Логи, метрики и трассировки: что собирать и зачем

Если запрос к API стал медленным, график метрик может показать рост задержки, лог — ошибку базы, а трассировка — что именно запрос провёл две секунды в ожидании соединения. По отдельности эти сигналы оставляют пробелы. На практике задача не в том, чтобы собирать всё подряд, а в том, чтобы связать три источника так, чтобы дежурный быстро нашёл причину и понял масштаб проблемы.

У каждого сигнала своя работа

Логи — записи о событиях: ошибка при оплате, отказ в авторизации, изменение статуса заказа. Их удобно читать, когда вы уже знаете, где искать, или хотите изучить конкретный случай. Но поиск по огромному объёму логов дорог, а отсутствие записи не всегда означает, что события не было: нужный уровень могли отключить, а приложение могло завершиться до отправки данных.

Метрики — числовые ряды, собранные за интервалы времени. Они отвечают на вопросы «сколько ошибок?» и «насколько выросла задержка?». По метрикам проще строить графики и оповещения: они компактнее подробных логов. Но среднее значение может скрыть медленные запросы, а сама метрика редко объяснит, какой конкретно этап подвёл.

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

Термин: кардинальность — количество разных значений, которые может принимать измерение. Например, метрика с меткой «код ответа» обычно имеет ограниченное число вариантов, а метка с уникальным ID пользователя может создать миллионы временных рядов и резко увеличить стоимость хранения.

Метрики показывают, что проблема есть и насколько она велика. Трассировки помогают найти участок, где она возникла. Логи сохраняют подробности конкретного события.

Как связать сигналы, а не просто собрать их

Для нового сервиса разумная основа — инструментировать приложение через OpenTelemetry и передавать сигналы в подходящие хранилища. OpenTelemetry — проект и набор спецификаций для сбора телеметрии; его SDK доступны для разных языков. Здесь речь о линейке OpenTelemetry SDK 1.x: возможности и настройки зависят от языка и конкретной версии пакета, поэтому перед внедрением сверяйте примеры с документацией именно для своего SDK. Сам OpenTelemetry не является готовым хранилищем и интерфейсом для анализа.

Связь начинается с контекста запроса. Когда приложение создаёт трассировку, оно может передавать идентификатор трассы дальше — в соседний сервис и в соответствующую запись лога. Тогда вы открываете ошибку, находите её Trace ID и переходите к полному пути запроса. Без такого контекста логи и трассировки остаются двумя отдельными архивами.

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

Выбор инструмента зависит от вопроса

Популярная связка — Prometheus для метрик, Loki для логов и Tempo для трассировок, с Grafana для просмотра. Это не обязательный комплект и не единственный вариант. Перед выбором проверьте требования к хранению, запросам, авторизации, резервному копированию и интеграции с уже работающей платформой. OpenTelemetry Collector может принимать, обрабатывать и передавать телеметрию, но его конфигурацию нужно сверять с документацией той версии, которую вы разворачиваете: релизы Collector выходят часто.

Порядок внедрения: от сигнала к поиску причины

1. Начните с пользовательского результата. Выберите несколько ключевых операций: например, создание заказа или вход в личный кабинет. Для каждой задайте вопрос, на который должен ответить мониторинг: «какова доля ошибок?» или «где задерживается запрос?». Проверка: у каждой выбранной операции есть понятный способ увидеть сбой, а не просто список датчиков.
2. Добавьте метрики задержки, трафика и ошибок. Считайте запросы, измеряйте их длительность и отдельно фиксируйте неуспешные ответы. Для задержки смотрите распределение и высокие перцентили, а не только среднее: небольшая доля очень медленных запросов может портить опыт пользователей, оставаясь незаметной в среднем. Проверка: вы можете отличить рост нагрузки от роста доли ошибок.
3. Запишите события, нужные для расследования. Включите время, название сервиса и операции, уровень важности, результат и контекст ошибки. Не отправляйте в телеметрию пароли, токены и другие секреты; персональные данные собирайте только при обоснованной необходимости и с учётом требований к их обработке. Проверка: по тестовой ошибке находится запись с достаточным контекстом, но без секретов.
4. Добавьте трассировки на границах компонентов. Проследите путь запроса через входной сервис, вызовы соседних сервисов и обращения к хранилищу. Настройте передачу контекста между ними. Проверка: трассировка тестового запроса содержит ожидаемые этапы, а дочерние операции связаны с родительской.
5. Свяжите лог с трассировкой и проверьте оповещения. Добавьте в записи идентификатор трассы, если используемая библиотека и схема логирования позволяют это сделать. Настройте оповещение на пользовательский симптом, например устойчивый рост ошибок, а не на любое единичное исключение. Проверка: тестовый инцидент приводит к сигналу, после которого можно открыть метрику, найти трассировку и перейти к связанному логу.

Что ломается первым

Собирают слишком много

Подробные логи и трассировки на каждый запрос быстро увеличивают объём данных. Сначала определите сроки хранения и допустимую стоимость, затем решите, какие события нужно сохранять всегда, а какие — выборочно. Уровень детализации, частоту выборки и сроки хранения проверяйте на реальной нагрузке: универсального безопасного значения нет.

Оповещения сообщают о симптоме без действия

Сигнал «CPU выше порога» может быть полезен, но сам по себе не объясняет, страдают ли пользователи. Оповещение должно отвечать на три вопроса: что сломалось, насколько это влияет на сервис и куда смотреть дальше. Если на сигнал нельзя отреагировать конкретным действием, пересмотрите его.

Метрики получают метку с уникальным значением

Метка с URL, ID заказа или текстом ошибки создаёт множество отдельных рядов. Последствие — рост потребления памяти и диска, замедление запросов к хранилищу или отказ в приёме данных. Ограничьте метки небольшим набором категорий, а уникальные идентификаторы оставьте для логов и трассировок.

Когда что выбирать

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

В продакшене проверьте не только сбор, но и путь данных: что произойдёт при недоступности коллектора, переполнении очереди или остановке хранилища. Телеметрия не должна незаметно съедать ресурсы приложения или превращаться в канал утечки данных. Способ буферизации и поведение при потере связи зависят от конкретных SDK, Collector и конфигурации.

Что делать дальше

Выберите одну критичную пользовательскую операцию и проведите через неё тестовый запрос. Убедитесь, что вы видите метрику задержки и ошибок, трассировку с ключевыми этапами и связанный лог. Затем намеренно вызовите безопасную тестовую ошибку и проверьте весь путь расследования. После этого измерьте объём телеметрии и нагрузку на приложение и хранилища — до расширения покрытия.