Какая наилучшая практика для централизованного ведения журнала?

Ответ 1

Один предостерегающий взгляд: в 100+ приложениях в большом магазине, где сотни, возможно, тысяч хостов, запускающих эти приложения, избегают всего, что вызывает тугую связь. Это практически исключает возможность подключения непосредственно к SQL Server или к любому решению базы данных, поскольку ведение журнала приложений зависит от доступности репозитория журнала.

Доступность центрального репозитория немного сложнее, чем просто "если вы не можете подключиться, не регистрируйте его", потому что обычно наиболее интересные события возникают, когда есть проблемы, а не когда все идет гладко. Если ваш журнал записывает записи точно, когда что-то становится интересным, ему никогда не будет доверено разрешать инциденты и, как таковые, не смогут получить поддержку и поддержку для других держателей акций (то есть владельцев приложений).
Если вы решите, что вы можете реализовать сохранение и повторить неудачную доставку информации о логах самостоятельно, вы столкнулись с тяжелой битвой: это не тривиальная задача и намного сложнее, чем кажется, начиная с эффективного и надежного хранения сохраненной информации и заканчивая созданием хорошей повторной логики и логики логики.

У вас также должен быть ответ на проблемы аутентификации и безопасности. Крупные организации имеют несколько доменов с различными доверительными отношениями, сотрудники работают через VPN или прямой доступ из дома, некоторые приложения запускаются без присмотра, некоторые службы настроены для работы как локальные пользователи, некоторые машины не объединены с доменом и т.д. И т.д. Вам лучше вопрос о том, как развертывается модуль протоколирования каждого приложения, повсеместно развертывается, собирается аутентифицироваться в центральном репозитории (и какие ситуации не будут отменены).

В идеале вы должны использовать механизм доставки вне коробки для вашего модуля ведения журнала. MSMQ, вероятно, наиболее подходящая: надежная асинхронная надежная доставка (по крайней мере, в большинстве случаев использования), доступная на каждом хосте Windows при установке (необязательно). Что является основной причиной боли, ваши приложения будут зависеть от компонента ОС, отличного от стандартного.

Центральное хранилище репозитория должно иметь возможность доставлять запрошенную информацию, возможно:

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

Единственное хранилище, способное доставить это для любого серьезного org (размер, время жизни), является реляционным движком, поэтому, вероятно, SQL Server. Выполнение анализа текстовых файлов действительно не будет идти на расстояние.

Поэтому я бы рекомендовал перенос/доставку журналов на основе обмена сообщениями (MSMQ) и реляционный центральный репозиторий (SQL Server), возможно, с компонентом aanalitycal поверх него (Analysis Services Data Mining). как вы видите, это явно не малый подвиг, и он охватывает немного больше, чем просто настройка log4net.

Что касается того, что нужно регистрировать, вы говорите, что уже задумываетесь, но я хотел бы перезвонить в моем дополнительном 2c: часто, особенно в случае расследования инцидентов, вам понравится возможность запрашивать дополнительную информацию. Это означает, что вы хотите узнать содержимое определенных файлов с компьютера инцидента или некоторые разделы реестра или некоторые значения счетчика производительности или полный свал процесса. Очень полезно иметь возможность запрашивать эту информацию из интерфейса центрального репозитория, но нецелесообразно всегда собирать эту информацию, если это необходимо. Это означает, что между выражением и центральным хранилищем должна быть какая-то двунаправленная связь, когда приложение сообщает об инциденте, его можно попросить добавить дополнительную информацию (например, свалку процесса по вине). Там должно быть много инфраструктуры, чтобы что-то подобное происходило из протокола между ведением журнала приложений и центральным репозиторием, к возможности центрального репозитория распознавать повторение инцидента, в качестве библиотеки логгинга для сбора дополнительная информация, требуемая и не в последнюю очередь способность оператора отмечать инциденты, поскольку они нуждаются в дополнительной информации о следующем происшествии.

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

Есть сторонние поставщики, предлагающие решения, некоторые даже интегрированные с log4net, например bugcollect.com (Полное раскрытие: моя собственная компания), Error Traffic Controller или Exceptioneer и другие.

Ответ 2

