Что такое Observability? Логи, метрики и трассировки

Что такое Observability?

Система может быть доступна и при этом оставаться сложной для понимания. Оформление заказа может внезапно замедлиться, один API-запрос может завершаться ошибкой только в определённом регионе, а обращение к базе данных — вести себя иначе после нового деплоя. Знать, что что-то пошло не так, полезно. Но гораздо важнее понимать почему это происходит, где возникла проблема и каких пользователей она затрагивает.

Именно для этого нужна observability.

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

Краткий ответ

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

В программных системах такие данные обычно называют телеметрией. К ней часто относятся метрики, логи и распределённые трассировки. OpenTelemetry описывает observability как возможность понимать систему извне и исследовать новые проблемы, включая вопросы, которые не были предусмотрены при первоначальном создании дашбордов и алертов. (opentelemetry.io)

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

Почему этот запрос завершился ошибкой?
Какой сервис вызвал замедление?
Началась ли проблема после деплоя?
Затронуты все пользователи или только определённый регион, endpoint, tenant или браузер?
Что изменилось в момент возникновения инцидента?

Ключевые понятия

Понятие	Что оно показывает
Метрики	Что изменяется численно
Логи	Какие события произошли
Трассировки	Как запрос проходил через систему
Профили	Где код потребляет ресурсы
Мониторинг	Требуют ли известные условия внимания
Observability	Достаточно контекста для исследования поведения системы, включая неожиданные проблемы

Логи, метрики и трассировки остаются наиболее привычными сигналами observability, но они не являются формальным ограничением того, что может входить в observability. OpenTelemetry в настоящее время описывает traces, metrics, logs и profiles среди поддерживаемых типов сигналов. (opentelemetry.io)

Observability и мониторинг

Observability и мониторинг пересекаются, но это не одно и то же.

Мониторинг обычно сосредоточен на заранее определённых измерениях и известных вопросах:

Превысил ли уровень ошибок заданный порог? Не слишком ли высока загрузка CPU? Отвечает ли сервис?

В документации Google Site Reliability Engineering мониторинг определяется как сбор, обработка, агрегация и отображение количественных данных о системе. Там же мониторинг используется для алертов, дашбордов, анализа трендов и отладки. Google также отмечает, что терминология в этой области не полностью унифицирована. (sre.google)

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

Представим, что алерт сообщает:

Checkout error rate: 8%

Мониторинг обнаружил проблему.

Observability должна помочь перейти от этого алерта к вопросам вроде:

Which checkout requests are failing? → Only requests using one payment provider. → Where do they fail? → Inside the payment-service call. → What changed? → Failures began after version 4.8.2 was deployed.

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

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

Как работает Observability

Observable-система обычно следует базовой цепочке:

Приложение и инфраструктура → инструментирование → сигналы телеметрии → сбор и обработка → хранение и анализ → дашборды, запросы, алерты и расследование

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

Метрики

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

Примеры:

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

Метрики удобны для анализа тенденций и обнаружения изменений в больших системах. Часто упоминаемые четыре золотых сигнала Google SRE — это latency, traffic, errors и saturation. (sre.google)

Однако метрики хуже подходят для описания каждой детали отдельного запроса. Здесь помогают другие сигналы.

Логи

Логи фиксируют события.

Например, запись в логе может выглядеть так:

2026-09-12T09:42:18Z
payment_failed
provider=stripe
order_id=84721
status=timeout

Логи могут содержать ценные сведения на уровне отдельных событий, но их полезность во многом зависит от структуры и контекста. OpenTelemetry рекомендует использовать структурированные логи и поддерживает такие поля, как timestamps, severity, trace IDs, span IDs, resources и attributes. (opentelemetry.io)

Миллион несвязанных строк логов сам по себе ещё не означает хорошую observability.

Распределённые трассировки

Distributed tracing позволяет проследить запрос по мере его прохождения через несколько компонентов.

Например:

Browser
  ↓
API Gateway
  ↓
Checkout Service
  ↓
Payment Service
  ↓
Database

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

Трассировка может показать:

POST /checkout              940 ms
├─ validate-cart             18 ms
├─ query-inventory           31 ms
└─ process-payment          861 ms

Теперь инженер видит, что большая часть задержки возникла внутри process-payment.

Чтобы distributed tracing оставался связанным между сервисами, контекст запроса должен передаваться вместе с самим запросом. Спецификация W3C Trace Context стандартизирует для этой цели HTTP-заголовки, включая traceparent и tracestate. (w3.org)

Почему важна корреляция

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

Предположим, метрика latency показывает резкий скачок.

В идеале инженер должен иметь возможность перейти от:

скачка метрики

к:

медленным трассировкам

затем к:

конкретному сервису

и далее к:

связанным логам

без необходимости вручную восстанавливать путь запроса через несколько систем.

Context propagation в OpenTelemetry позволяет связывать телеметрию между процессами и сетевыми границами, а также ассоциировать логи с trace и span, в рамках которых они были созданы. (opentelemetry.io)

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

INTERNAL LINK: Что такое Distributed Tracing?

Практический пример

