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

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

Проблема

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

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

Существует множество инструментов, помогающих нам отслеживать и улучшать наблюдаемость, таких как APM или Distributed Tracing. Так что, наверное, кажется, что я возлагаю на журнал слишком большую ответственность. Но я думаю, что хорошо написанный журнал — это самое дешевое решение, которое мы можем найти для улучшения наблюдаемости приложения. Кроме того, он может добавить больше информации, которой не могут иметь инструменты мониторинга. Комбинируя все эти инструменты, он может легко помочь нам понять, что происходит в приложениях, особенно в процессах устранения неполадок и мониторинга.

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

Управление журналом и панель управления

Давайте сначала поговорим об этом. Идея улучшить то, как мы ведем журнал, возникла после того, как мы использовали инструменты управления журналами и панель визуализации. Мы используем Splunk и ELK. Они оба великолепны и работают одинаково для поиска, запросов и предоставления статистики. Мы можем извлечь так много информации в режиме реального времени, если будем передавать журналы в эти приложения.

Это как Google; Я могу искать любой текст
Итак, 95% запросов имеют код статуса 200 OK; мы можем улучшить это!
За последние 5 минут 5 % запросов были отклонены
* Какой API наиболее подвержен влиянию?
* Какой код ошибки вызывает наибольшее количество ошибок?
* Является ли Был ли какой-либо рост трафика перед тем, как возникла ошибка?
* Можем ли мы определить, какой регион затронут этой ошибкой?
* Ошибка сосредоточена только на одном узле?

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

Общий журнал

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

Журнал событий

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

  • Одна запись в журнале не представляет ни одну транзакцию, ни один запрос.
  • Для приложения, которое обрабатывает запросы одновременно, последовательность событий может перекрываться с другими входящими запросами. Сделайте так, чтобы читать было еще труднее.
  • Информация в основном хранится в поле message. Эти значения являются произвольным текстом; это может быть дико. Таким образом, информацию может быть трудно анализировать машиной.

Журнал запросов

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

  • Каждое событие в журнале запросов представляет собой один запрос
  • По умолчанию этот журнал предоставляется в каждой веб-службе.
  • Мы можем измерить общий показатель успешности и время ответа из этого журнала, поскольку одна запись представляет один клиентский запрос.
  • Информация для каждого события в основном ограничивается IP-адресом клиента, отправленным байтом, кодом состояния и временем отклика.

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

Красивое бревно

Возможно, это не лучшая практика в отрасли. Несмотря ни на что, вот список:

1. Сделать его машиночитаемым

Сначала я думал, что определение формата журнала зависит от того, кто будет читать журналы. Это человек или машина? Сделайте его максимально дружелюбным к тому, кто будет читать эти журналы. Со временем я понял, что ручное чтение журналов на сервер не очень удобно и не масштабируется никоим образом. Сделать его понятным для человека больше не вариант. Я рекомендую ограничить доступ непосредственно к серверу только для просмотра логов. Позвольте инструментам управления журналами собрать его для вас.

Итак, я предлагаю всегда использовать удобный для машин текстовый формат, такой как JSON, потому что и ключ, и значение записываются. Кроме того, JSON — это стандартный формат, который каждое управление журналами может автоматически читать и анализировать. Еще кое-что; не используйте CSV или формат, разделенный вертикальной чертой, потому что мы должны поддерживать ссылку на заголовок журнала для анализа.

2. Поместите идентификатор в свой журнал, но не смешивайте его с сообщениями о событиях

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

severity="error" message="Unable to retrieve information for user hirzani and transaction id OIytrYJS38297UHS due to database failure with error code ABC"

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

Итак, напишите это вместо этого,

severity="error" user="hirzani" id="OIytrYJS38297UHS"
message="Unable to retrieve information due to database failure with error code ABC"

3. Оставьте небольшое количество конечных точек API

Мне, как команде мониторинга, трудно обрабатывать такие конечные точки API, /api/profile/{username} or /api/{username}/profile/birthdate.
Это определение API создаст большое количество уникальных конечных точек API, поскольку имя пользователя является его частью. Я считаю, что username следует указать в параметре вместо конечной точки URL. Если мы определяем конечную точку API с такими переменными, убедитесь, что у нас есть контролируемое количество уникальных значений. Это вызывает те же проблемы, что и то, что я упоминал в пункте № 2. Подсчет транзакций для каждого API может быть грязным.

Другой пример, /api/season/{season}/info. Это определение конечной точки API по-прежнему приемлемо, поскольку `{season}` может иметь только 2 или 4 значения. Это может быть нормально с точки зрения беспорядка. Но вместо этого я предпочитаю использовать статическое определение конечной точки. Поместите переменные в параметр. Конечная точка API, такая как /api/season/winter/info и /api/season/summer/info, скорее всего, будет иметь одинаковую логику. С точки зрения мониторинга производительности эти два API лучше определить в одном API, поскольку оба они обслуживаются одной и той же строкой кода.

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

4. Добавьте полезный тег

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

«Эй, а можно разбить по регионам на подсчет ошибок за последние 5 минут?»

«Нет, регион не прописан в логе, надо свериться с базой данных».

«Неважно, наша база данных отчетов запаздывает на час, и мы не хотим выполнять специальный запрос к транзакционной таблице».

Это требование будет определять, какую информацию мы должны помещать в журналы. Когда многие люди в организации уже потребляют информацию из управления журналами и панели мониторинга, у них будут некоторые идеи о том, какую информацию они хотят видеть.

Конечно, мы ничего не можем поместить в журнал, но, надеюсь, вы сможете понять, какие важные теги нужно поставить.

5. Определите четкий код ошибки и категорию ошибки.

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

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

Успех
Когда запрос выполнен должным образом, мы называем его успешным. Система предоставляет ожидаемый ответ на запрос.

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

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

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

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

Мониторинг как навык

Недавно я прочитал книгу Практический мониторинг Майка Джулиана; он упоминает несколько анти-паттернов мониторинга и шаблонов проектирования. Один из антипаттернов мониторинга называется Мониторинг как задание. Итак, это неправильный подход, если мы думаем, что мониторинг — это работа одной команды. Невозможно освоить несколько сервисов и приложений с сегодняшней скоростью изменений, одновременно разбираясь в хорошо работающей базе данных и балансировщике нагрузки. Наоборот, мониторинг — это навык, которым должен овладеть каждый в организации. Следовательно, мониторинг как навык.