Logstash + Elasticsearch + Kibana + Redis или RabbitMQ + NLog или Log4net

Хранение + Поиск и аналитика: Elasticsearch
Сбор и анализ: Logstash
Визуализировать: Kibana
Queue & Buffer: Redis
В приложении: NLog

Ответ 3

Упомянутое до сих пор ограничение длины сообщения Syslog в 1024 байта вводит в заблуждение и неправильно смещает решения, основанные на Syslog.

Ограничение для устаревшего "протокола системного журнала BSD" действительно составляет 1024 байта.

Протокол системного журнала BSD - 4.1 части сообщения системного журнала

Ограничение для современного "протокола системного журнала" зависит от реализации, но ДОЛЖНО составлять не менее 480 байтов, ДОЛЖНО быть не менее 2048 байтов и МОЖЕТ быть еще выше.

Протокол системного журнала BSD - 6.1. Длина сообщения

Например, параметр конфигурации Rsyslog называется MaxMessageSize, который, как предлагается в документации, может быть установлен как минимум на 64 КБ.

rsyslog - директивы конфигурации

То, что организация-разработчик является "домом Microsoft", где "решения UNIX не годятся" не должно мешать менее точным читателям получать точную информацию.

Ответ 4

SQL будет работать, но я использовал Splunk для агрегирования журналов. Я смог найти какую-то удивительную информацию, основанную на том, как Splunk позволяет вам индексировать ваши данные, а затем использовать свои инструменты запросов, чтобы сделать несколько хороших графиков. Вы также можете бесплатно загрузить базовую версию.

Ответ 5

Как указывали другие ответы, наиболее близким к отраслевому стандарту является syslog. Но не отчаивайтесь, потому что вы живете в мире Windows. Kiwi имеет syslog daemaon, который работает в Windows, и он свободен. Узнайте больше.

Обновление
Как указывает @MichaelFreidgeim, Киви теперь взимает плату за своего демона syslog. Однако есть и другие свободные альтернативы. Этот другой ответ SO ссылается на пару из них.

Ответ 6

Если у вас есть журнал log4net для локального EventViewer, вы можете просмотреть эти журналы в окне Windows 2008, см. статью

Ответ 7

Как уже указывалось другими, направление журналов с масштабов приложений и хостов непосредственно в базу данных не является хорошей идеей. Я просто хотел добавить еще одно преимущество в пользу использования выделенного централизованного сервера регистрации - это развязка ваших приложений из инфраструктуры журналов. Поскольку вы находитесь в .Net, есть несколько хороших вариантов - log4net и NLog. Оба являются очень хорошими продуктами, но мне особенно нравится NLog, он оказался намного лучше с более тяжелыми нагрузками, имеет гораздо лучшие варианты конфигурации и активно поддерживается. Log4Net, насколько я знаю, не изменился в течение нескольких лет и имеет некоторые проблемы, но все же очень надежное решение. Таким образом, как только вы используете такую ​​инфраструктуру, вы контролируете уровень приложения в отношении того, как, когда и когда он передает свои журналы на централизованный сервер. Если вообще.

Посмотрите logFaces, который был специально создан для описываемых ситуаций - для объединения журналов с масштабов приложений и хостов, предоставляющих централизованные хранения и источника для анализа и мониторинга. И делать все это не навязчиво с нулевыми изменениями в вашей существующей базе кода. Он будет обрабатывать огромную нагрузку приложений и хостов и позволяет указать, что вы хотите делать с данными. С другой стороны, у вас есть очень приятный графический интерфейс для мониторинга в режиме реального времени или копания в данных. Вам вообще не нужно иметь дело с базами данных. Есть множество баз данных, которые выбрали бы - как SQL, так и NoSQL. BTW, RDBS - не лучшие исполнители с очень большими хранилищами данных. logFaces может работать с MongoDB - эта настройка обычно превосходит лучшие традиционные бренды RDBS в десять раз или около того. Особенно при использовании с закрытыми коллекциями.

(для раскрытия я являюсь автором logFaces)

Ответ 8

Если вы работаете на машинах * nix, традиционное решение syslog.

Ответ 9

В Unix есть syslog.
Кроме того, вы можете проверить данное тематическое исследование.