97 этюдов для программистов. Опыт ведущих экспертов

Многословный журнал лишит вас сна Йоханнес Бродуолл

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

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

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

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

Распределенные системы создают дополнительный уровень сложности. Вы должны решить, как действовать в случае отказа внешних зависимостей. Если система сильно распределена, это может происходить часто. Учтите это обстоятельство при выборе политики ведения журнала.

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

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