При участии Dan Gomez Blanco (New Relic). Если вы разрабатываете программное обеспечение для самостоятельного развёртывания или SaaS-продукт, пользователи рано или поздно попросят отправлять логи, трассировки и метрики в их собственный стек наблюдаемости. Привязка их к встроенным дашбордам или ограничение экспорта определёнными вендорами создаёт ненужные трудности. Вместо этого поддержка экспорта в любой бэкенд, совместимый с Open Telemetry (OTel), — это нейтральный к вендорам и перспективный подход, который даёт пользователям свободу выбора стека наблюдаемости.
В этой статье описано, как спроектировать продукт так, чтобы пользователи могли экспортировать логи, трассировки и метрики в бэкенд OTel, когда захотят. Open Telemetry определяет четыре типа сигналов, передаваемых по стандартному протоколу Open Telemetry Protocol (OTLP): логи (записи событий, журналы запросов и доступа, логи приложений с временными метками и метаданными), трассировки (распределённые трассировки и спаны, позволяющие видеть путь запросов между сервисами и сопоставлять их с логами), метрики (счётчики, датчики и гистограммы, например частота запросов, задержка и частота ошибок) и профили (выборки, показывающие, где приложения потребляют ресурсы во время выполнения). Схема экспорта одинакова для всех трёх сигналов: позвольте пользователям настроить OTLP-эндпоинт и отправлять туда телеметрию. Вы можете поддерживать один, два или все три сигнала в зависимости от того, что генерирует ваш продукт. Многие платформы с поддержкой экспорта OTel поддерживают как минимум трассировки и логи, а всё больше из них поддерживают и метрики. Проектирование сразу под все три сигнала позволяет избежать последующей переделки.
Хорошая стратегия экспорта обладает несколькими чёткими свойствами для каждого поддерживаемого сигнала: нейтральность к вендорам, отсутствие необходимости в глубокой кастомной разработке, сохранение богатого контекста и поддержка семантических соглашений. Нужно учитывать два контекста: где работает ваш продукт? Для программного обеспечения с самостоятельным развёртыванием инструментируйте продукт с помощью Open Telemetry и позвольте клиентам настраивать эндпоинт через переменные окружения или конфигурационный файл. Для облачных платформ добавьте функцию платформы для управления экспортом. Примеры — Keycloak и Kuma.
Источник: Hacker News · Сводку подготовил HeadlinesBriefing