Представьте: сработал алерт, дашборд покраснел, система упала — но что именно сломалось и почему, никто не понимает. Для таких случаев существует observability, в основе которой три типа сигналов: метрики, логи и трейсы.
В статье разбираемся, что показывает каждый из них и как они работают вместе, помогая разобраться в любом инциденте: от простой ошибки до сложного сбоя в распределённой системе.
Разобраться в теме помогает Дмитрий Унтила, CPO «Пульта» и «Графини» в «Лаборатории Числитель», более 10 лет работающий с системами мониторинга.
Оглавление
- Когда мониторинга уже не хватает: в чем суть observability
- Как работает логирование
- Трейсинг в программировании: как работает трассировка запросов
- Метрики observability: числа, которые рассказывают о здоровье системы
- Логи, трейсы и метрики: в чём разница
- Как метрики, логи и трейсы работают вместе на примере реального инцидента
- Популярные инструменты мониторинга и логирования
Когда мониторинга уже не хватает: в чем суть observability
Представьте автомобиль. Мониторинг — это контрольная лампочка на приборной панели: она загорается, когда что-то идёт не так. Наблюдаемость (observability) — это полноценная диагностика, своего рода бортовой компьютер, который показывает, какой именно датчик дал сбой, в какой момент и при каких условиях.
Традиционный мониторинг хорошо справляется с обнаружением проблемы. Но в современных распределённых системах, где один пользовательский запрос проходит через десятки микросервисов, этого недостаточно. Нужна observability, чтобы понять источник и причины возникновения.
Поэтому основа для построения проактивной работы с ИТ-инфраструктурой — взаимодополняемость мониторинга и observability. Эти подходы не являются альтернативными или конкурирующими: они представляют собой части одного процесса, где мониторинг фиксирует проблему, а observability позволяет расследовать инцидент и предотвратить его повторение.
При этом вопрос о том, нужна ли компании полноценная observability, во многом определяется ценой ошибки.
«Это как с автомобилем: если машина нужна, чтобы пару раз в неделю ездить в гипермаркет в получасе от дома по ровной городской дороге, то использовать для этого внедорожник нерационально. А там, где ямы и бурелом, без него не обойтись. Как правило, observability требуется в случаях, когда цена ошибки перекрывает стоимость самой наблюдаемости», — поясняет Дмитрий Унтила.
Observability строится на трёх типах телеметрии: метриках, логах и трейсах. Все вместе они дают полную картину состояния системы. Каждый сигнал отвечает на свой вопрос:
- метрики — что происходит с системой сейчас?
- логи — что именно произошло в конкретный момент?
- трейсы — как запрос прошёл через всю цепочку сервисов?
Как работает логирование
Это самый интуитивно понятный инструмент наблюдаемости. Большинство разработчиков сталкиваются с ним с первых дней работы. Каждый раз, когда приложение выполняет какое-то действие, оно может оставить об этом запись: отметку времени, описание события, статус выполнения и сопутствующий контекст.
Например, на производстве каждая смена записывает, что происходило, когда и при каких обстоятельствах. Спустя время по этому журналу можно восстановить картину любого события.
Для разработчика или DevOps-инженера логирование значит возможность задать вопрос «что происходило в системе в 14:37:22?» и получить конкретный ответ.
Логирование событий охватывает широкий спектр активности системы. Типичные объекты логирования:
- входящие HTTP-запросы, SQL-запросы к базе данных, вызовы внешних API;
- процессы: старт и завершение фоновых задач, крон-джобов, очередей;
- события бизнес-логики: регистрация пользователя, оформление заказа, проведение платежа;
- стектрейсы, коды ошибок, описание сбоев;
- аудит и безопасность: попытки входа, изменения прав доступа, административные действия.
Современные системы логирования работают со структурированными логами — записями в формате JSON или любом аналогичном, где каждое поле имеет чёткое имя и тип. Это делает логи машиночитаемыми и позволяет эффективно их фильтровать, агрегировать и анализировать.
Механизм логирования: как устроен процесс изнутри
В современных системах приложение генерирует лог-запись и передаёт её в коллектор (например, агент Fluentd или Vector), который обогащает запись метаданными — именем сервиса, версией, именем хоста — и направляет в систему хранения.
Функция логирования в коде может выглядеть так: logger.info («Order placed», {order_id: «42», user_id: «7», amount: 1500}). Это и есть структурированный лог — набор именованных полей, по которым потом можно выполнять поиск.
Логирование в контейнерных средах отличается от классического подхода. Здесь каждый под порождает собственный поток логов, поды создаются и удаляются динамически, а сами логи по умолчанию нигде не сохраняются после удаления пода.
Поэтому для Kubernetes требуется отдельное решение. Как правило, это DaemonSet-агент (Fluent Bit, Promtail), который собирает логи со всех нод и отправляет их в централизованное хранилище. Без этого разобраться в инциденте в K8s-кластере крайне сложно.
Зачем нужно логирование и в чём его ограничения
Логи дают контекст. Метрика покажет, что количество ошибок возросло. Лог покажет, какая именно ошибка произошла, для какого пользователя, с каким запросом и что предшествовало сбою. Однако у логов есть ограничение: они изолированы. Один лог описывает событие в конкретном сервисе, но не показывает, как запрос путешествовал по всей системе. Для этого нужен другой инструмент: трейсинг.
Трейсинг в программировании: как работает трассировка запросов
Трейсинг в программировании — это механизм отслеживания пути запроса через распределённую систему от начала до конца. Если логи представляют собой записи в журнале отдельных сервисов, то трейс — это единая нить, которая связывает все эти записи воедино.
Что такое трейсинг и как устроен процесс трассировки
Процесс трейсинга начинается в момент, когда запрос входит в систему. На входе ему присваивается уникальный идентификатор: trace-id. Он передаётся вместе с запросом через все сервисы, которые он посещает. Трейсинг наблюдаемости позволяет ответить на вопросы, которые недоступны ни метрикам, ни логам: сколько времени запрос провёл в каждом сервисе, где возникла задержка, какой именно компонент стал узким местом.
Trace-id, span и структура трейса
Два ключевых понятия трейсинга — trace-id и span.
Trace-id — глобальный идентификатор всего запроса. Один trace-id сопровождает запрос от момента входа в систему до получения ответа, независимо от того, сколько сервисов задействовано.
Span — единица работы внутри трейса. Каждый вызов сервиса, каждый запрос к базе данных, каждая внешняя операция — это отдельный span с собственным временем начала и окончания. Spans вкладываются друг в друга, образуя дерево, которое наглядно показывает, как выполнялся запрос.
Представьте, что вы заказали пиццу. Trace-id — это номер вашего заказа. Spans — это отдельные этапы: принятие заказа, приготовление теста, выпечка, упаковка, доставка. По номеру заказа вы можете узнать, на каком этапе находится пицца и где произошла задержка. Трассировка логов означает, что в каждом лог-сообщении содержится trace-id. Это позволяет связать логи из разных сервисов с конкретным запросом, это и есть корреляция сигналов observability.
Зачем трейсинг observability в микросервисных архитектурах
В монолитном приложении найти проблему относительно просто: всё происходит в одном процессе. В микросервисной архитектуре один пользовательский запрос может пройти через 10, 20, а иногда и 50 сервисов. Трейсинг помогает понять, где именно возникла задержка или ошибка. Трейсы наблюдаемости — самый ценный инструмент при расследовании неизвестных проблем: когда метрики сигнализируют о деградации, но непонятно, в каком именно сервисе искать причину, трассировка даёт ответ быстро и точно.
Метрики observability: числа, которые рассказывают о здоровье системы
Метрики — это числовые показатели состояния системы, измеряемые во времени. Это самый лаконичный тип данных: одна метрика — одно число в конкретный момент времени. Именно метрики наблюдаемости запускают алерт, когда что-то идёт не так. На метрики observability смотрят в первую очередь при расследовании инцидента. Они показывают масштаб проблемы: сколько запросов завершились ошибкой, насколько вырос latency, какова загрузка CPU.
Типы метрик: счётчик, гейдж и гистограмма
В системах сбора метрик (прежде всего в Prometheus) выделяют несколько базовых типов:
Счётчик (Counter) — монотонно возрастающее значение. Например, общее количество HTTP-запросов с момента старта сервиса. Счётчик никогда не уменьшается (кроме случаев перезапуска сервиса), используется для подсчёта событий: количество ошибок, количество обработанных сообщений.
Гейдж (Gauge) — значение, которое может расти и убывать. Примеры: текущее использование памяти, количество активных соединений, температура CPU. Гейдж отражает мгновенное состояние системы.
Гистограмма (Histogram) — распределение значений по корзинам. Чаще всего используется для измерения времени ответа: какая доля запросов обрабатывалась менее 100 мс, менее 500 мс, менее 1 с. Позволяет вычислять перцентили: p95, p99.
RED, USE и золотые сигналы Google: как выбрать ключевые метрики
Индустрия выработала несколько методологий для выбора ключевых показателей.
RED-метрики (Rate, Errors, Duration) — подход для микросервисов: Rate — количество запросов в секунду, Errors — доля запросов с ошибками, Duration — время обработки запроса. RED даёт быстрый ответ на вопрос «Как чувствует себя сервис с точки зрения пользователя?».
USE-метрики (Utilization, Saturation, Errors) — подход для инфраструктуры: Utilization — загрузка ресурса, Saturation — насколько ресурс перегружен (очередь, ожидание), Errors — ошибки ресурса. USE хорошо подходит для анализа серверов, дисков, сетевых интерфейсов.
Четыре золотых сигнала Google (Site Reliability Engineering): Latency — время ответа на запрос, Traffic — интенсивность трафика, Errors — частота ошибок, Saturation — насколько система близка к пределу своих возможностей. SRE-команды часто комбинируют эти подходы: RED для пользовательских сервисов, USE для инфраструктуры, а золотые сигналы — как обобщающая рамка для построения алертов на основе SLO.
Логи, трейсы и метрики: в чём разница
Все три типа сигналов observability решают разные задачи и обладают разными характеристиками.
Как метрики, логи и трейсы работают вместе на примере реального инцидента
Каждый сигнал в отдельности даёт лишь часть картины. Настоящая польза observability проявляется, когда три типа данных работают в связке. Рассмотрим типичную схему расследования инцидента.
Шаг 1: метрика — сигнал тревоги. В 14:37 срабатывает алерт: доля ошибок 5xx на сервисе оформления заказов превысила 5%. На дашборде видно: latency вырос с 200 мс до 4 секунд, а количество успешных запросов резко упало. Метрики дают масштаб проблемы и момент её начала.
Шаг 2: трейс — локализация. Инженер открывает трейсинг и находит медленные трейсы за этот период. Каждый из них показывает: запрос зависает на этапе обращения к сервису платежей. Span «payment-service.charge» занимает 3,8 секунды вместо обычных 150 мс. Трейс точно указывает на проблемный компонент.
Шаг 3: лог — причина. По trace-id из трейса инженер находит логи сервиса платежей в тот же период. В логах повторяется запись: «Connection timeout to payment-gateway: read timeout after 3000ms» («Превышено время ожидания подключения к платежному шлюзу: истекло время ожидания чтения после 3000 мс»). Это и есть конкретная причина: внешний платёжный шлюз перестал отвечать вовремя.
Вся цепочка расследования заняла несколько минут вместо нескольких часов. Observability работает как единая система: метрики указывают на симптом, трейсы — на место, логи — на причину. Без мониторинга невозможно вовремя узнать о существовании проблемы, а без наблюдаемости — понять, как её решить. Верная настройка мониторинга позволяет управлять алертами, снижая уровень шума за счёт сокращения количества бесполезных показателей и повышения точности сигналов.
Ключевой механизм, который делает возможным такой сценарий — корреляция. Когда в каждом логе и трейсе присутствует trace-id, а метрики привязаны ко временной шкале, переход между типами данных занимает пару кликов. Именно поэтому карточка инцидента в зрелых командах всегда содержит ссылки на все три источника данных.
Популярные инструменты мониторинга и логирования
Сегодня в большинстве компаний для observability используется набор открытых инструментов, который часто называют PLG-стеком (Prometheus + Loki + Grafana) или LGTM-стеком с добавлением Tempo.
Prometheus — система сбора и хранения метрик. Работает по модели pull: сам обходит сервисы по расписанию и собирает метрики с их /metrics-эндпоинтов. Имеет мощный язык запросов PromQL и встроенный алертинг.
Loki — система агрегации и хранения логов от Grafana Labs. В отличие от Elasticsearch, Loki не индексирует содержимое логов, только метаданные (лейблы). Это делает её значительно дешевле в эксплуатации при больших объёмах.
Tempo — бэкенд для хранения трейсов от той же команды. Принимает трейсы в форматах OpenTelemetry, Jaeger, Zipkin. Интегрирован с Grafana, что позволяет в один клик переходить от метрик и логов к трейсам.
Jaeger — open source-система распределённого трейсинга от Uber. Один из наиболее зрелых инструментов для визуализации трейсов и анализа зависимостей между сервисами.
OpenTelemetry — стандарт и набор инструментов для сбора и передачи телеметрии. Объединяет метрики, логи и трейсы под единым API и форматом данных. OpenTelemetry не хранит данные, он их собирает и передает в выбранные бэкенды (Prometheus, Loki, Tempo и другие). Сегодня это де-факто стандарт инструментации в DevOps и SRE.
Grafana-логирование — распространённый термин, хотя точнее говорить о визуализации логов в Grafana. Сама Grafana не собирает и не хранит логи, она лишь отображает данные из Loki (или Elasticsearch) в удобном интерфейсе. Именно в Grafana инженеры переходят от метрик к логам observability, а затем к трейсам, не покидая одного интерфейса.
«Пульт» и «Графиня» — отечественная связка для метрик и логов
Для российских компаний, работающих в условиях требований к импортозамещению, есть отечественные альтернативы — «Пульт» и «Графиня» от «Лаборатории Числитель». «Пульт» — система мониторинга ИТ‑инфраструктуры на базе Zabbix: она отвечает за сбор метрик и работу с логами и событиями инфраструктуры, поддерживает агентский и безагентский сбор данных по стандартным протоколам (SNMP, IPMI, JMX, ODBC, SSH). «Графиня» — российский аналог Grafana — берёт на себя визуализацию: сводит метрики и логи из разных источников («Пульт», Zabbix, Prometheus, Victoria Metrics и других) в единые витрины данных. Оба продукта включены в реестр российского ПО. Уже сегодня эта связка закрывает метрики и логи и используется в крупных российских компаниях. Поддержка трейсинга распределённых запросов — следующий шаг развития платформы на пути к полноценному observability-стеку, не зависящему от западных вендоров.
Что дают логи, метрики и трейсы вместе
Observability — это способность системы «рассказывать» о своём состоянии через три типа сигналов: метрики, логи и трейсы. Метрики дают числовую картину состояния системы и запускают алерты. Без метрик вы не узнаете, что что-то пошло не так. Логи дают детальный контекст каждого события. Без логов вы не поймёте, что именно произошло. Трейсы показывают путь запроса через все сервисы. Без трейсов вы не найдёте, где именно в цепочке возникла проблема.
Все три сигнала необходимы. По отдельности каждый из них показывает часть картины; полная observability возможна только при их совместной работе и корреляции.
Инструменты мониторинга и логирования (Prometheus, Loki, Tempo, Grafana, OpenTelemetry) образуют экосистему, где переход между сигналами занимает секунды.
«Главное для построения проактивной работы с ИТ-инфраструктурой — взаимодополняемость мониторинга и observability. Эти подходы не являются альтернативными или конкурирующими. Они представляют собой части одного процесса: мониторинг фиксирует проблему, observability позволяет расследовать инцидент и предотвратить его повторение», — подчеркивает Дмитрий Унтила.
Алгоритм примерно такой. Если вы только начинаете выстраивать observability в своей компании, начните с метрик и алертов на их основе. Затем добавьте структурированные логи с единым форматом. И наконец, внедрите трейсинг, особенно если у вас микросервисная архитектура. Каждый из этих шагов даст ощутимый результат.
FAQ
Чем observability отличается от обычного мониторинга?
Мониторинг фиксирует, что что-то сломалось — как контрольная лампочка на приборной панели. Observability — это полноценная диагностика: она показывает, что именно сломалось, где и почему. Подходы не конкурируют, а дополняют друг друга: мониторинг сигнализирует о проблеме, observability помогает ее расследовать.
Что такое логирование и зачем оно нужно?
Логирование — это запись событий, происходящих в системе: с отметкой времени, описанием события и контекстом. Логи дают детальный контекст конкретного события — например, какая именно ошибка произошла и для какого пользователя. Их ограничение в том, что один лог описывает событие только в одном сервисе и не показывает путь запроса через всю систему.
Что такое трейсинг и как он устроен?
Трейсинг — это отслеживание пути запроса через распределенную систему от начала до конца. Запросу присваивается уникальный идентификатор trace-id, который сопровождает его через все сервисы, а каждая отдельная операция внутри запроса фиксируется как span. Трейсинг показывает, в каком сервисе возникла задержка или узкое место.
Что такое метрики observability и какие у них есть типы?
Метрики — это числовые показатели состояния системы во времени, которые запускают алерты при отклонениях. Базовые типы: счетчик (монотонно растущее значение, например количество запросов), гейдж (значение, которое может расти и убывать, например использование памяти) и гистограмма (распределение значений, например времени ответа, по корзинам для расчета перцентилей).
Что такое методологии RED, USE и золотые сигналы Google?
Это подходы к выбору ключевых метрик. RED (Rate, Errors, Duration) применяется для микросервисов и оценивает запросы в секунду, долю ошибок и время обработки. USE (Utilization, Saturation, Errors) — для инфраструктуры: загрузка, перегрузка и ошибки ресурса. Четыре золотых сигнала Google объединяют Latency, Traffic, Errors и Saturation как обобщающую рамку для алертов на основе SLO.
Как метрики, логи и трейсы работают вместе при расследовании инцидента?
Метрика сигнализирует о проблеме и показывает ее масштаб, трейс позволяет локализовать, в каком именно сервисе возникла задержка, а лог по trace-id раскрывает конкретную причину сбоя. Такая цепочка с корреляцией сигналов сокращает расследование инцидента с нескольких часов до нескольких минут.
