kolbasik Sep 28 2016 at 15:03

История одного исследования в log4net и ускорение его более чем в 10 раз

7 min

8.3K

.NET*C#*

From sandbox

+20

Comments 9

Bonart Sep 28 2016 at 15:28

А что мешает писать напрямую в Elastic Search?

kolbasik Sep 28 2016 at 16:03

Да, все верно, самый быстрый пусть писать напрямую в хранилище. Просто банально нет возможности их переписать: не достаточно ресурсов и времени. У нас много разных серверов со множеством сервисов. А так это изменение только в конфигурации.

Bonart Sep 28 2016 at 16:28

А сам log4net туда писать не умеет?

kolbasik Sep 28 2016 at 17:06

Я не знаю стандартного функционала в log4net, который бы мог писать в elasticsearch напрямую.
Мы используем связку nxlog -> elasticsearch -> kibana, где вся конфигурация сводится к тому, чтобы отправить сериализированный LoggingEvent в JSON на порт 514 по UDP. Для работы с UDP у log4net уже есть RemoteSyslogAppender. Это работает довольно быстро.

Суть статьи было донести информацию о том, что если вы используете Properties в LoggingEvent, то всегда тратится время на получение имени пользователя, которое довольно затратно по времени.

Vestild Sep 28 2016 at 18:15

есть аппендер https://github.com/jptoto/log4net.ElasticSearch
там правда баги, поэтому пришлось форкнуть и пофиксить

Bonart Sep 30 2016 at 16:22

Я собственно к чему веду: возможно, вам лучше будет использовать связку log4net -> serilog -> elasticsearch -> kibana, особенно если log4net напрямую в elasticsearch писать не умеет.
Ключевые моменты:

Вывод у serilog структурирован сразу, что при использовании elasticsearch позволяет сильно сэкономить на дальнейшей обработке и хранении собранных данных.
Имеющуюся кодовую базу можно постепенно переводить на прямое использование serilog с сохранением работоспособности приложений.

nkochnev Sep 28 2016 at 17:59

Первоначально я пробовал настроить логирование в ElasticSearch через Logstash, пока не понял это лишний шаг. Сейчас мы используем Nlog для прямой записи в ElasticSearch, связка работает отлично!
Надо было только поискать ElasticSearchTarget, подправить немного под себя. Например, при логировании Exception всегда сохраняем message, StackTrace и все InnerException

centur Sep 29 2016 at 10:18

Ну мы в общем тоже давно забили на универсальных прокси-провайдеров и переключились на Serilog — просто написали тонкую прослойку-враппер над методами, которые мы вызываем (что может показаться оверкилом но делать некоторые конфигурации просто удобней в классе-враппере).

Вообще чем больше в интернете Logging as a service, тем больше приходишь к выводу что вот эти ребята предлагают тебе установить свой bottleneck за деньги. Современные логгеры настолько просты и удобны, что added value таких прокси в части scalability стремится к нулю. Хорошо если они еще какую-то аналитику предлагают по вашим логам, но чаще всего оказывается чтобы она работала — надо писать сообщения в service-specific формате ( что приводит к тому что эти фичи не работают при переходе между вендорами). Структурные логи в этом отношении спасают, т.к. хранят не конечный результат, а все исходные данные и могут отдать их в любой sink с сохранением большего количества деталей, чем "просто строка"

И к слову — структурированные логи оказались очень практичными и при поиске — можно делать запросы по данным не при помощи регэксов а по структуре сообщений и внутренних значений.

NIKOSV Sep 29 2016 at 10:32

Serilog вроде как лучшее на сегодня решение для .NET. Логирование контекста, в частности CorrelationID доступно из коробки, структурированые логи из коробки, репорт логов в документообразные БД из коробки, включая elasticsearch.