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

О чём книга

Чарити Мейджорс, Лиз Фонг-Джонс и Джордж Миранда переопределяют слово «наблюдаемость» для индустрии разработки софта. Авторы — основатели и инженеры Honeycomb, компании, которая строит инструменты наблюдаемости, так что книга продвигает определённый подход, в котором авторы заинтересованы. Аргументация при этом достаточно сильна, чтобы Observability Engineering стала одной из самых цитируемых работ в области 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 генерирует огромные объёмы данных. Семплирование авторы обсуждают, но в экономику не углубляются: сколько стоит хранение и обработка такого объёма телеметрии для компании среднего размера — вопрос открытый.

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