Логи, метрики и трассировки: что нужно видеть в системе до эксперимента

20.08.2026 · DevOps и CI/CD

Observability часто начинают настраивать после проблемы: релиз уже выполнен, показатель изменился, и команда пытается понять, что произошло. Для инженерного эксперимента порядок лучше развернуть. Сначала нужно решить, какие состояния и события система умеет показывать, и только затем вносить изменение.

Логи, метрики и трассировки отвечают на разные вопросы. Метрика показывает динамику измеряемого свойства. Лог фиксирует отдельное событие и его контекст. Trace связывает операции одного запроса между компонентами распределённой системы. До эксперимента важно не просто иметь эти данные, а уметь связать их с конкретной версией, окружением и моментом изменения.

Observability начинается не с дашборда, а с вопроса к системе

OpenTelemetry определяет observability как возможность понимать внутреннее состояние системы по её внешним данным. Для этого приложение должно быть инструментировано и выдавать telemetry: traces, metrics, logs и другие поддерживаемые сигналы.

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

Поэтому до запуска проверки полезно сформулировать несколько диагностических вопросов:

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

Telemetry имеет ценность не количеством записей, а тем, какие проверяемые вопросы она позволяет задать системе.

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

Метрика — это измерение, которое меняется во времени. Она удобна для ответа на вопросы вроде:

как изменилась latency;
увеличилась ли частота ошибок;
сколько запросов получает сервис;
насколько загружены ограниченные ресурсы.

Google SRE предлагает четыре базовых направления мониторинга пользовательского сервиса: latency, traffic, errors и saturation. Это не универсальный список всех показателей приложения, но хорошая отправная точка, когда нужно увидеть реакцию системы на изменение.

Группа	Что помогает увидеть
Latency	Сколько времени занимает обслуживание запроса или операции
Traffic	Какой объём работы получает система
Errors	Какая часть операций завершается ошибкой или некорректным результатом
Saturation	Насколько система приближается к ограничениям ресурса или ёмкости

Для эксперимента важно не только выбрать показатель, но и убедиться, что он существовал до изменения. Если метрику начали собирать одновременно с новым релизом, нормального ряда «до» уже нет.

Метрика должна быть привязана к тому состоянию системы, которое мы сравниваем

Представим, что stable и canary работают одновременно. Общая latency всего сервиса меняется незначительно. Это ещё не означает, что новая версия ведёт себя так же.

Если telemetry позволяет разделить данные по версии, можно увидеть:

service.version = 1.8.4 → stable
service.version = 1.9.0 → canary

OpenTelemetry определяет service.version как стандартный resource attribute для версии компонента. Для среды можно использовать deployment.environment.name, например staging или production. service.instance.id позволяет различать отдельные одновременно работающие экземпляры одного сервиса.

Для экспериментальной telemetry особенно полезны идентификаторы:

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

Без этой привязки график показывает состояние системы в целом, но не обязательно состояние того объекта, который менялся.

Labels помогают разделять данные, но ими легко создать другую проблему

В time-series monitoring измерение часто разбивается на серии с помощью labels. Так можно сравнивать версии, методы API, классы ответов и другие заранее выбранные измерения.

Но label не стоит использовать как контейнер для любого контекста.

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

уникальный request ID;
user ID;
случайный UUID;
полный URL с неограниченным набором параметров;
уникальное сообщение ошибки.

Такие данные могут быть полезны в логах или traces, но часто плохо подходят как labels для каждой metric series.

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

Логи нужны там, где одной временной серии уже недостаточно

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

Лог фиксирует событие. Хорошая запись позволяет восстановить хотя бы:

время;
уровень или тип события;
компонент-источник;
смысл события;
существенные атрибуты контекста;
идентификаторы для связи с другими telemetry-сигналами.

Google SRE отмечает, что логирование даёт возможность понять, что процесс делал в конкретный момент. Для распределённой системы записи иногда приходится анализировать сразу по нескольким процессам.

Для эксперимента это особенно важно около момента вмешательства. В журнале должно быть видно не только «ошибок стало больше», но и когда произошёл deploy, переключился feature flag, изменился rollout или был выполнен другой управляемый шаг.

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

Строка:

Something went wrong during request

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

Структурированная запись позволяет отделить стабильные поля от текстового сообщения:

{
  "timestamp": "...",
  "service": "checkout",
  "service_version": "1.9.0",
  "event": "payment_request_failed",
  "trace_id": "...",
  "span_id": "..."
}

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

При этом в telemetry нельзя без необходимости переносить секреты, пароли, токены и персональные данные. Полнота наблюдения не требует записывать всё содержимое запроса.

Trace отвечает на вопрос, через какие операции прошёл конкретный запрос

В распределённой системе один внешний запрос может пройти через API gateway, приложение, базу данных, очередь и несколько внутренних сервисов.

На общем графике видно итоговую latency. В логах — отдельные события компонентов. Trace добавляет структуру пути.

OpenTelemetry описывает trace как путь запроса через приложение. Отдельные единицы работы представлены spans, а context propagation позволяет сохранять связь при переходе между процессами и сетевыми границами.

Упрощённо:

HTTP request
   ↓
frontend span
   ↓
checkout span
   ↓
database span
   ↓
response

Если после изменения выросла длительность только одного участка, trace помогает локализовать его намного точнее, чем общий показатель сервиса.

