Большинство команд узнают, что им нужна наблюдаемость, в самый неподходящий день: страница оформления заказа тормозит, дашборды зелёные, и никто не может сказать, какой сервис на самом деле горит. Этот разрыв между «у нас есть мониторинг» и «мы можем объяснить, что делает система» — вся дисциплина в одном предложении.
Мониторинг отвечает на вопросы, которые вы уже знали, что нужно задать: высока ли загрузка CPU, работает ли эндпоинт. Наблюдаемость позволяет задать продакшену новый вопрос, не выпуская новый код. OpenTelemetry, Prometheus, Grafana и распределённая трассировка — это инструменты; навык заключается в том, чтобы решить, что записывать, на что ставить алерты и что игнорировать.
Что такое наблюдаемость на самом деле (и почему одни инструменты её не дают)
Три типа сигналов несут почти всю нагрузку: метрики (агрегированные числа во времени), логи (дискретные события с контекстом) и трейсы (путь одного запроса через сервисы). Каждый отвечает на свой вопрос, и команды обычно чрезмерно инвестируют в один.
Метрики дёшевы в хранении и дороги в интерпретации — линия p99 задержки говорит, что что-то не так, но не где. Логи богаты, но не поддаются поиску в масштабе, если не контролировать кардинальность. Трейсы — единственный сигнал, показывающий причинно-следственные связи через границы сервисов, поэтому распределённая трассировка — та часть, которую большинство самоучек пропускают и позже жалеют.
Неочевидная часть: наблюдаемость — это задача моделирования данных прежде, чем задача инфраструктуры. Если в вашем трейсе нет имени сервиса, кода статуса или ID запроса, который также появляется в логах, никакое количество Grafana не соединит точки. OpenTelemetry существует именно потому, что вендорские агенты делали эту связь хрупкой — SDK выдаёт вендор-нейтральный формат, а бэкенд (Jaeger, Tempo, коммерческий APM) становится заменяемой деталью.
Один разбор: от «пользователи говорят, что медленно» до первопричины
Представьте поток оформления заказа: фронтенд → API-шлюз → сервис заказов → сервис платежей → экземпляр Postgres. Пользователи сообщают о медленном оформлении заказа. Вот как на самом деле работает практик, по порядку.
- Начните с симптома, а не с дашборда. Возьмите задержку p95 и p99 для эндпоинта оформления заказа за последние 24 часа. Скажем, p50 — 120 мс, а p99 — 2,4 с: среднее скрывает проблему, а хвост — это то, что чувствуют пользователи.
- Разбейте по измерениям. Сгруппируйте ту же метрику по коду статуса и по нижестоящей зависимости. Если p99 подскакивает только для запросов, попадающих в сервис платежей, пространство поиска только что сократилось на 80%.
- Откройте трейс. Найдите медленный трейс и прочитайте водопад спанов. Паттерн, который нужно искать, — это один спан, доминирующий в общем времени: вызов платежей на 2,1 с внутри запроса на 2,3 с — явная улика.
- Сопоставьте с логами. Возьмите ID трейса из этого спана, поищите его в логах и проверьте, не логировал ли сервис платежей повторы, исчерпание пула соединений или таймаут чуть ниже клиентского дедлайна.
- Подтвердите счётчиком. Добавьте или прочитайте метрику Prometheus для насыщения пула или количества повторов. Если повторы растут синхронно с p99, у вас есть механизм, а не корреляция. Подробнее об этом — в статье CI/CD как искусство: разбор реального пайплайна и ошибок, которые дорого стоят.
Режим отказа при другом подходе: команды начинают с шага 5 (пялятся на CPU хоста), ничего не находят и заключают «это сеть». Метрики хоста почти всегда ровные, когда проблема — медленная зависимость или шторм повторов.
Где ломается сама схема
Проекты наблюдаемости терпят неудачу предсказуемыми способами. Это не ошибки новичков — это структурные ограничения.
Взрыв кардинальности. Каждая уникальная комбинация меток в Prometheus — отдельный временной ряд. Метка вроде user_id или request_id на метрике будет умножать ряды, пока цель сбора не упадёт. В стейджинге с десятью пользователями это выглядит нормально. Ранний признак: длительность сбора растёт, а память на поде Prometheus неуклонно увеличивается. Если уже слишком поздно, удалите проблемную метку, агрегируйте и перенесите высококардинальные данные в трейсы или логи, где им место.
Сэмплирование, скрывающее хвост. Головное сэмплирование на 1% хорошо для затрат и бесполезно для отладки редких ошибок — медленные запросы, которые вас волнуют, — это именно те, что не попали в выборку. Ранний признак: вы видите ошибки в агрегате, но никогда не находите соответствующий трейс. Решение — хвостовое сэмплирование: сохраняйте каждый трейс с ошибкой или выше порога задержки, сэмплируйте скучные.
Алерты, срабатывающие на причины, а не на симптомы. CPU на 90% — не инцидент; падающий SLI — инцидент. Алертинг по симптомам (частота ошибок, задержка относительно SLO) вызывает меньше и значит больше. Ранний признак: дежурный игнорирует страницы, потому что «это опять тот алерт». К этому моменту система алертинга потеряла доверие и требует перестройки, а не подстройки.
Молчание чёрного ящика. Всё внутри кластера инструментировано, но никто не проверяет то, во что на самом деле попадают пользователи. Балансировщик нагрузки, возвращающий 502 при здоровых бэкендах, не появляется ни в одной внутренней метрике. Дешёвые внешние пробы против публичного эндпоинта ловят этот класс отказов.
| Отказ | Ранний сигнал | Восстановление |
|---|---|---|
| Взрыв кардинальности | Растут длительность сбора и память | Удалить метки, агрегировать, перенести в трейсы |
| Головное сэмплирование скрывает хвост | Ошибки видны, трейсы отсутствуют | Перейти на хвостовое сэмплирование |
| Алерты по причинам | Дежурный игнорирует страницы | Перестроить вокруг SLI и SLO |
| Нет проверок чёрного ящика | Внутри зелено, у пользователей красно | Внешние пробы на публичных эндпоинтах |
Как люди на самом деле этому учатся
Самообучение работает, если вы уже что-то запускаете в продакшене. Вы читаете документацию OpenTelemetry, поднимаете Prometheus и Grafana в Docker и учитесь, ломая вещи, — цена в времени и в том, что никто не скажет вам, что ваш SLO бессмысленен или ваш алерт — шум.
Курсы сжимают цикл обратной связи: кто-то уже совершил ошибку кардинальности и может показать вам её форму, прежде чем вы повторите. Компромисс реален — вам всё равно нужны собственные руки на работающей системе, чтобы усвоить это. Буткемпы, обещающие готовность к продакшену за выходные, не дают этого; наблюдаемость — это суждение, а суждение приходит из инцидентов.
Средний путь, который выбирают большинство инженеров: соберите небольшой инструментированный стек самостоятельно, а затем получите структурированную обратную связь по решениям — стратегия сэмплирования, пороги алертов, структура рунбуков, — потому что именно там неправильный выбор невидим до инцидента.
Кому это подходит, а кому нет
Подходит бэкенд-инженерам и инженерам, близким к SRE, которые владеют сервисом в продакшене, платформенным инженерам, строящим общие конвейеры телеметрии, и дежурным, уставшим от догадок. Не подходит тем, кто хочет чек-лист для установки инструментов — инструменты — это лёгкая часть, а дисциплина — решать, что измерять и на что ставить страницы.
Если вы ещё не запускаете что-то с реальными пользователями, начните с этого; наблюдаемость без системы для наблюдения — это теория.
Если вы хотите структурированный путь через решения — проектирование SLI/SLO, инструментирование OpenTelemetry, Prometheus и Grafana, трассировка, алертинг, рунбуки и постмортемы — курс «Наблюдаемость» проходит именно через эти компромиссы с проработанными примерами и даёт обратную связь по вашим выборам. Начните с инструментирования одного реального эндпоинта, а затем следуйте пути оттуда. Начать можно здесь: Observability (Prometheus, Grafana). Подробнее об этом — в статье Data Engineering (Spark, dbt): как строить пайплайны данных, которые не падают в production.