Какова лучшая практика для централизованного входа? [закрытый]

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

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

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

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

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

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

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

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

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

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

Есть некоторые сторонние поставщики, которые предлагают решения, некоторые даже интегрированные с log4net, например bugcollect.