Наблюдаемость современных приложений: логи, метрики и трассировки

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

При этом нам нужно понимать:

• Работает ли приложение корректно?
• Возникают ли проблемы у пользователей?
• Не заканчиваются ли ресурсы?
• Какой компонент системы вызвал ошибку?
• Что именно произошло во время инцидента?

Именно для этого существует наблюдаемость (observability).

Что такое observability?

Observability — это способность понимать внутреннее состояние системы, анализируя телеметрию, которую она производит. Во время работы система постоянно генерирует диагностическую информацию о своём поведении. Эта информация называется телеметрией. Основные типы телеметрии:

• Логи (Logs)
• Метрики (Metrics)
• Трассировки (Traces)

Observability — это не инструмент и не библиотека. Это возможность понять, что происходит внутри системы, анализируя эти данные.

Observability и мониторинг

Мониторинг отвечает на вопрос:

«Есть ли проблема?»

Он постоянно проверяет заранее определённые условия — пороговые значения, health checks — и отправляет уведомление, если что-то выходит за допустимые пределы.

Например:

• загрузка CPU превысила 90%;
• увеличился процент ошибок;
• P95 задержки превысил допустимое значение;
• перестал проходить health check.

Observability отвечает на другой вопрос:

«Почему это произошло?»

Она помогает расследовать инцидент и найти его первопричину. Мониторинг обнаруживает проблему. Observability помогает понять её причину.

Метрики

Метрики — это числовые измерения, собираемые с течением времени.

Например:

• загрузка CPU;
• потребление памяти;
• количество запросов в секунду;
• количество ошибок;
• задержка базы данных.

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

Трассировки

Трассировка (Trace) представляет собой выполнение одной операции. Например:

• один HTTP-запрос;
• обработка одного сообщения Kafka;
• выполнение фоновой задачи.

Трассировка состоит из нескольких спанов (Span). Каждый спан представляет отдельную операцию внутри трассировки. Например:

Создание заказа
├── Проверка запроса
├── Проверка остатков
├── Сохранение в базу данных
└── Вызов платёжного сервиса

Каждый спан содержит информацию:

• название операции;
• время начала;
• продолжительность;
• связь с родительским спаном.

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

Логи

Логи — это сообщения с отметкой времени, описывающие события, происходящие внутри системы. Например:

• заказ успешно создан;
• платёж завершился ошибкой;
• произошёл таймаут при обращении к базе данных.

Современные приложения обычно используют структурированные логи. Например:

{
  "level": "Error",
  "message": "Payment failed",
  "orderId": "12345"
}

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

Как всё работает вместе

Каждый тип телеметрии отвечает на свой вопрос:

• Метрики — Что происходит?
• Трассировки — Где возникла проблема?
• Логи — Почему это произошло?

Представим, что пользователь сообщает:

«Создание заказа занимает около 10 секунд.»

Сначала мы смотрим метрики. Они показывают, что задержка обработки заказов действительно увеличилась. Затем открываем трассировку одного медленного запроса.

Например:

Создание заказа
├── Проверка запроса (5 мс)
├── SQL-запрос (9000 мс)
└── Платёжный сервис (50 мс)

Теперь понятно, на каком этапе возникла задержка. После этого открываем логи, связанные с данной трассировкой. Например:

Таймаут SQL-запроса.
Ожидание снятия блокировки.

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

OpenTelemetry

OpenTelemetry — это открытый фреймворк для observability. Он предоставляет API, SDK, библиотеки автоматической инструментализации и экспортёры для генерации, сбора и отправки телеметрии в едином формате. Благодаря этому приложение можно подключить к различным платформам наблюдаемости без изменения собственного кода. Важно понимать, что OpenTelemetry не хранит телеметрию. За хранение и визуализацию отвечают специализированные системы, например:

• Grafana;
• Jaeger;
• Prometheus.

Поток телеметрии

В упрощённом виде поток данных выглядит следующим образом:

Приложение
      ↓
Инструментализация
      ↓
OpenTelemetry SDK
      ↓
Экспортёр
      ↓
Платформа наблюдаемости

Телеметрия может собираться автоматически или вручную.

Автоматическая инструментализация

Готовые библиотеки умеют автоматически собирать информацию о:

• HTTP-запросах;
• запросах к базе данных;
• внешних HTTP-вызовах;
• метриках среды выполнения;
• необработанных исключениях.

Ручная инструментализация

Разработчик должен самостоятельно добавить телеметрию для бизнес-операций, которые фреймворк не понимает. Например:

• создание заказа;
• обработка платежа;
• резервирование товара;
• формирование счёта.

Фреймворк понимает технические операции, но только разработчик знает, какие бизнес-процессы действительно важны.

Заключение

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