Общие советы по интерпретации журналов ошибок [закрыто]

Позвольте разработчикам диагностировать производственные проблемы время от времени. Это сделает чудеса для Вашего входа.:)

Моя привычка с журналами сервера: рассматривайте их регулярно и исследуйте/разрешайте проблемы, которые я нахожу. Я делаю это заранее - не ожидающий, пока пользователи не воют о системном отключении электричества. Главная причина это эффективно, действительно сводится к нескольким старым поговоркам:

Один стежок, сделанный вовремя, стоит девяти. Очевидно, при решении проблем, в то время как они являются маленькими, Вы опережаете события, и у пользователей/управления будет меньше причин вопить на Вас; это - хорошая вещь.

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

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

Моя цель с такими системами состоит в том, чтобы пересмотреть журналы еженедельно, пока я не решил или понял каждую новую ошибку, которая подходит; затем ослабьте мои обзоры журнала к ежемесячному журналу. Чистые журналы легче считать!

Хорошая программа поддерживает регистрирующиеся уровни. И обычно журналы бесполезны без меток времени.

Большинство дистрибутивов Linux идет с logwatch инструментом; учитесь использовать его, и настраивать это, игнорируют настройки. Прием должен установить порог болевого ощущения соответственно, так, чтобы ничто критическое не было проигнорировано, но не столь спамное, что administators пишут почтовые правила зарегистрировать и проигнорировать logwatch почту.

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

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

При отказе сделать это в среде Unix вероятно старший значащий сингл (дорогостоящий и разрушительный) обычно сделанный контролем.

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

Что? Нет никакой документации? Время для AttitudeAdjustmentTool

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

Об определенной общей ситуации, когда у Вас есть все они одновременно: (1) проблема в распределенной среде (2) огромная груда информации об отладке, рассеянной по сотрудничающим серверам и различным файлам журнала (3) никакая документация для интерпретации журналов (4) ничто на Google (5) никакая подсказка (6) плееры пинг-понга вместо поддержки поставщика.

• В первую очередь, удостоверьтесь, что время синхронизируется во всей среде (ntp). Если это не, забудьте о попытке узнать отношения межхоста от их файлов журнала.
• Не поднимайте случайную "ошибку" со случайного журнала для обвинения. Считайте журнал хронологически, помня, что "ошибочная" строка может быть также результатом нормальной операции программного обеспечения и всегда там.
• Сравните журналы от правильного функционирования до журналов от проблемной ситуации. В какой точке они прекращают соответствовать? (vimdiff могло бы быть полезным),
• Если во время тестовых сценариев у Вас есть функциональность для вставки собственных сообщений журнала, используйте ее. (как регистратор в системном журнале)
• Согласно анализу, если Вы ловите себя переключающийся между многими огромными, входит и дальше, пытаться поймать поток действия - пытается объединить журналы. (Используйте sed для размещения времени в первый столбец. Используйте cat+sort для слияния нескольких файлов. И конечно grep - соперничают за фильтрацию ненужных строк.)

Не делайте предположения о файлах журнала.

Форматы поля должны быть проверены. Например: даты дд/мм/гг или mm/dd/yy?; действительно ли числовые поля являются десятичными, шестнадцатеричными, восьмеричными или что-то еще? Последовательные метки времени (другие упомянули важность синхронизации времени между устройствами: проверьте, что это было sync'd или разрабатывает то, что источник метки времени был бы и исправил бы его)?

Все устройства/процессы регистрируются на том же уровне журнала и туда, где Вы ожидали бы их к?

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