Я запускаю несколько приложений, которые создают свои собственные журналы. Затем я запускаю сценарии cron на том же сервере, чтобы импортировать данные для моего приложения. Когда эти ошибки cron отсутствуют, по умолчанию он отправляет электронные письма пользователю, который запускает задание cron.
Слишком много мест, где мне нужно проверять журналы и почту на предмет того, что потенциально могло пойти не так. Мой вопрос в том, что лучше всего сделать это или даже лучше - это как приложение парсера журналов, которое будет просматривать все системные журналы, когда что-то действительно идет не так, вместо того, чтобы мне приходилось просматривать это каждый день?
Logwatch - хорошее решение, но вы по-прежнему имеете дело с большим количеством писем. Я предпочитаю вводить все в системный журнал, а затем собирать эти системные журналы на центральной машине регистрации. Затем вы можете выполнять различные виды обработки и корреляции событий в журналах в одном месте.
Во-первых, как добавить журналы приложений в системный журнал? Есть несколько способов. В простейшем случае вы можете позвонить logger в сценариях оболочки для создания сообщений системного журнала. Если вы используете сценарии Perl, вы можете модифицировать их для использования Log4Perl для перенаправления журналов в системный журнал. Подобные подходы доступны и для других языков.
Вам следует подумать о замене стандартного системного логического файла чем-то вроде syslog-ng для повышения производительности и возможности фильтрации журналов по мере их перемещения по конвейеру. syslog-ng также поддерживает блокирующие каналы, поэтому вы можете перенаправить вывод существующей программы прямо в syslog-ng без изменения программы и без потери данных.
Собрав все журналы в одном месте, вы можете настроить такие инструменты, как Простой коррелятор событий найти закономерности. Вы также можете запускать такие инструменты, как logstash для сохранения журналов в базе данных и включения более мощных запросов и построения графиков.
Конечно, для этого есть и коммерческие инструменты. Один из самых популярных - Splunk который можно попробовать бесплатно и для ограниченного объема данных. Splunk поставляется с клиентом, который можно запускать на нескольких серверах, чтобы избавить вас от необходимости загружать все ваши журналы на центральный сервер системного журнала. Если у вас больше денег, чем у разработчиков, возможно, стоит подумать о чем-то вроде Splunk.
Наконец, вот хороший мини-руководство по центральной регистрации это касается многих из тех же вопросов, что и я.
На мой взгляд, журнал лучший. По умолчанию он входит в состав многих дистрибутивов, и хотя освоить синтаксис конфигурации непросто, после того, как работа сделана, она становится во многом работой, которую нужно расслабить и расслабиться. Он работает в пакетном режиме, время от времени запускается для переваривания последних файлов журнала, а также для сортировки и обобщения записей.
Если вы не хотите так много работать, образец меньше взрыва за гораздо меньше денег. Он также работает в интерактивном режиме, поглощая каждую новую строку файла журнала по мере ее появления и предупреждая вас по запросу, если она соответствует определенным условиям.
Какой бы подход вы ни выбрали, я лично рекомендовал бы отказаться от подхода «сортировать файлы журналов, когда что-то пойдет не так», в пользу «постоянно просматривайте файлы журналов, чтобы я мог освоить свою систему».
Во-первых, журналы наблюдаемого сбоя могут не быть журналами корня сбоя. Ваш веб-сервер может кричать, что данные из файла кэша cookie имеют неправильный формат (ошибка утверждения!), Пока он не посинет, но если вы не смотрите системный журнал, в котором говорится /cache заполнен на 100%, и из этого следует, что никакие данные cookie не могут быть записаны в кеш, например, вы не узнаете, что пошло не так.
Во-вторых, на мой взгляд, неразумно ожидать, что приложение будет знать, какие журналы создает ваша система при нормальной или патологической работе. Понимание тонкостей вашей системы - ваша работа как системного администратора; большинство системных администраторов пойдут на шаг дальше и автоматизируют исключение всех нормальных действий и уведомление о всех патологических, используя обычные инструменты (например, указанные выше), настроенные для их системы, или написав свои собственные.
Другое решение, если у вас есть ресурсы, - SPLUNK. Вы создаете сервер SPLUNK в своей сети и отправляете на него все журналы со всех ваших серверов и всех ваших приложений. Он индексирует журналы и синхронизирует их с временной шкалой.
Это потрясающая концепция, которая действительно может помочь с проблемами отладки. Бесплатно до 500 МБ журналов в день:
http://www.splunk.com/view/free-vs-enterprise/SP-CAAAE8W
Андрей
Вы также можете взглянуть на Осьминог (отказ от ответственности: мой проект), довольно сложный в начале, но в конце концов действительно мощный.