ClickHouse спонсировал этот пост. Insight Partners является инвестором ClickHouse и TNS.
Давайте будем честными: большинство журналов — это просто шум.
[INFO] Запуск процесса… наверное.
[DEBUG] Дошёл до 42 строчки — жив.
[TRACE] Функция введена. Скоро уеду.
[INFO] Пользователь нажал кнопку. Который из? Понятия не имею.
[WARN] Все в порядке, просто хотел вас предупредить.
[DEBUG] Переменная x = 7. Может измениться. Возможно, нет.
[INFO] Операция завершилась успешно (как нам кажется).
[TRACE] Цикл №12 бесконечной печали.
[DEBUG] Заполнитель для значимого сообщения.
[INFO] Грамотное выключение… за исключением случаев, когда это не так.
Как разработчики, мы слишком часто разбрасываем журналы, как конфетти: каждую запись функции, каждую переменную, каждое биение сердца. Вскоре накапливаются терабайты бессмысленных строк, заполняя информационные панели, которые никто не читает.
Мы платим миллионы долларов поставщикам средств наблюдения только за то, чтобы они складировали наш мусор. Каждая бесполезная строка журнала сжигает вычислительные ресурсы, диск и деньги. Ведение журнала без намерения — это не наблюдаемость, это мусор.
Даже при использовании современных платформ наблюдения, которые значительно повышают сжатие за счет столбчатого хранения, нет смысла протоколировать все. Это по-прежнему превращает анализ первопричин в проблему с иголкой в стоге сена, ослабляя сигнал, который вам действительно нужен — и вы будете платить больше за эту привилегию.
Нам нужно быть избирательными. Записывайте то, что помогает нам понять систему, устранять реальные проблемы или объяснять влияние на бизнес — и заткнуть все остальное.
Философия бревна
Каждая строка в журнале — это выбор, а не рефлекс. Если это не поможет вашему будущему «я» отследить ошибку в 3 часа ночи, удалите ее. Ведение журнала не является ведением журнала; пусть оно будет минимальным, ясным и действительно полезным.
Прежде чем вы нажмете logger.info, остановитесь и спросите: действительно ли я это воспринял бы?
Если нет, удалите его. Журналы — это не повествование; они доказательства. Они существуют для того, чтобы рассказать вам, о чем думала система, когда что-то пошло не так.
Журналы не следует помещать в конец цепочки наблюдения. Они не просто микроскоп для подтверждения, но и карта для открытий. Иногда самый быстрый способ получить представление — это изучить необработанный текст _ grep, отфильтровать и следовать интуиции.
Журналы вызывают любопытство — они раскрывают нюансы, которые метрики могут сгладить, и контекст, который трассировки не могут выразить. Относитесь к ним не как к последнему средству, а как к живому источнику истины, открытому для исследования с самого начала.
Контекст, или этого не произошло
«Произошла ошибка» без входных данных, идентификаторов или состояния ничего не значит. Добавьте достаточно контекста, чтобы восстановить момент — идентификаторы запросов, идентификаторы пользователей, входные параметры, имена операций. Сегодня с помощью OpenTelemetry вы получаете идентификаторы трассировки и диапазона бесплатно. Используйте их. Журналы, связанные с трассировками (и даже метриками) с помощью идентификаторов трассировки, бесконечно более ценны, чем отдельные строки текста.
Бревна не являются отдельной опорой; это заключительная глава вашего анализа первопричин. Вы предупреждаете о метриках, исследуете трассировки, а затем заходите в журналы, чтобы увидеть, что на самом деле произошло. Когда ваши журналы связаны идентификаторами трассировки и диапазона, они перестают быть шумом и становятся доказательством — строго ограниченными, контекстными и напрямую привязанными к пути одного запроса. Это намеренная наблюдаемость, а не стена текста.
Хорошо структурированный, а не произвольный текст
Протоколирование произвольного текста устарело. Структурированные журналы, будь то JSON, CSV или ключ-значение, не просто проще запрашивать; они являются основой аналитики. Когда журналы обретают структуру, появляются закономерности:
- «Эта ошибка начала резко расти на прошлой неделе».
- «В основном это происходит после события X».
- «Это предупреждение связано с этим конкретным развертыванием».
Будущее ведения журналов – это не чтение одной строки; он видит закономерность среди тысяч людей.
Структурированное ведение журналов делает построение диаграмм простым и эффективным.
Хотя многие платформы наблюдения предлагают схему при чтении, за эту гибкость приходится платить. Каждый запрос заставляет систему сканировать и анализировать необработанный текст построчно, чтобы определить структуру, которая должна была существовать изначально. Эти запросы требуют больших вычислительных затрат, медленнее и сложнее для написания пользователем.
Предварительно структурированные журналы переворачивают эту неэффективность с ног на голову. Когда ваши данные уже имеют форму, вы можете воспользоваться преимуществами столбцово-ориентированного хранилища и встроенной агрегации — запросы, визуализация и корреляция событий выполняются за миллисекунды, а не за минуты.
Знайте, когда измерять, а не только когда регистрировать
Не каждое событие попадает в поток журнала. Некоторые вещи заслуживают структуры и времени — именно для этого нужны интервалы и метрики. Если вы измеряете задержку, поток пользователей или распределенную причинно-следственную связь, вместо этого создайте интервал. Спаны фиксируют продолжительность, контекст и отношения между сервисами и сообщают вам, почему что-то было медленным или сломанным, тогда как журнал может только сообщать о том, что это произошло.
Та же логика применима и к метрикам, превращая повторяющиеся журналы в реальные сигналы, которые вы можете предупреждать и эффективно агрегировать. Если вы обнаруживаете, что записываете одно и то же сообщение сотни раз в секунду, вы не наблюдаете, а просто тратите память. Измерьте его один раз, суммируйте, и пусть ваши показатели и трассировки сделают всю тяжелую работу.
Уровни журналов предназначены для людей, а не для машин
Ведение журнала — это не личный дневник отладки; это общий артефакт для ваших будущих товарищей по команде. Каждая строка должна помочь кому-то понять, что произошло, не догадываясь, что вы имели в виду. Пишите журналы для следующего инцидента, а не для вашего текущего настроения. Ваши журналы рассказывают историю вашей системы. Сделайте это достойным прочтения, например:
- ОШИБКА: Пейдж человека. Что-то сломано.
- ПРЕДУПРЕЖДАТЬ: Неожиданно, но можно выжить. Расследуйте позже.
- ИНФОРМАЦИЯ: Рутинное поведение системы, которое стоит знать.
- ОТЛАДКА/СЛЕД: Временное мнение разработчика — редко покидайте свой ноутбук.
Будьте осмотрительны. Не отмечайте что-либо как ошибку, если это действительно не требует действий. Чрезмерное использование ERROR притупляет ваши оповещения и приучает команды игнорировать то, что важно. Каждый уровень журнала должен сообщать о намерении: что нужно исправить сейчас, что нужно посмотреть, а что можно игнорировать.
Тем не менее, ведение журнала трассировки имеет свое место. Например, за кулисами ClickHouse Cloud мы тщательно отслеживаем журналы, чтобы помочь нашим инженерам диагностировать проблемы с производительностью и оказывать поддержку клиентам в нужном масштабе. Это преднамеренное исключение, необходимое, когда вы управляете распределенной базой данных, обслуживающей тысячи рабочих нагрузок в режиме реального времени. Однако для большинства приложений такой уровень детализации не является наблюдаемостью; это просто шум.
Инструменты, которые помогут вам меньше и эффективнее вести журналы
Существуют богатые SDK и мощные фильтры, поэтому вам не нужно просто «все записывать». Используйте их.
Современные пакеты SDK OpenTelemetry Collector позволяют вам указывать, что вы регистрируете: вы можете инструментировать свой код так, чтобы создавались только значимые строки журнала, а все остальное можно фильтровать или удалять во время приема или сбора данных.
Например:
- Процессор фильтра поддерживает удаление нежелательных журналов, показателей или трассировок с помощью языка преобразования OpenTelemetry (OTTL) с такими условиями, как серьезность, атрибуты ресурсов или шаблоны контента.
- Если ваша платформа наблюдения позволяет, вы можете фильтровать данные во время агента, шлюза сборщика или во время приема, чтобы ненужные журналы никогда не записывались, не сохранялись и не индексировались (что позволяет сэкономить на вычислениях, хранении и запросах).
Если администраторы замечают, что пользователи создают несерьезные журналы, они могут агрессивно фильтровать их либо в конвейере, либо путем принудительного применения политик минимального ведения журналов. Если вы используете проприетарную платформу, они предоставляют аналогичные инструменты фильтрации или контроля приема, даже если о них не кричат публично.
Войдите целенаправленно или не регистрируйтесь вообще
Наблюдаемость не связана с объемом. Речь идет о ясности. Каждая строка журнала должна заслужить свое место, объясняя то, чего не могут объяснить метрики и трассировки. Ведение журналов без намерения просто сжигает деньги и стирает знания.
Будьте осмотрительны. Используйте структуру. Добавьте контекст. Знайте, когда измерить, когда проследить, а когда ничего не говорить. Современные инструменты позволяют легче, чем когда-либо, поддерживать дисциплину, но дисциплина все равно должна исходить от вас.
В конце концов, хорошее ведение журнала не означает фиксацию всего, что происходит. Речь идет о том, чтобы запечатлеть то, что важно.
Мы являемся создателями популярной системы управления базами данных с открытым исходным кодом, ориентированной на столбцы, которая позволяет пользователям создавать аналитические отчеты с использованием SQL-запросов в режиме реального времени. Мы понимаем, что данные растут в режиме реального времени, и считаем, что результаты должны быть быстрыми, очень быстрыми. Узнайте больше ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Майк Ши руководит наблюдением в ClickHouse, является соучредителем HyperDX и соавтором ClickStack. Майк остается практическим разработчиком, участвует в проектах OpenTelemetry и ClickStack с открытым исходным кодом и регулярно выступает на мероприятиях, посвященных наблюдениям. Он считает, что при наблюдаемости… Подробнее от Майка Ши
