Построение новой системы логирования

[AntonIV8]

Это обсуждение было начато в рамках итерации по построению новой единой системы логирования технологии.

Основные требования к системе:

1. Универсальность - должна собирать логи с разных источников
2. Простота - не должна быть тяжелым сверхфункциональным решением, т.к в этом нет потребности
3. Поддерживать структурное логирование

В ходе дискуссии необходимо выбрать лучшее решение.

Найденные материалы:

Serilog + ELK
https://blog.romanpavlov.me/logging-serilog-elk/

Инструменты структурного логирования (для .NET)
https://redwerk.com/blog/structured-logging-in-third-party-net-logging-frameworks/

Сравнение 4х систем логирования
https://habr.com/ru/post/594805/

[AntonIV8]

Пока представляется 2 схемы архитектуры единой системы логирования. Нужно принять решение - выбрать какую-то одну или сделать поддержку сразу двух

1. Каждый сервис отдельно шлет лог
   

2. Фронтенд шлет логи через лог-сервис бэка + пишет логи в таблицу ApplicationLog бд приложения .

На этих двух схемах представлены 3 способа ведения логов ember-фронтом

1. Напрямую через OData и объект ApplicationLog
2. Через специальный контроллер в бакенде и LogService
3. Напрямую в чужой сервис логирования

Предлагаю реализовать все эти три пути (1, 2 сейчас 3 возм позже). Для этого нужна доработка сервиса логирования фронта и бэка.
В самом ember-приложении только расширится настройка сервиса логирования, которая сейчас в config/environment. Этой настройкой можно будет включать/выключать эти три функции (они могут работать параллельно)

Почему я предлагаю сделать сразу три варианта:

1. Останется поддержка проектов, у которых предусмотрено отображение логов в приложении
2. Это основной способ, который был более-менее определен в целях этой итерации
3. Есть вероятность, что такой вариант пригодится в будущем

[mao29]

Для первой схемы придется выставлять наружу какой-то эндпоинт, через который логи напрямую в хранилище логов будут попадать. Нужно понять можно ли на этот эндпоинт сделать авторизацию, чтобы нельзя было заддосить этот эндпоинт всяким мусором. В случае со 2 вариантом схемы насколько я понимаю авторизация может быть та же, что и для всех остальных эндпоинтов бекенда

[mao29]

Насчет второй схемы еще не понял коммент про "логи как обычные записи в спецтаблице". С фронтенда логи мне кажется лучше не через ember data отправлять, а обычными http-запросами на отдельный эндпоинт на бекенде, чтобы поменьше преобразований по пути происходило

[mao29]

Если делать через log4net, можно несколько аппендеров настроить, чтобы и в ApplicationLog писалось и в стороннее хранилище. При этом я из описания не очень понял можно ли добиться чтобы логи от фронтенда через LogService уходили в хранилище с информацией, что это именно с фронтенда запись, или они будут как будто это логи бекенда писаться

[AntonIV8]

Для этого мы сделали WebApi для лог сервиса. Механизм записи в лог по факту будет бековский, через LogService (log4net).
Дорабатываем logService в ember-flexberry. Можно наверное при формировании запроса для отправки лог-сообщения через web, к этому сообщению какую-нибудь пометку добавлять.
Если рассматривать loki+grafana, то к примеру эта пометка может быть в JSON, например source="frontend". Затем в интерфейсе графаны добавить фильтр по этому label(source) и он выдаст соотв записи

[AntonIV8]

Занимаемся проблемой мусорных логов. Очень много логов генерит сам эмбер. Придумали два подхода решения этой проблемы. Подходы основаны на фильтрации нежелательных сообщений