«Шумная» проблема с журналированием - PullRequest
4 голосов
/ 04 января 2010

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

Каковы некоторые распространенные подходы, методы и, возможно, даже структуры, которые могут предоставить краткую информацию регистрации, которая быстро просматривается и читается?

Ответы [ 4 ]

5 голосов
/ 04 января 2010

Log4J и другие каркасы журналов предоставляют концепцию уровней журналов, где вы указываете приоритет с каждым оператором журнала. Затем во время выполнения вы устанавливаете уровень самого файла журнала - будут проходить только операторы журнала с таким приоритетом или выше. Так, например, вы можете настроить свою производственную систему так, чтобы она регистрировала сообщения только на уровнях WARN или ERROR, тогда как ваша среда разработки может быть настроена на запись чего-либо с DEBUG или выше.

Это хорошее решение, поскольку оно не требует каких-либо изменений в коде (например, добавление / удаление операторов журнала для каждой новой сборки) и может быть легко перенастроено (временно), когда вам нужно выполнить что-то вроде отладки определенного проблема.

Если ваша система использует архитектуру .NET, есть порт log4j, называемый log4net, который вы можете использовать (хотя очевидно, что замена существующей системы потребует изменения кода). Однако этот вопрос задавался об общих принципах проектирования, а не о том, что делать с существующей кодовой базой, поэтому я думаю, что этого ответа достаточно.

Редактировать: поскольку у вас есть возможность использовать совершенно новый фреймворк, на этой странице есть список альтернатив, хотя я неравнодушен к log4j из-за моего собственного использования в приложениях Java.

1 голос
/ 04 января 2010

Я рекомендую log4net . Вам может понадобиться построить вокруг него свой варпер (более безоблачный).

0 голосов
/ 05 января 2010

Если вы хотите сопоставить несколько журналов, Splunk определенно стоит посмотреть.

Чтобы сделать данные журнала приложений более доступными и легко интерпретируемыми, взгляните на Гибралтар .

Гибралтар включает в себя мощные инструменты анализа журналов, которые могут помочь вам увидеть шаблоны тысяч журналов. Хотя он включает в себя собственный API ведения журнала, он также работает с популярными средами ведения журнала, такими как log4net, NLog, DotNetLog ObjectGuy, а также классы Trace / Console в пространстве имен .NET System.Diagnostics.

0 голосов
/ 04 января 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...