Наблюдаемость и телеметрия

§1Вопрос, для которого нет готовой панели

Мониторинг из главы 1.2 отвечает на вопросы, заданные заранее. Команда решила, что важны доля ошибок и длительность запросов, настроила измерения, построила панели и правила. Пока проблема укладывается в эти вопросы, панели её показывают.

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

У этой способности есть точное определение. Оно дано в следующем разделе.

§2Наблюдаемость

Наблюдаемость (observability) — свойство системы: насколько по её внешним данным можно понять, что происходит внутри. Для инженера это возможность задать новый вопрос о поведении сервиса и получить ответ из уже собранных данных, не меняя код.

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

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

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

Первоисточник: OpenTelemetry · Observability primer ↗

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

§3Как связаны мониторинг и наблюдаемость

Часто их противопоставляют так: мониторинг отвечает на вопрос «что сломалось», наблюдаемость — «почему». Для первого знакомства это подходит, но на практике граница размыта. Хорошо подобранные показатели мониторинга часто сразу подсказывают причину, а записи о событиях без нужного контекста причину не объясняют.

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

1. Получить уведомление

   Доля ошибок /products выросла. Опора — мониторинг, заранее настроенное правило.

2. Уточнить область

   Какая версия, маршрут, экземпляр. Опора — метрики с разбивкой по признакам.

3. Найти отдельные неуспешные запросы

   Опора — логи с идентификатором запроса.

4. Посмотреть, на каком этапе ушло время

   Опора — трасса запроса.

5. Добавить недостающее измерение

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

После каждого разбора ясно, каких данных не хватило. Если добавить их в код, следующая похожая проблема разбирается быстрее. Так наблюдаемость сервиса растёт от инцидента к инциденту.

В каждом шаге разбора инженер опирается на данные. Следующий раздел называет эти данные и их виды.

§4Телеметрия: данные, которые система сообщает о себе

Телеметрия — данные о работе системы, которые она создаёт во время работы и передаёт для хранения и анализа. Слово составлено из греческих «теле» — далеко и «метрон» — мера: измерение на расстоянии.

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

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

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

Кроме трёх основных сигналов, есть и другие. Например, профили показывают, какие функции программы тратят процессорное время и память. В этой теме они не понадобятся.

Первоисточник: OpenTelemetry · Signals ↗

Сигналы названы. Остаётся вопрос, откуда они берутся в программе.

§5Инструментация: откуда берутся данные

Телеметрия сама не появляется. Если в коде обработчика никто не измерил длительность, никакая система мониторинга её не покажет: измерение, запись о событии или этап трассы должна создать сама программа.

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

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

started = time.perf_counter()
spans = []

async def stage(name, seconds):
    offset = time.perf_counter() - started
    begin = time.perf_counter()
    await asyncio.sleep(seconds)
    spans.append({"name": name, "offset_ms": round(offset * 1000, 3),
                  "duration_ms": round((time.perf_counter() - begin) * 1000, 3)})

time.perf_counter() возвращает показания точного таймера в секундах. С часами на стене это число не связано, но разность двух показаний даёт длительность промежутка. Переменная started хранит момент начала всего запроса.

Без этих строк обработчик работал бы так же, но о медленном запросе была бы известна только общая длительность. С ними видно, что почти все три секунды ушли на ожидание зависимости.

Первоисточник: OpenTelemetry · Instrumentation ↗

Инструментация создаёт отдельные записи. Чтобы из них сложилась история одного запроса, записи нужно связать между собой.

§6Время и идентификатор связывают события

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

{
  "timestamp": "2026-09-15T13:06:29.890773+00:00",
  "level": "ERROR",
  "service": "products-api",
  "event": "request_completed",
  "status": 500,
  "request_id": "2797ad2d8174461eb96c36e59f8126da"
}

timestamp ставит событие на общую шкалу времени. Окончание +00:00 означает время по UTC — всемирному координированному времени без смещения часового пояса. Если все компоненты пишут время в UTC, записи с серверов в разных часовых поясах сравнивают без пересчёта.

request_id связывает события одного запроса. Сервис создаёт его функцией uuid.uuid4().hex: это 32 шестнадцатеричных символа, случайных для каждого запроса. Вероятность совпадения двух таких значений настолько мала, что на практике её не учитывают. Тот же идентификатор сервис возвращает клиенту в заголовке X-Request-ID. Пользователь пересылает его в поддержку, и разработчик находит по нему все записи.

Когда запрос проходит через несколько сервисов, идентификатор передают дальше, иначе цепочка оборвётся на первом же вызове. Передачу контекста между сервисами называют распространением контекста (context propagation). В распределённой трассировке для этого два идентификатора: trace_id — общий для всей операции и span_id — свой у каждого этапа. Сервис стенда состоит из одного процесса, поэтому ему хватает одного request_id.

Первоисточник: OpenTelemetry · Context propagation ↗

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

§7Почему идентификатор запроса не добавляют в метрику

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

Метрику хранят как набор временных рядов. Признаки, по которым её делят, называют метками (labels). Каждое уникальное сочетание значений меток создаёт отдельный временной ряд. Метрика запросов с метками route и status на стенде хранит два ряда: для статуса 200 и для статуса 500.

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

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

Сервис стенда создаёт телеметрию своим кодом. В рабочих системах для этого есть общий стандарт.

§8OpenTelemetry: общий способ создавать и передавать телеметрию

Раньше каждая система мониторинга предлагала свои библиотеки для инструментации, и при смене хранилища трасс приходилось переписывать код во всех сервисах. В 2019 году проекты OpenTracing и OpenCensus объединились в OpenTelemetry, чтобы у всех был один способ.

OpenTelemetry — открытый стандарт и набор инструментов для создания, сбора и передачи телеметрии: метрик, логов и трасс. Проект развивается в фонде CNCF и не привязан к конкретному хранилищу.

OpenTelemetry состоит из нескольких частей, каждая отвечает за свой участок пути данных.

Между частями данные идут по протоколу OTLP. Библиотеки инструментации подключаются к SDK и измеряют типовые операции фреймворков и драйверов.

Хранилища в этой цепочке — отдельные системы. OpenTelemetry данные не хранит и графики не строит. Метрики сохраняет, например, Prometheus, трассы — Jaeger или Grafana Tempo, логи — Loki или Elasticsearch. OpenTelemetry отвечает за то, чтобы данные были созданы одинаково и доставлены по адресу.

Сервис этой темы OpenTelemetry не использует: этапы запроса измеряет короткая функция stage, разобранная выше. Так механизм виден целиком, без библиотек. Термины при этом те же, что в OpenTelemetry, и при переходе на стандартную инструментацию новые понятия не понадобятся.

Первоисточник: What is OpenTelemetry? ↗

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

§9Где телеметрия искажается и теряется

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

Выборку трасс называют сэмплированием (sampling). Сервис с десятью тысячами запросов в секунду не может хранить трассу каждого, поэтому сохраняет, например, один процент трасс или все трассы с ошибками. Это нужно помнить при выводах: сто сохранённых медленных трасс не значат, что все запросы медленные, если медленные сохраняли в первую очередь.

§10Частые ошибки

§11Проверьте себя

§12Шпаргалка