Observability

К словарю | К списку вопросов

Observability, или наблюдаемость, — это способность понять внутреннее состояние системы по её внешним сигналам и быстро объяснить её поведение, в том числе при возникновении заранее неизвестной проблемы.

К таким сигналам относятся:

• метрики;
• логи;
• распределённые трейсы;
• ошибки и события;
• состояние компонентов и зависимостей;
• технические и бизнес-показатели;
• данные о релизах и изменениях конфигурации.

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

Monitoring и observability

Monitoring обнаруживает заранее известные нежелательные состояния:

• сервис недоступен;
• error rate превысил порог;
• latency выросла;
• заканчивается память;
• увеличился размер очереди.

Observability помогает исследовать причину:

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

Monitoring преимущественно отвечает на вопрос «Что произошло?», а observability — «Почему это произошло и как это доказать?». Это не противоположные подходы: качественный monitoring является частью общей наблюдаемости системы.

Основные сигналы

Metrics

Метрики — числовые показатели, изменяющиеся во времени:

• количество запросов;
• error rate;
• latency и её перцентили;
• CPU и память;
• число соединений с базой данных;
• размер очереди и время ожидания;
• Kafka consumer lag;
• cache hit rate;
• число успешных бизнес-операций.

Метрики подходят для дашбордов, анализа тенденций и алертов. Они хорошо показывают масштаб и момент возникновения проблемы, но часто не объясняют её причину.

Logs

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

• timestamp и severity;
• service name и environment;
• request ID, trace ID или correlation ID;
• тип операции и результат;
• код ошибки и длительность;
• идентификатор версии или релиза.

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

Traces

Распределённый trace показывает путь одного запроса через компоненты системы. Каждый span описывает отдельную операцию: вызов сервиса, запрос к базе данных, обращение к кэшу или внешнему API.

Трейсы позволяют увидеть:

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

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

Не только три столпа

Метрики, логи и трейсы — основные телеметрические сигналы, но observability ими не ограничивается. Для расследования также важны:

• профилирование и continuous profiling;
• события deployment и изменения конфигурации;
• feature flags;
• topology и dependency maps;
• audit events;
• данные о пользовательском результате;
• runbooks и информация о владельцах сервисов.

Главное не количество источников, а возможность связать их единым контекстом.

Признаки плохой observability

• логи неструктурированы или не содержат контекста;
• correlation ID теряется между сервисами;
• метрики агрегированы слишком грубо;
• невозможно определить затронутых пользователей;
• трейсы не проходят через очереди и внешние вызовы;
• алерты шумят и не указывают на пользовательское влияние;
• телеметрию нельзя связать с релизом;
• дашборды показывают состояние инфраструктуры, но не результат бизнес-операций;
• метрики имеют неконтролируемую cardinality и становятся слишком дорогими.

Пример

После релиза пользователи сообщают о медленном checkout.

Без достаточной наблюдаемости команда видит только рост общей latency и вручную проверяет frontend, backend, базу данных и внешние зависимости.

При хорошей наблюдаемости можно установить:

• latency endpoint /checkout выросла с 300 ms до 4,5 s после конкретного релиза;
• основная задержка возникает при вызове платёжного провайдера;
• проблема затрагивает преимущественно пользователей из определённого региона;
• error rate пока не вырос, но длительность вызова приблизилась к timeout;
• откат изменения восстанавливает исходную latency.

Эти данные позволяют выбрать обоснованное действие: откатить релиз, изменить timeout policy, включить fallback или ограничить проблемный сценарий.

Ответ на собеседовании

Observability — это способность системы давать достаточно внешних сигналов, чтобы команда могла понять её внутреннее состояние, найти причину проблемы и оценить влияние на пользователей. Это не только метрики, логи и трейсы, но и качество контекста: correlation ID, structured logging, связь с релизами, бизнес-метрики и возможность проследить путь конкретного запроса через систему. Monitoring сообщает о заранее известных симптомах, а observability позволяет исследовать в том числе те проблемы, которые мы заранее не предусмотрели.

На уровне Lead observability является частью production readiness. До релиза нужно ответить на вопросы:

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

Ключевая мысль: monitoring показывает симптом, а observability даёт данные для доказательного поиска причины.