Observability

Observability (наблюдаемость, наблюдательность) — это свойство системы, позволяющее оценивать её внутреннее состояние по внешним выходным данным, в первую очередь по телеметрии (логам, метрикам, трейсам). В контексте разработки и эксплуатации программного обеспечения (DevOps, SRE) наблюдаемость является ключевым принципом для понимания поведения сложных, распределённых систем, особенно в условиях микросервисной архитектуры.

История и происхождение

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

В сферу информационных технологий понятие наблюдаемости начало активно проникать в середине 2010-х годов, когда традиционные методы мониторинга (сбор метрик и проверка пороговых значений) перестали справляться с ростом сложности распределённых систем. Компании, такие как Netflix, Uber, Google, начали формировать практики, которые позже были обобщены под термином «observability». Ключевую роль в популяризации концепции сыграла компания Honeycomb и её соосновательница Хани Тидор (Charity Majors), которая в 2017 году ввела различие между мониторингом и наблюдаемостью.

Отличие от мониторинга

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

Мониторинг отвечает на вопрос «работает ли система?», а наблюдаемость — на вопрос «как именно она работает?» и «почему она работает именно так?».

Основные компоненты (три столпа)

Традиционно наблюдаемость строится на трёх типах телеметрических данных, известных как «три столпа»:

Логи (Logs)

Логи представляют собой неструктурированные или полуструктурированные текстовые записи о событиях, произошедших в системе. Каждая запись содержит временную метку и сообщение. В современных системах логи дополняются структурированными полями (JSON), что облегчает их поиск и анализ. Пример: {"timestamp": "2024-01-01T12:00:00Z", "level": "ERROR", "service": "auth", "message": "User authentication failed", "user_id": "12345"}.

Метрики (Metrics)

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

• Счётчики (Counters): накапливаемые значения (например, количество запросов).
• Гистограммы (Histograms): распределение значений (например, время ответа).
• Датчики (Gauges): мгновенные значения (например, загрузка CPU).
• Саммари (Summaries): квантили (p50, p95, p99).

Трейсы (Traces)

Трейсы (или трассировки) — это записи пути запроса через распределённую систему. Каждый трейс состоит из нескольких спанов (span), каждый из которых представляет собой единицу работы (например, вызов базы данных, вызов микросервиса). Трейсы позволяют увидеть полную картину обработки запроса, включая время выполнения каждого шага и последовательность вызовов.

Современный подход: высокоразмерные события

В последние годы концепция «трёх столпов» подвергается критике. Современный подход к наблюдаемости, продвигаемый, в частности, компанией Honeycomb, заключается в сборе высокоразмерных событий (high-cardinality events). Вместо разделения на логи, метрики и трейсы, предлагается собирать единый поток событий, каждое из которых содержит множество атрибутов (измерений). Это позволяет проводить произвольный анализ без предварительной агрегации.

Ключевые характеристики высокоразмерных данных:

• Высокая кардинальность: атрибуты могут принимать множество уникальных значений (например, user_id, request_id, session_id, IP-адрес).
• Богатый контекст: каждое событие содержит полную информацию о запросе, включая данные о пользователе, версии кода, регионе, типе устройства и т.д.
• Отсутствие предварительной агрегации: данные хранятся в сыром виде, что позволяет задавать любые вопросы задним числом.

Инструменты и технологии

OpenTelemetry (OTel)

OpenTelemetry — это стандарт де-факто для сбора телеметрии. Он предоставляет набор API, SDK и инструментов для генерации, сбора и экспорта логов, метрик и трейсов из приложений. OpenTelemetry поддерживает множество языков программирования и может отправлять данные в различные бэкенды (Honeycomb, Jaeger, Prometheus, Datadog и др.). Проект является результатом слияния двух предыдущих проектов: OpenTracing и OpenCensus.

Бэкенды для хранения и анализа

• Honeycomb: облачная платформа, специализирующаяся на высокоразмерных событиях и произвольном анализе.
• Datadog: коммерческая платформа для мониторинга и наблюдаемости, включающая APM, логи, метрики и синтетический мониторинг.
• New Relic: коммерческая платформа, предлагающая аналогичный набор функций.
• Jaeger: open-source распределённая система трассировки, разработанная в Uber.
• Grafana Tempo: open-source бэкенд для хранения трейсов, интегрируемый с Grafana.
• SigNoz: open-source альтернатива Datadog и New Relic, построенная на OpenTelemetry.

Применение в разработке и эксплуатации

Наблюдаемость применяется в следующих сценариях:

1. Отладка и расследование инцидентов: Когда система даёт сбой, наблюдаемость позволяет разработчику быстро найти корневую причину, проследив путь конкретного запроса от начала до конца.
2. Оптимизация производительности: Анализ трейсов и метрик позволяет выявить узкие места (например, медленные запросы к базе данных) и оптимизировать их.
3. Понимание поведения пользователей: Сбор событий с контекстом (например, какие действия совершает пользователь, какие ошибки он видит) позволяет улучшить пользовательский опыт.
4. Постепенное развёртывание (Canary deployment): При развёртывании новой версии кода наблюдаемость позволяет сравнить её поведение с предыдущей версией и быстро откатить изменения в случае проблем.
5. Тестирование в production: Наблюдаемость позволяет проводить эксперименты (например, хаос-инжиниринг) и понимать их влияние на систему.

Критика и ограничения

Несмотря на преимущества, наблюдаемость имеет и критикуемые аспекты:

• Стоимость: Хранение и обработка высокоразмерных данных, особенно в коммерческих облачных решениях, может быть очень дорогой.
• Сложность внедрения: Требуется значительная инженерная работа по инструментированию кода (добавление трейсов, структурированных логов) и настройке инфраструктуры.
• Шум: Слишком много данных может затруднить поиск действительно важных сигналов. Требуется умение задавать правильные вопросы.
• Необходимость культуры: Наблюдаемость эффективна только в командах, где существует культура экспериментов и готовность разбираться в сложных проблемах, а не просто гасить алерты.

Источники

1. Kalman, R. E. (1960). "On the general theory of control systems". Proceedings of the 1st International Congress on Automatic Control.
2. Majors, C., Fong-Jones, L., & Miranda, G. (2022). Observability Engineering. O'Reilly Media.
3. Документация OpenTelemetry. (opentelemetry.io).
4. Документация Honeycomb. (honeycomb.io).
5. Документация Grafana Tempo. (grafana.com/oss/tempo/).
6. Документация Jaeger. (jaegertracing.io).