В современном мире цифровых технологий сложные распределённые системы и микросервисные архитектуры требуют от специалистов по разработке и эксплуатации приложений новых решений для мониторинга и диагностики. Одним из наиболее перспективных и мощных инструментов, позволяющих получить полное представление о здоровье и производительности приложений, является OpenTelemetry. Эта открытая платформа благодаря своей универсальности и масштабируемости быстро завоевывает популярность, становясь стандартом в индустрии. Опыт Норвежской администрации труда и социального обеспечения (NAV) представляет собой наглядный пример того, как можно шаг за шагом пройти путь от первых попыток внедрения OpenTelemetry до полноценного внедрения трассировки в продуктивных кластерах. NAV — это организация с тысячами сервисов, развёрнутых в среде Kubernetes, где эффективное мониторинг и трассировка стали ключевыми задачами.
Проблемы, с которыми столкнулись команды NAV на старте, знакомы многим. Использование Prometheus и Grafana для сбора метрик было распространено, но ещё сохранялась необходимость анализировать огромные объёмы логов в Kibana, что усложняло понимание полного пути запроса и причин возникающих ошибок. Особенно трудно было диагностировать проблемы в распределённых системах с использованием событийной архитектуры на базе Kafka. Отсутствие единой стандартизации для передачи корелляционных идентификаторов лишь усугубляло ситуацию. OpenTelemetry предложила решение, предоставив стандартный формат для телеметрических данных, SDK и библиотеки на популярных языках программирования, а также возможность интеграции с различными системами хранения и визуализации данных.
Однако освоение OpenTelemetry оказалось нелегкой задачей — это сложная система с множеством компонентов, требующая правильной настройки и интеграции. Ключевые условия успешного внедрения включали наличие надёжного хранилища данных и, что не менее важно, мотивацию и понимание разработчиков о пользе инструментов трассировки. Выбор падал на Grafana Tempo — масштабируемое и бесплатное решение, которое легко интегрируется с уже используемой в NAV экосистемой Grafana. Для обращения данных OpenTelemetry в Tempo была развернута служба Collector, способная принимать данные из множества источников, обрабатывать их и отправлять в разные хранилища. Такая гибкость позволяла без изменений в приложениях расширять систему и менять её архитектуру.
Особой сложностью стала обязательная автоматизация процесса инструментирования. При наличии более 1600 приложений в производственной среде ручная доработка каждого проекта была неприемлема по времени и ресурсам. Java-агент OpenTelemetry стал настоящим спасением — он вставляет необходимый код автоматически, не требуя модификаций исходников. Этот подход доказал свою эффективность, особенно благодаря поддержке более 100 популярных библиотек. С ростом контейнеризации и Kubernetes появилась потребность адаптировать агент к новым условиям: традиционные методы установки на узлы были невозможны.
Здесь на помощь пришёл OpenTelemetry Operator — Kubernetes-оператор, автоматически внедряющий агенты в контейнеры, конфигурирующий их и передающий данные в Collector. В NAV разработчики интегрировали Operator в собственную платформу nais, упрощающую развертывание приложений. Добавив в manifest всего несколько строк конфигурации, они позволили автоматически включать трассировку для приложений на Java, Node.js и Python. Такой уровень абстракции значительно снизил порог входа и ускорил массовое принятие OpenTelemetry.
Визуализация трасс в Grafana Tempo стала настоящим прозрением для команд, позволяя отслеживать прохождение запросов от пользователя до конкретного микросервиса и анализировать возникающие проблемы в полной цепочке. Использование Grafana Faro Web SDK значительно расширило возможности фронтенд-разработчиков по наблюдению и оптимизации пользовательских взаимодействий. Тем не менее, путь к полной интеграции не был без проблем. Появляющийся шум в трассах от запросов на проверку здоровья, метрик и статусов приводил к затруднениям при поиске нужных данных. NAV удалось решить эту проблему фильтрацией таких спанов на уровне Collector, что позвоночило пользователя сосредоточиться на действительно важных событиях.
Особый вызов представляла событийная архитектура с паттерном Rapids & Rivers, где запросы могут проходить сквозь множество подписчиков. Увеличение лимита размера трассы до 40 Мб помогло увидеть полную картину, но этот вопрос остаётся открытым, и сообщество рассматривает варианты улучшения посредством связанных спанов. Разные языки программирования привнесли свои сложности. Несмотря на популярность Java и Kotlin, Node.js приложения требовали дополнительной настройки, включая исправление ошибок с правами доступа в контейнерах и ручное добавление traceparent заголовков для правильной корреляции запросов.
Разработчики NAV смогли самостоятельно найти обходные пути и добиться стабильного функционирования. Также была выявлена сложность с автоматическим перехватом логов, где чувствительная информация могла попадать в универсальные каналы. Для управления этим была введена необходимость явного включения функции экспорта логов, что позволило повысить безопасность и контроль за телеметрией. Глядя в будущее, NAV планирует совершенствовать работу с OpenTelemetry, внедряя шаблоны и готовые панели для Grafana, чтобы уменьшить затраты времени команд на построение визуализаций. Новые функции, такие как Span Metrics, дадут возможность генерации метрик на основе трассировочных данных, что расширит возможности анализа и мониторинга.
