Мониторинг и observability: метрики, логи и трейсы
Основы3 минРедакция Innovialabs
Коротко
Мониторинг сообщает, что что-то сломалось, по заранее заданным проверкам; observability позволяет понять, почему, с помощью трех источников данных: метрик (сколько), логов (что произошло) и трейсов (где именно).
Короткий ответ
Мониторинг — это наблюдение за заранее известными показателями: загрузка CPU, число ошибок, время ответа. Вы заранее решаете, что важно, и ставите алерты. Мониторинг отвечает на вопрос «что-то не так?».
Observability (наблюдаемость) — свойство системы, по внешним данным которой можно понять ее внутреннее состояние, в том числе в ситуациях, которые никто не предвидел. Она отвечает на вопрос «почему это происходит?».
Это не конкуренты: мониторинг — часть observability. Сначала алерт говорит, что выросли ошибки, потом данные observability помогают найти причину.
Три столпа: метрики, логи, трейсы
| Источник | Что это | На какой вопрос отвечает |
|---|---|---|
| Метрики | числа во времени: запросы в секунду, ошибки, задержка, память | Сколько? Как часто? Есть ли тренд? |
| Логи | записи о событиях с деталями: ошибка, пользователь, параметры | Что именно произошло? |
| Трейсы | путь одного запроса через все сервисы с длительностью каждого шага | Где именно тормозит или падает? |
Метрики
Метрики дешевы в хранении и быстро агрегируются, поэтому на них строят дашборды и алерты. Минус — в них мало деталей: метрика покажет, что 5xx-ошибок стало больше, но не скажет, какой запрос их вызвал.
Осторожно с кардинальностью: если добавить в метрику метку с ID пользователя или полным URL, число временных рядов взорвется, и хранилище станет медленным и дорогим.
Логи
Логи дают контекст: стектрейс, входные данные, идентификатор заказа. Лучше писать структурированные логи (JSON), чтобы по полям можно было искать и фильтровать. Минус — объем: логи быстро растут, их хранение и индексация стоят денег.
Трейсы
Трейс состоит из спанов — отрезков работы: обработка HTTP-запроса, запрос в базу, вызов внешнего API. Все спаны одного запроса связаны общим trace ID. Трейсы особенно нужны в системах из нескольких сервисов, где по логам одного сервиса причину не найти.
Как они работают вместе
Типичное расследование выглядит так:
- Метрика запускает алерт: задержка p95 у API выросла.
- Трейс медленного запроса показывает, что время уходит на вызов сервиса платежей.
- Логи этого сервиса с тем же trace ID показывают таймауты подключения к базе.
Ключ — корреляция: добавляйте trace ID в каждую строку лога, а в инструментах настраивайте переходы от графика к трейсам и от трейса к логам.
Какие инструменты что покрывают
| Задача | Популярные open source варианты |
|---|---|
| Метрики | Prometheus, VictoriaMetrics |
| Логи | Loki, Elasticsearch/OpenSearch, Graylog |
| Трейсы | Jaeger, Tempo, Zipkin |
| Визуализация и алерты | Grafana, Alertmanager |
| Сбор данных | OpenTelemetry, Fluent Bit, Vector |
Есть и платформы, которые закрывают все три столпа сразу: Datadog, New Relic, Grafana Cloud, Elastic Observability. Они быстрее запускаются, но стоимость обычно растет вместе с объемом данных.
OpenTelemetry — открытый стандарт и набор SDK для сбора метрик, логов и трейсов. Если инструментировать код через него, бэкенд хранения можно сменить без переписывания приложения.
С чего начать
- Небольшой проект: метрики сервера и приложения, централизованные логи, несколько алертов на ошибки и доступность. Трейсы пока можно не внедрять.
- Несколько сервисов или очереди: добавьте трейсинг через OpenTelemetry и trace ID в логах.
- Алертите по симптомам, которые видит пользователь (ошибки, задержка), а не по каждой внутренней метрике, иначе команда начнет игнорировать уведомления.