Рассмотрим ecommerce-платформу, пользователи которой сообщают о медленном оформлении заказа.

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

Observability даёт больше возможностей для расследования.

Метрика latency показывает, что замедлился только POST /checkout. Distributed traces показывают, что большая часть времени запроса уходит на inventory service. Логи этого сервиса содержат события timeout базы данных. Метаданные деплоя показывают, что незадолго до роста задержки новый релиз изменил один из inventory-запросов.

Расследование выглядит так:

Симптом: checkout работает медленно → Измерение: latency checkout увеличилась → Возможная причина: inventory service → Подтверждение: traces показывают долгие database spans → Доказательство: logs показывают database timeouts → Исправление: исправить проблемный запрос → Повторное измерение: latency возвращается к ожидаемому уровню

Ни один отдельный сигнал не дал полный ответ. Ценность появилась благодаря возможности связать их между собой.

Как построить Observability

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

В первую очередь инструментируйте важные пользовательские сценарии и границы между сервисами. Используйте стабильные идентификаторы сервисов, записывайте значимые ошибки и latency, передавайте trace context между компонентами и добавляйте бизнес-контекст там, где он действительно помогает диагностике.

OpenTelemetry предоставляет vendor-neutral APIs, SDKs, protocols и инструменты для генерации и экспорта телеметрии. Его Collector может принимать телеметрию, обрабатывать её через настраиваемые pipelines и экспортировать в один или несколько observability backends. (opentelemetry.io)

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

Applications
     ↓
OpenTelemetry SDKs
     ↓
OpenTelemetry Collector
     ↓
Metrics / Logs / Trace Backend
     ↓
Dashboards + Alerts + Investigation

Сам OpenTelemetry не является observability backend. Хранение, выполнение запросов, анализ и визуализация выполняются другими системами. (opentelemetry.io)

INTERNAL LINK: Что такое OpenTelemetry?

Распространённые ошибки

Одна из ошибок — считать, что больше телеметрии автоматически означает лучшую observability. Большие объёмы плохо структурированных данных могут замедлить расследование и одновременно увеличить расходы на хранение и обработку.

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

Проектировать метрики тоже нужно внимательно. High-cardinality attributes, такие как request IDs, произвольный пользовательский ввод или raw URLs, могут создавать очень большое количество уникальных metric series. OpenTelemetry прямо указывает cardinality как фактор, влияющий на расход памяти для metrics. (opentelemetry.io)

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

FAQ

Observability нужна только для микросервисов?

Нет. Микросервисы делают observability особенно полезной, поскольку запросы проходят через множество компонентов, но observability также полезна для монолитных приложений, API, баз данных, frontend-приложений, background workers и инфраструктуры.

Достаточно ли одних логов?

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

Логи, метрики и трассировки — это три столпа observability?

Их часто называют тремя столпами observability, в том числе в документации Microsoft. Однако observability не следует определять исключительно через эти три типа сигналов. Современные системы также могут использовать профили и другие виды телеметрии. (learn.microsoft.com)

Что такое OpenTelemetry?

OpenTelemetry — это vendor-neutral open-source framework для инструментирования приложений и генерации, сбора и экспорта телеметрии, включая traces, metrics и logs. Сам по себе он не является backend-системой для хранения или визуализации данных. (opentelemetry.io)

Заменяет ли observability мониторинг?

Нет. Мониторинг по-прежнему необходим для health checks, дашбордов, анализа трендов, алертов, SLO и известных условий отказа. Observability расширяет возможности исследования поведения системы в тех случаях, когда ответ ещё не заложен в алерт или дашборд.

Итог

Observability означает способность понимать, что происходит в работающей системе, на основе данных, которые она генерирует.

Метрики показывают закономерности. Логи описывают события. Трассировки связывают операции в распределённых системах. Контекст объединяет эти сигналы.

Цель заключается не в максимальном количестве телеметрии, а в достаточном объёме значимой и связанной телеметрии, чтобы эффективно перейти от «что-то сломалось» к «вот что произошло и почему».

Sources

OpenTelemetry — Observability Primer, updated 2026. OpenTelemetry Observability Primer (opentelemetry.io)
OpenTelemetry — What is OpenTelemetry?, 2026. What is OpenTelemetry? (opentelemetry.io)
OpenTelemetry — Signals, updated March 10, 2026. OpenTelemetry Signals (opentelemetry.io)
OpenTelemetry — Context Propagation, updated 2026. OpenTelemetry Context Propagation (opentelemetry.io)
OpenTelemetry — Collector, 2026. OpenTelemetry Collector (opentelemetry.io)
OpenTelemetry — Metrics, 2026. OpenTelemetry Metrics (opentelemetry.io)
W3C — Trace Context, W3C Recommendation, November 23, 2021. W3C Trace Context (w3.org)
Google — Site Reliability Engineering: Monitoring Distributed Systems, Rob Ewaschuk. Google SRE — Monitoring Distributed Systems (sre.google)
Microsoft — .NET Observability with OpenTelemetry. Microsoft .NET Observability with OpenTelemetry (learn.microsoft.com)

Что такое Observability? Логи, метрики и трассировки