Наблюдаемость (observability) — это способность понять, что происходит внутри системы, не залезая в неё руками: по тому, что она «излучает» наружу. Стоит на трёх столпах. Логи — текстовые записи событий: что произошло и когда. Метрики — числа во времени: сколько запросов в секунду, какая задержка, сколько ошибок, насколько загружен процессор. Трейсы — путь одного запроса через все сервисы: где он шёл и где застрял. Логи отвечают «что случилось», метрики — «насколько всё плохо и когда началось», трейсы — «в каком именно сервисе». Алерт — это порог на метрике, который сам шлёт уведомление. Для аналитика главное: закладывать в требования не только «что система делает», но и «как мы поймём, что она сломалась».
Я застал ночь, когда «оплата тормозит» — и три инженера полтора часа спорили, кто виноват: фронтенд, платёжный сервис или банк. Каждый смотрел в свой кусок и видел, что у него «всё нормально». Виноват оказался кеш, который никто не мерил. С тех пор я понял простое: если систему нельзя наблюдать, её отладка — это гадание по чату. А гадание в проде стоит дорого — пока спорят, клиенты не платят.
Зачем вообще наблюдаемость
В проде нельзя поставить точку останова и пошагать отладчиком, как на своей машине. Система работает, через неё идут реальные пользователи, и единственное, что у вас есть, — то, что она сама о себе рассказывает наружу. Наблюдаемость — это про то, чтобы система рассказывала о себе достаточно, чтобы по этим следам можно было восстановить картину и найти причину, а не угадывать.
Ключевое отличие от старого слова «мониторинг»: мониторинг отвечает на заранее заданные вопросы («жив ли сервис?»), а наблюдаемость позволяет задавать вопросы, которые вы не предусмотрели заранее («почему именно у пользователей из этого региона с этой картой оплата висит 8 секунд?»). В монолите можно было обойтись логами. В микросервисах (см. монолит против микросервисов) один запрос проходит через десяток сервисов — и без наблюдаемости вы физически не видите, где он сломался.
Три столпа: логи, метрики, трейсы
Это три разных взгляда на одну систему. Они не заменяют друг друга — они отвечают на разные вопросы.
| Столп | Что это | На какой вопрос отвечает | Пример |
|---|---|---|---|
| Логи | Текстовые записи событий | Что именно произошло? | «2026-05-23 14:02:11 ERROR платёж 8842 отклонён банком, код 51» |
| Метрики | Числа, агрегированные во времени | Насколько плохо и когда началось? | RPS, p95 задержки, доля ошибок, загрузка CPU |
| Трейсы | Путь одного запроса по сервисам | В каком сервисе застряло? | запрос 200 мс: API 5 мс → платёж 12 мс → банк 183 мс |
Логи — самое привычное: сервис пишет строчки о том, что с ним происходит. Они подробные и точные, но их много, и по ним тяжело увидеть общую картину — это как читать стенограмму вместо графика. Метрики — это числа, которые снимают регулярно и складывают на график во времени: видно тренд, видно момент, когда «поехало». Но метрика говорит «ошибок стало 5%», а не «вот эта конкретная ошибка». Трейс — самое ценное в распределённой системе: он показывает один запрос целиком, как он шёл через все сервисы и сколько времени провёл в каждом. Именно трейс сразу ответил бы той ночью: 183 мс из 200 запрос провёл, ожидая банк, — а спорили мы зря.
Как они дополняют друг друга на практике
Рабочий порядок такой: метрика поднимает тревогу — «доля ошибок оплаты подскочила до 7%». Вы смотрите на график и видите, когда началось. Дальше трейс показывает, в каком сервисе застревают эти запросы. И уже лог этого сервиса говорит точную причину — «нет связи с банком, таймаут». Метрика заметила, трейс локализовал, лог объяснил. Поэтому нужны все три, а не один.
Как это устроено
flowchart LR S1["Сервис заказов"] --> C["Сборщик (OpenTelemetry)"] S2["Платёжный сервис"] --> C S3["Сервис уведомлений"] --> C C --> L["Логи"] C --> M["Метрики"] C --> T["Трейсы"] L --> D["Дашборд"] M --> D T --> D M --> A["Алерт → дежурный"]
Схема показывает поток. Каждый сервис «излучает» наружу свои сигналы — события, числа, отрезки пути запроса. Их собирает общий сборщик (сегодня это чаще всего OpenTelemetry — единый стандарт сбора) и раскладывает по трём хранилищам: логи, метрики, трейсы. Дальше всё это стекается на дашборд, где инженер видит картину глазами. А метрики дополнительно заведены на алерты: если число перешло опасный порог, система сама будит дежурного, не дожидаясь, пока заметят люди. Главная идея — сервисы не знают, кто и как будет читать их сигналы; они просто честно рассказывают о себе, а сбор и анализ — отдельный слой.
Что такое алерт
Алерт — это правило вида «порог → уведомление». Вы говорите системе: «если доля ошибок выше 2% в течение пяти минут — напиши дежурному в Telegram». Алерт всегда вешается на метрику, потому что метрика — это число, а с числом легко сравнить порог. Смысл алерта в том, чтобы про поломку узнавали не от разъярённого клиента, а от системы — и желательно раньше клиента.
Тонкость, о которую спотыкаются: порог надо выбрать с умом. Слишком чувствительный алерт орёт по любому пустяку, дежурный привыкает его игнорировать — и пропустит реальную беду (это называют «усталостью от алертов»). Слишком грубый молчит, когда уже всё горит. Поэтому хороший алерт вешают не на «было хоть одно падение», а на то, что реально бьёт по пользователю: рост ошибок, рост задержки, недоступность.
Связь с нефункциональными требованиями
Здесь наблюдаемость смыкается с нефункциональными требованиями. Помните правило «НФТ без числа — это не требование»? Так вот, метрики — это и есть инструмент, которым эти числа меряют. Когда в спеке написано «p95 ответа API < 300 мс» или «доступность 99.9%» — это не просто пожелание, это значение, которое кто-то должен непрерывно измерять. И измеряет его именно метрика. А как из таких метрик делают цели надёжности и обещания клиенту — в записи про SLA, SLO и инциденты.
Требование, которое нечем проверить, — не требование
Если вы написали SLA «доступность 99.9%», но нигде не сказано, чем и как её мерить, — это число повиснет в воздухе. На разборе инцидента вы не докажете ни что нарушили, ни что уложились. Поэтому к каждому нефункциональному требованию с числом я приучился добавлять строчку «как меряем»: какая метрика, с какой частотой снимается, какой алерт стоит. SLO (целевое значение метрики) без метрики, которая его считает, — это самообман.
Что меняется для аналитика
Аналитик не настраивает дашборды — это работа инженеров. Но аналитик решает, что вообще нужно наблюдать, и закладывает это в требования заранее. Три вещи, которые стоит проговаривать на этапе спеки:
- Как мы поймём, что фича работает. Какую метрику смотреть, чтобы убедиться, что оплата проходит, а не молча отваливается? Если такой метрики нет — её надо завести.
- Какие события логировать. Особенно по деньгам и важным переходам статусов: «платёж создан», «платёж подтверждён», «платёж отклонён, причина». На разборе инцидента эти логи — единственное, что у вас есть.
- Какой алерт и на какой порог. Что должно разбудить дежурного ночью, а что подождёт до утра. Это бизнес-вопрос не меньше, чем технический.
Звучит как «не моя забота», но это ровно та забота, из-за которой потом полтора часа спорят ночью. Один абзац «наблюдаемость» в спеке экономит этот спор.
Откуда это взялось
Мониторинг был всегда — за «здоровьем» серверов следили с тех пор, как появились серверы. А вот сам термин observability пришёл не из IT, а из теории управления (работы Рудольфа Калмана, 1960-е): там «наблюдаемость» — это формальное свойство системы, при котором её внутреннее состояние можно восстановить по внешним сигналам. В IT слово всплыло волной около 2017–2018 годов вместе с микросервисами: когда сервисов стали сотни, старого мониторинга «жив/не жив» перестало хватать, понадобилось восстанавливать картину по следам. Идею «трёх столпов» (logs, metrics, traces) сформулировало инженерное сообщество примерно тогда же. А чтобы все эти сигналы собирались единообразно, а не каждым вендором по-своему, в 2019 году из слияния двух проектов родился OpenTelemetry — сегодня это фактический стандарт сбора телеметрии.
Частые вопросы
Чем логи отличаются от метрик и трейсов?
Логи — это текстовые записи отдельных событий («платёж 8842 отклонён банком»): подробно и точно, но картину целиком по ним видно плохо. Метрики — это числа, агрегированные во времени (RPS, задержка, доля ошибок, CPU): по ним видно тренд и момент, когда «поехало», но не конкретную причину. Трейсы — это путь одного запроса через все сервисы с временем в каждом: они показывают, в каком именно сервисе застряло. На практике метрика поднимает тревогу, трейс локализует место, лог объясняет причину.
Что такое observability простыми словами?
Это способность понять, что происходит внутри работающей системы, не залезая в неё руками, — по тому, что она сама о себе рассказывает наружу (логи, метрики, трейсы). В отличие от старого мониторинга, который отвечает только на заранее заданные вопросы вроде «жив ли сервис?», наблюдаемость позволяет задавать вопросы, которые вы не предусмотрели заранее, — например, почему конкретный тип запросов тормозит именно у части пользователей. Особенно критична в микросервисах, где один запрос идёт через десяток сервисов.
Что аналитику закладывать в требования про наблюдаемость?
Три вещи. Первое — как мы поймём, что фича работает: какую метрику смотреть. Второе — какие события логировать, особенно по деньгам и переходам статусов («платёж создан / подтверждён / отклонён с причиной»). Третье — какой алерт и на какой порог должен сработать при поломке. Плюс к каждому нефункциональному требованию с числом (SLA, p95) добавляйте строчку «как меряем» — иначе требование нечем проверить, и на разборе инцидента вы ничего не докажете.