Насколько я понял, одной из проблем было решение индепотентности операций. С этим намного легче бороться, если добавить при отправке данных уникальный идентификатор команды { OperationID: GUID, Data: any }, а при повторном принятии команды при RETRY очень легко проверять на дубликаты.
Я не знаю стандартного функционала в log4net, который бы мог писать в elasticsearch напрямую.
Мы используем связку nxlog -> elasticsearch -> kibana, где вся конфигурация сводится к тому, чтобы отправить сериализированный LoggingEvent в JSON на порт 514 по UDP. Для работы с UDP у log4net уже есть RemoteSyslogAppender. Это работает довольно быстро.
Суть статьи было донести информацию о том, что если вы используете Properties в LoggingEvent, то всегда тратится время на получение имени пользователя, которое довольно затратно по времени.
Да, все верно, самый быстрый пусть писать напрямую в хранилище. Просто банально нет возможности их переписать: не достаточно ресурсов и времени. У нас много разных серверов со множеством сервисов. А так это изменение только в конфигурации.
Я как-то не заметил этот момент, мои извинения :)
Насколько я понял, одной из проблем было решение индепотентности операций. С этим намного легче бороться, если добавить при отправке данных уникальный идентификатор команды
{ OperationID: GUID, Data: any }, а при повторном принятии команды при RETRY очень легко проверять на дубликаты.Я не знаю стандартного функционала в log4net, который бы мог писать в elasticsearch напрямую.
Мы используем связку nxlog -> elasticsearch -> kibana, где вся конфигурация сводится к тому, чтобы отправить сериализированный LoggingEvent в JSON на порт 514 по UDP. Для работы с UDP у log4net уже есть RemoteSyslogAppender. Это работает довольно быстро.
Суть статьи было донести информацию о том, что если вы используете Properties в LoggingEvent, то всегда тратится время на получение имени пользователя, которое довольно затратно по времени.