Это объяснение стратегий, которые мы используем для входа в Single Music , которые мы разработали за последние пару лет. Мы используем тщательную настройку уровней ведения журнала, агрессивное оповещение и короткий период хранения, чтобы быть более осведомленными о том, что мы регистрируем, и чтобы мы могли быстро выявлять и диагностировать проблемы.
Уровни ведения журнала
Большинство структурированных систем ведения журнала позволяют пользователям регистрировать сообщения на разных “уровнях. “Уровень печатается в начале сообщения и служит для разделения сообщений на категории высокого уровня. Поскольку наш сервер состоит в основном из приложений spring-boot на основе Java, мы используем API SLF4J с реализацией Logback . API SL4J предоставляет несколько уровней журнала, но в одном мы используем только четыре: Отладка, Информация, Предупреждение и Ошибка — в порядке возрастания серьезности, соответственно. Вот объяснение того, как мы разделяем наши сообщения журнала на четыре категории.
отлаживать
Это наш самый подробный уровень журнала. Он переключается во время выполнения и отключен по умолчанию. Цель наших инструкций уровня DEBUG состоит в том, чтобы иметь возможность видеть основной путь выполнения кода через определенные важные процессы. У нас нет инструкций журнала в каждой ветви кода, но основные “решения”, принимаемые бизнес-логикой, регистрируются. Как следует из названия DEBUG , это в некоторой степени служит альтернативой фактической отладке и позволяет нам по существу отслеживать, что происходит в коде, если что-то идет не так.
информация
Это основной уровень журнала “что-то случилось”. Он включен по умолчанию и по сути является просто шумом. Честно говоря, иногда мне нравится смотреть “Живой хвост” всех наших журналов (мы объединяем наши журналы с помощью Logz.io ) и журналы уровня INFO служат для того, чтобы заверить нас в том, что все работает нормально. Многое из того, что мы регистрируем здесь, – это небольшие заметки, когда службы отправляют/получают асинхронные сообщения.
предупреждать
На уровне ПРЕДУПРЕЖДЕНИЕ мы отмечаем исключительные случаи, которые недостаточно серьезны, чтобы требовать немедленных действий. Это включает в себя странные состояния, в которых мы не ожидаем оказаться, пользователей, пытающихся делать недопустимые вещи, и проблемы технической задолженности, которые необходимо решить в какой-то момент, но не являются неотложными. Мы отслеживаем количество сообщений уровня ПРЕДУПРЕЖДЕНИЕ на панели мониторинга и выясняем, увеличивается ли их количество.
ошибка
На уровне ОШИБКА , нашем самом высоком уровне серьезности, мы регистрируем исключительные случаи, требующие немедленного или близкого к немедленному расследования. Это сценарии, которые приводят к ошибкам пользователя, неудачным пакетным или фоновым транзакциям, которые необходимо повторить/воспроизвести/исправить, а также сценарии, в которых данные повреждены или потеряны. Хотя мы стараемся регистрировать как можно больше контекста во всех наших инструкциях журнала, эти ERROR журналы, в частности, содержат наибольшее количество контекста о состоянии системы во время ошибки и самой ошибки. Если мы регистрируем возникшее исключение, мы обычно также регистрируем всю трассировку стека. Поскольку Журналы ОШИБОК являются наиболее важными и часто требуют каких-либо действий администратора, мы используем “коды ошибок” для их дальнейшей классификации в более конкретных областях. Например, если что-то не сработает во время нашего процесса создания отчетов SoundScan утром, сообщение журнала будет содержать код [ЗВУКОВОЙ СКАНЕР СООБЩАЕТ ОБ ОШИБКЕ] в нем. Это позволяет нам создавать более конкретные предупреждения для особо важных бизнес-сценариев.
Последовательность – это ключ
Наше разделение журналов на четыре категории всего в одном примере. Менее важно точно как ваши журналы разделены на категории, но самое главное, что, как только вы решите классифицировать, вы будете согласованы во всех журналах во всех приложениях в вашей системе.
Оповещение
В Single у нас настроено множество оповещений на основе наших сообщений журнала. Наиболее важным из которых является то, что мы предупреждаем о каждый и каждый ОШИБКА – инструкция журнала уровня, создаваемая приложениями. Мы делаем это по нескольким причинам. Во-первых, это обеспечивает мотивацию для своевременного исправления ошибок. Это делает ошибки настолько раздражающими, насколько это возможно! Никому не нравится, когда их телефон взрывается из-за слабых уведомлений. Во-вторых, это ставит вопрос о надлежащей обработке ошибок и улавливании исключительных случаев. Это заставляет нас серьезно задуматься об относительной серьезности сбоев во время выполнения.
Как упоминалось выше, у нас есть специальные предупреждения, настроенные в дополнение к предупреждениям уровня ОШИБКА , которые относятся к определенным критически важным бизнес-процессам. Предупреждения настроены на поиск определенных строк “кода ошибки” в сообщениях журнала. Мы решили использовать строки для кодов вместо числовых кодов, потому что это передает смысл непосредственно в сообщении и устраняет необходимость запоминать коды или ссылаться на таблицу, чтобы увидеть, что они означают.
Короткий Срок Хранения
В настоящее время мы работаем с трехдневным периодом хранения всех агрегированных журналов. Мы никогда не полагаемся на журналы, чтобы ответить на вопрос “что случилось?”. во время любых критически важных для бизнеса транзакций. Состояние решений, принятых в критических путях, фиксируется в комбинации исходящих событий и данных, сохраняемых в долговременных хранилищах (в нашем случае mysql).
Это может показаться похожим на стратегию, которую мы используем для журналов уровня DEBUG , и это так! Существует своего рода нечеткая грань между тем, что должно быть журналами, и тем, что должно быть данными. Я думаю, что все сводится к тому, нужно ли извлекать информацию позже, нужно ли ее часто запрашивать, нужно ли ее подсчитывать или комбинировать с другой информацией для принятия бизнес-решений. Аналогично стратегии оповещения о каждом журнале ошибок приложения, наличие очень короткого периода хранения также заставляет нас принимать решения на ранней стадии при создании функциональности о том, какая информация в журналах на самом деле должна быть в базе данных — потому что через три дня, если она не хранится где-то прочно, она исчезает!
В качестве примера, предположим, что мы получаем веб-справочник событий заказа от Shopify, и код решает пропустить обработку, потому что заказ не содержит позиции, которую отслеживает наша система. Каков наилучший способ сохранить историческую запись этого решения? Мы можем написать сообщение в журнале, например: “пропуск заказа № 1234 в магазине X, потому что ни одна позиция не содержит помеченных товаров”. Или мы можем записать запись в таблицу базы данных “обработанный заказ”. Предположим, что в будущем мы получим запрос в службу поддержки с вопросом об этом конкретном номере заказа и вопросом: “Что случилось? Почему пользователь не получил электронное письмо? “Если мы выберем опцию ведения журнала, мы сможем ответить на этот вопрос окончательно только в том случае, если операторы журнала все еще сохраняются. Если мы выберем опцию базы данных, мы сможем всегда ответить на этот вопрос. В качестве дополнительной опции мы могли бы опубликовать событие в такой теме, как order.skipped , чтобы указать, что заказ был пропущен. Это позволило бы нам расширить функциональные возможности системы на основе этого решения.
Журналы важны
Все это в основном означает, что журналы являются важной частью работающей программной системы и ключевым компонентом наблюдаемости этой системы. Я не знаю, является ли наша стратегия лучшей, но я думаю, что важно иметь стратегию и критически относиться к тому, что вы регистрируете. Хорошо структурированные и организованные журналы обеспечивают надежную стратегию оповещения, которая гарантирует, что у вас не будет никаких тихих сбоев. Сохранение короткого периода хранения гарантирует, что вы не полагаетесь на журналы для ответа на вопросы, на которые должны отвечать постоянные данные.
Оригинал: “https://dev.to/singlemusic/logging-strategies-34nf”