Чтение файлов журналов может быть довольно неприятным, поскольку по своей природе их содержание говорит о разработчике, который их написал, как о самой проблеме.
У тебя есть общее назначение советы по интерпретации журналов ошибок (например: "Google - ваш друг" или "какая-то ошибка коды возникают чаще других »или« помните, что предупреждения и ошибки очень разные »)?
О конкретной распространенной ситуации, когда у вас есть все это одновременно: (1) проблема в распределенной среде (2) огромная куча отладочной информации, разбросанной по взаимодействующим серверам и различным файлам журнала (3) нет документации для интерпретации журналы (4) ничего в Google (5) нет подсказки (6) игроки в пинг-понг вместо поддержки поставщика.
Позвольте разработчикам время от времени устранять производственные проблемы. Это будет творить чудеса с вашей регистрацией. :)
Хорошая программа поддерживает уровни ведения журнала. И обычно журналы бесполезны без меток времени.
Большинство дистрибутивов Linux поставляются с инструментом logwatch; научитесь его использовать и настройте параметры игнорирования. Хитрость заключается в том, чтобы правильно установить порог боли, чтобы ничего критического не игнорировалось, но не было таким спамом, чтобы администраторы записывали почтовые правила в файл и игнорировали почту logwatch.
Моя привычка к журналам сервера: регулярно просматривать их и исследовать / решать обнаруженные мной проблемы. Я делаю это заранее - не дожидаясь, пока пользователи начнут кричать о сбое системы. Основная причина того, что это эффективно, сводится к паре старых высказываний:
Стежок, сделанный вовремя, стоит девяти. Очевидно, что если вы решаете проблемы, пока они невелики, вы на шаг впереди, и у пользователей / руководства будет меньше причин кричать на вас; это хорошая вещь.
Практика ведет к совершенству. Я думаю, что это большее преимущество для системного администратора. Заходя туда регулярно и активно читая журналы, вы приобретаете опыт и знания. Вы узнаете, что означают эти загадочные сообщения журнала - и которые тривиальны, а какие имеют большое значение. Процесс исследования сообщений, которые вы не сразу понимаете (а их поначалу будет много!), Многому научит вас о внутреннем устройстве ОС и приложениях, работающих в ней.
Обычно, когда я беру новую систему в управление, у нее в журнале будет довольно много ошибок, многие из которых повторяются довольно регулярно. Предыдущий администратор часто отмахивается от них чем-то вроде «не совсем уверен, в чем дело, но пользователи никогда не жаловались, поэтому я не считал его достаточно сломанным, чтобы исправить!»
Моя цель с такими системами - просматривать журналы еженедельно, пока я не решу или не пойму каждую новую возникающую ошибку; затем уменьшите количество обзоров журнала до ежемесячных. Чистые журналы читать легче!
Я не верю, что можно дать какие-либо общие советы для интерпретации журналов ошибок, за исключением того, что вы должны исследовать каждую ошибку в индивидуальном порядке, например с Google или прочитав исходный код, чтобы понять это.
Для обработки чего-то вроде syslog, особенно при агрегировании большого количества машин, можно сделать предложение общего назначения. Составьте список шаблонов, которые следует игнорировать, и список шаблонов, о которых следует немедленно предупреждать. Создавайте ежедневный отчет, исключающий «игнорировать» сообщения. (Или даже посмотрите файл журнала в реальном времени, исключая игнорируемые сообщения). Используйте этот отчет для добавления в список игнорирования и в список предупреждений. Для шаблонов, идентифицированных как реальные ошибки, отправьте уведомление администраторам в режиме реального времени. В идеале ваш список игнорирования должен быть достаточно подробным, чтобы вы могли прочитать пропадающие сообщения, а ваш список предупреждений должен быть достаточно простым, чтобы вы могли исследовать каждое, о чем вас предупреждают. Уметь справляться с потоками предупреждений от неисправной системы, которые нельзя исправить сразу. Стоит сохранить два дополнительных уровня шаблонов - те, которые стоит изучить, но которые вряд ли будут проблемой, и те, о которых стоит предупредить, но не мешать кому-то.
Неспособность сделать это в среде Unix, вероятно, является наиболее значительным (дорогостоящим и разрушительным) обычно совершаемым упущением.
Обратитесь к документации о файлах журнала, которые разработчики передали вместе с приложением.
Какой? Нет документации? Время для AttitudeAdjustmentИнструмент
А если серьезно, то документирование файлов журналов и их интерпретация должно стать одной из задач разработчиков. Их работа не выполняется, когда есть код, она выполняется, когда операторы могут запускать приложение и поддерживать его работоспособность, а это означает документацию, встречи по передаче, проектирование для управляемости и т. Д.
Не делайте предположений о файлах журналов.
Форматы полей необходимо проверить. Например: даты дд / мм / гг или мм / дд / гг ?; числовые поля десятичные, шестнадцатеричные, восьмеричные или что-то еще? Согласованы ли временные метки (другие отмечали важность синхронизации времени между устройствами: проверьте, было ли оно синхронизировано, или выясните, что является источником временной метки, и исправьте его)?
Все ли устройства / процессы ведут журнал на одном уровне и в том месте, где вы ожидаете?
Согласовано ли ведение журнала между разными версиями одного и того же программного обеспечения? (проверка того, что выходные данные журнала соответствуют предыдущим версиям и документации, должна быть в списке для тестирования новых версий программного обеспечения, но может быть упущена из виду)