Почему логи, метрики и трассировки по-прежнему не обеспечивают реальную наблюдаемость

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

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

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

Обещание «трех столпов»

Прежде чем критиковать эту модель, давайте точно определим, что она обещает.

Логи дают вам запись отдельных событий с отметкой времени: была вызвана функция, поступил запрос, произошла ошибка. Они богаты деталями и легко добавляются в код. Проблема заключается в объеме — сервис с высоким трафиком может генерировать миллионы строк логов в минуту, а сопоставление данных между сервисами требует дисциплины и специальных инструментов.

Метрики предоставляют вам агрегированные числовые данные за определенный период времени: частота запросов, частота ошибок, процентили задержки, использование ЦП. Их хранение обходится недорого, на их основе легко настраивать оповещения, и они идеально подходят для информационных панелей. Компромисс заключается в том, что при агрегировании теряется информация — задержка p99 в две секунды говорит вам, что что-то работает медленно, но не где и почему.

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

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

Чего не хватает трем столпам

Проблема «известных неизвестных»

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

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

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

Слепые зоны высокой кардинальности

Традиционные системы метрик испытывают трудности с данными высокой кардинальности. Если вы хотите отслеживать задержку по ID пользователя или частоту ошибок по конкретной комбинации конечной точки API + региона + арендатора, большинство баз данных временных рядов либо отказывают в этом, либо делают это непомерно дорого.

Это реальная операционная проблема. Многие инциденты в производственной среде вызваны определенной группой пользователей, конкретным регионом или конкретной комбинацией параметров запроса, которые невозможно эффективно запросить с помощью метрик с низкой кардинальностью. Вы знаете, что что-то не так. Вы видите ухудшение совокупного сигнала. Но вы не можете выделить точно ту группу, которая пострадала.

Такие инструменты, как Honeycomb и Lightstep, были созданы специально для решения этой проблемы с помощью данных событий с высокой кардинальностью — каждый запрос представляет собой структурированное событие с произвольными полями. Это принципиально иная ментальная модель, чем наблюдаемость, ориентированная на метрики, и она позволяет выполнять запросы, которые просто невозможно запустить с помощью традиционных инструментов.

Проблема коллапса контекста

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

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

Сторонние службы, которые вы вызываете, не участвуют в вашей инфраструктуре трассировки.

Пакетным заданиям и фоновым процессам часто не хватает надлежащих инструментов для подключения к трассировкам, которые их запустили.

Функции Lambda и бессерверные среды выполнения исторически имели неполную поддержку трассировки.

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

Слепые зоны бизнес-логики

Возможно, самым серьезным ограничением модели «трех столпов» является то, что она в первую очередь представляет собой модель наблюдаемости инфраструктуры. Она рассказывает вам о техническом поведении вашей системы: задержках, частоте ошибок, потреблении ресурсов.

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

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

Как выглядит настоящая наблюдаемость

Выход за рамки модели «трех столпов» не означает ее отказ. Это означает честное признание ее ограничений и наложение дополнительных практик поверх нее.

Начните со структурированных событий

По возможности генерируйте структурированные события — объекты JSON со значимыми полями — вместо неструктурированных строк журнала. Вот в чем разница между:

[ERROR] Не удалось обработать заказ 12345

и:

{

“level”: “error”,

«event»: «order_processing_failed»,

«order_id»: «12345»,

«user_id»: «u-789»,

«region»: «us-east-1»,

«payment_method»: «stripe»,

«код_ошибки»: «STRIPE_TIMEOUT»,

«duration_ms»: 4823,

«trace_id»: «abc-def-ghi»

}

Вторая версия доступна для запросов, в отличие от первой. Вы можете спросить: «Сколько таймаутов Stripe произошло в us-east-1 за последние 10 минут, с разбивкой по способам оплаты?» Вы не сможете дать осмысленный ответ на этот вопрос, опираясь на неструктурированные строки журналов в большом масштабе.

OpenTelemetry — это очевидный стандарт, который следует принять в данном случае — он предоставляет независимый от поставщика способ вывода журналов, метрик и трассировок в едином формате, который работает с инструментами Grafana, Datadog, Honeycomb, Jaeger и многими другими.

Используйте запросы с высокой кардинальностью

Если ваш текущий стек наблюдаемости не может ответить на запрос «покажи мне задержку p95 с разбивкой по уровням тарифных планов пользователей и конечным точкам API за последние пять минут», у вас есть серьезный пробел в наблюдаемости. Оцените, поддерживает ли ваш инструментарий эту функцию.

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

Внедрите непрерывную проверку в ваши конвейеры

Одной из наиболее недооцененных практик наблюдаемости является непрерывная верификация: запуск в производственной среде облегченных синтетических проверок, которые подтверждают не только техническое состояние, но и бизнес-корректность. Может ли пользователь пройти процесс оформления заказа от начала до конца? Правильно ли возвращается цена для продукта X? Возвращает ли система рекомендаций результаты, соответствующие нашей ожидаемой логике?

Для этой цели могут служить такие инструменты, как Steadybit, Gremlin и даже настраиваемые проверки работоспособности. Цель состоит в том, чтобы обнаружить неверные результаты раньше, чем это сделают ваши пользователи.

Инструменты для инцидентов, которые еще не произошли

После каждого инцидента в производственной среде проводите тщательный анализ: какая информация помогла бы быстрее диагностировать проблему? Затем добавьте соответствующие инструменты. Это обычная практика, приносящая значительную отдачу. Команды, которые последовательно ее применяют, за 12–18 месяцев заметно улучшают свои навыки отладки.

Обзор инструментов

Несколько инструментов, о которых стоит знать помимо стандартной тройки:

Инструмент	Для чего он нужен
Honeycomb	Исследование событий с высокой кардинальностью, быстрое произвольное сегментирование
Grafana Tempo	Масштабируемое распределенное трассирование, хорошо интегрируется с Loki + Prometheus
OpenTelemetry Collector	Независимый от поставщика конвейер телеметрии
Jaeger	Распределенное отслеживание с открытым исходным кодом
ClickHouse	Быстрые аналитические запросы по большим объемам структурированных событий
Robusta	Встроенные в Kubernetes средства обогащения оповещений и руководств

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

Заключение

Модель «трех столпов» — это хорошая отправная точка, а не конечная цель. Это фреймворк, разработанный в то время, когда архитектуры микросервисов были проще, кардинальность не вызывала особых опасений, а наблюдаемость бизнес-логики не была предметом обсуждения.

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

Если ваша команда может ответить на вопрос «Система поступила правильно?», а не просто «Система не вышла из строя?», вы приближаетесь к настоящей наблюдаемости. Если вы можете ответить только на второй вопрос, вам еще есть над чем работать.