Observability Engineering: наблюдаемость без трёх столпов

О чём книга

Чарити Мейджорс, Лиз Фонг-Джонс и Джордж Миранда написали книгу, которая переопределяет слово «наблюдаемость» для индустрии разработки софта. Авторы — основатели и инженеры Honeycomb, компании, которая строит инструменты наблюдаемости, и это важный контекст: книга продвигает определённый подход, и авторы прямо в нём заинтересованы. Тем не менее их аргументация достаточно сильна, чтобы книга стала одной из самых цитируемых в области operations.

Книга вышла в 2022 году в O’Reilly, а в 2024 году авторы выпустили второе издание, расширив раздел про OpenTelemetry и добавив больше практических примеров.

Ключевые идеи

Наблюдаемость — это свойство системы

Мейджорс настаивает на чёткой границе между мониторингом и наблюдаемостью. Мониторинг работает с known unknowns: вы заранее знаете, что может сломаться, и настраиваете алерты на конкретные пороговые значения. Наблюдаемость работает с unknown unknowns: вы можете задать системе произвольный вопрос и получить ответ без необходимости деплоить новый код для сбора дополнительных данных.

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

Против «трёх столпов»

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

Мейджорс многократно критиковала этот подход. Бен Сигельман из LightStep тоже разобрал проблему и объяснил, почему метрики, логи и трейсы — это типы телеметрии, а не столпы чего бы то ни было. Три отдельных инструмента для трёх типов данных не дают вам наблюдаемости, потому что контекст теряется при переходе от одного инструмента к другому.

Wide structured events

Вместо трёх разрозненных потоков данных авторы предлагают единый примитив: широкое структурированное событие (wide structured event). Когда запрос проходит через систему, вы собираете все метаданные в одно событие с произвольным количеством полей. Зрелый сервис с хорошей инструментацией отправляет события с 200-400 полями на каждый запрос.

Ключевая идея: high cardinality. Поля вроде userId, requestId, sessionId, tenantId имеют высокую кардинальность (миллионы уникальных значений), и именно они оказываются самыми полезными при отладке. Традиционные инструменты метрик (Prometheus, Graphite) плохо справляются с high cardinality, потому что каждое уникальное значение создаёт новую временную серию. Авторы строят аргументацию вокруг того, что инструмент наблюдаемости должен работать с high cardinality как с нормой, а не как с крайним случаем.

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

Авторы посвящают несколько глав организационным аспектам. Команды, которые внедряют наблюдаемость, начинают деплоить чаще, потому что перестают бояться продакшена. Когда инженер знает, что сможет за минуты найти причину проблемы, барьер для деплоя снижается. Мейджорс связывает это с концепцией «you build it, you run it»: команда, которая владеет сервисом и имеет инструменты для его наблюдения, принимает лучшие решения о том, когда и как деплоить.

Observability 1.0 и 2.0

Мейджорс ввела термины «Observability 1.0» (три столпа, три отдельных инструмента, корреляционные ID между дашбордами) и «Observability 2.0» (единый источник правды на основе широких структурированных событий с произвольной нарезкой данных в реальном времени).

Что можно применить

Начните с инструментации. Добавьте контекст к каждому запросу: кто вызвал, откуда, какой тенант, какой feature flag активен. Не ограничивайтесь стандартными полями HTTP-запроса. Чем больше полей вы добавите в событие, тем больше вопросов сможете задать потом.

Если вы используете OpenTelemetry, настройте экспорт трейсов с кастомными атрибутами. Добавляйте бизнес-контекст: тип подписки пользователя, размер организации, регион. Когда возникнет проблема, вы сможете сказать «этот баг затрагивает только enterprise-пользователей в европейском регионе» за секунды, а не за часы.

Пересмотрите свои дашборды. Если у вас двадцать дашбордов в Grafana, на которые никто не смотрит, у вас мониторинг, а не наблюдаемость. Попробуйте подойти к отладке иначе: вместо того чтобы открывать заранее построенный дашборд, начните с вопроса «какие запросы сейчас медленнее всего?» и group by по разным полям, пока не найдёте паттерн.

Критика

Рецензенты на Goodreads отметили дисбаланс: книга тратит слишком много глав на объяснение разницы между мониторингом и наблюдаемостью и слишком мало — на конкретные инженерные приёмы. Некоторые читатели написали, что в книге «много про observability и мало про engineering».

Авторы — основатели Honeycomb, и книга продвигает подход, который совпадает с продуктом Honeycomb. Wide structured events, high cardinality, отказ от метрик как первичного источника данных — всё это архитектура Honeycomb. Читатель должен держать этот конфликт интересов в голове.

Категоричное противопоставление мониторинга и наблюдаемости раздражает практиков. Большинство инженерных команд работают с гибридным стеком: Prometheus для метрик, ELK или Loki для логов, Jaeger или Tempo для трейсов. Книга по сути говорит им: «вы делаете всё неправильно». Это отпугивает аудиторию, которая могла бы выиграть от частичного внедрения предложенных идей.

Ценовой вопрос тоже стоит упомянуть. Отправка широких событий с сотнями полей на каждый запрос при нагрузке в тысячи RPS генерирует огромные объёмы данных. Авторы обсуждают семплирование, но не углубляются в экономику: сколько стоит хранение и обработка такого объёма телеметрии для компании среднего размера.

При всей критике книга изменила разговор об операционных практиках. До неё «наблюдаемость» была синонимом мониторинга в маркетинговых материалах вендоров. После неё инженеры начали задавать правильный вопрос: «могу ли я с помощью своих инструментов ответить на произвольный вопрос о поведении системы?» И одного этого вопроса достаточно, чтобы изменить подход к инструментации.