Для эксперимента особенно полезна связь logs ↔ traces

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

В OpenTelemetry для этого используются TraceId и SpanId. Logging data model позволяет хранить их вместе с LogRecord, а SDK может добавлять trace context в запись автоматически.

Тогда диагностика выглядит последовательно:

на metric-графике обнаружено изменение;
выбран интересующий период и версия;
найден конкретный trace;
по trace_id и span_id открыты связанные события в логах;
восстановлен контекст конкретного запроса.

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

Correlation должна работать до эксперимента, а не появляться после него

Если trace IDs начали писать в логи только после того, как обнаружилась проблема, старые события уже не станут связанными задним числом.

То же относится к версии сервиса, среде и другим атрибутам.

Поэтому перед изменением полезно проверить не наличие отдельных систем telemetry, а реальные переходы между ними:

можно ли из dashboard перейти к нужной версии;
можно ли от проблемного trace найти соответствующие логи;
видно ли, какой сервис и экземпляр породили запись;
сохраняется ли context propagation через сетевые границы;
одинаково ли называются основные сущности в разных сигналах.

OpenTelemetry Semantic Conventions как раз задают общие имена и значения для типовых сущностей. Последовательная схема именования упрощает сопоставление telemetry из разных компонентов.

Sampling означает, что trace-система может видеть не каждый запрос

На небольшом сервисе можно сохранять все traces. На большой нагрузке это может оказаться слишком дорого по объёму данных и обработке.

OpenTelemetry поддерживает sampling — выбор части traces для записи и экспорта. Это позволяет контролировать объём telemetry.

Для эксперимента из этого следует важное ограничение: отсутствие trace не всегда означает отсутствие события. Возможно, конкретный запрос просто не попал в выборку.

Перед проверкой нужно понимать:

используется ли sampling;
какова его стратегия;
одинакова ли она для сравниваемых состояний;
не приведёт ли слишком редкая выборка к недостатку данных в небольшой canary-группе.

Если canary обслуживает лишь малую долю трафика, а tracing дополнительно сохраняет малую долю запросов, фактическое число traces новой версии может оказаться намного меньше ожидаемого.

Observability-инструмент сам способен влиять на систему

Дополнительное логирование, profiling и детальная instrumentation имеют стоимость. Они используют CPU, память, сеть, диск и backend-хранилище.

Google SRE в методологии troubleshooting прямо приводит пример: включение подробного логирования способно увеличить latency и тем самым изменить наблюдаемое поведение.

Поэтому нельзя считать telemetry полностью внешним наблюдателем.

Если перед состоянием B команда включила подробный debug logging, которого не было в состоянии A, сравниваются уже две разницы:

изменение приложения + изменение instrumentation.

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

Перед экспериментом нужно увидеть нормальное состояние, а не только ошибки

Система, которая пишет данные только во время сбоя, плохо подходит для сравнения «до» и «после».

Нужен рабочий baseline: как те же metrics, logs и traces выглядят при обычном поведении.

До эксперимента полезно проверить:

Что проверяем	Что должно быть понятно
Метрики	Как выглядит обычная динамика latency, traffic, errors и saturation
Версии	Можно ли разделить telemetry разных build или release
Логи	Есть ли необходимые события и стабильные поля контекста
Traces	Прослеживается ли путь через важные компоненты
Correlation	Связываются ли logs и traces через общие идентификаторы
Время	Можно ли сопоставить момент изменения с telemetry по единой временной шкале
Sampling	Понятно ли, какая часть trace-данных реально сохраняется

Этот набор не заменяет фиксацию исходного состояния системы. Он дополняет её: baseline описывает, что было развёрнуто, а telemetry показывает, как это состояние вело себя во времени.

Дашборд не должен быть единственным артефактом эксперимента

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

Поэтому для важного эксперимента стоит сохранять:

точный временной диапазон;
версию или вариант системы;
запросы к telemetry, если они существенны для вывода;
ссылки или идентификаторы traces;
выбранные лог-события;
описание применённого sampling;
момент изменения системы.

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

Что observability может показать, а что не может доказать сама

Telemetry хорошо отвечает на вопросы:

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

Но даже очень подробные logs, metrics и traces не превращают временную последовательность автоматически в причинное доказательство.

Если после deploy выросла latency и traces показывают более долгую операцию в новой версии, это сильное наблюдение. Но окончательная интерпретация всё равно зависит от дизайна проверки, других изменений и альтернативных объяснений.

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

Минимальная observability-подготовка перед изменением

Определить вопрос. Какое поведение системы нужно будет увидеть после изменения.
Проверить baseline metrics. Нужные измерения должны существовать до эксперимента.
Идентифицировать версию. Telemetry должна позволять отличить сравниваемые состояния.
Проверить логи. Существенные события должны быть структурированы и иметь понятный контекст.
Проверить traces. Важный путь запроса должен проходить через нужные spans.
Связать сигналы. Trace ID, Span ID и единые resource attributes должны позволять переходить между источниками.
Понять sampling. Нужно знать, какую часть запросов tracing действительно сохраняет.
Проверить стоимость instrumentation. Режим наблюдения не должен незаметно различаться между A и B.
Сохранить запросы и временные границы. Результат должен оставаться проверяемым после завершения эксперимента.

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

Источники

Технические источники проверены 19 августа 2026 года. Использованы официальные материалы OpenTelemetry, Google SRE и Prometheus.