Налаштування Datadog APM для Distributed Tracing: посібник

Уявіть: запит до кошика займає 2 секунди замість 200 мс. Без трейсингу день іде на перебір сервісів. Datadog APM показує, що 80% часу йде на виклик inventory-service — і одразу видно, що проблема в неоптимальному SQL запиті. Кореляція трейсів з логами дозволяє побачити точну помилку без перемикання між системами, заощаджуючи до 4 годин на день на налагодженні.

Ми налаштовуємо Datadog APM для distributed tracing у мікросервісній архітектурі. Без грамотного трейсингу кожен 500-мілісекундний сплеск перетворюється на детектив. Datadog пропонує трейсинг як частину єдиної платформи — без окремого Jaeger-колектора або Elasticsearch. Агент Datadog приймає трейси і відправляє в хмару, де вони автоматично корелюють з метриками, логами та профілями. Це головна перевага — і головне обмеження: ви залежите від SaaS і платите за обсяг даних. Але для 80% компаній це окупається зниженням MTTR на 60% і економією до $2000 на місяць на інфраструктурі логування для 10 мікросервісів.

Як Datadog APM спрощує трасування мікросервісів?

Схема проста: dd-agent як DaemonSet у Kubernetes приймає трейси від додатків через localhost:8126 (або через Unix socket), агрегує і шле в Datadog. Додаток інструментується через dd-trace бібліотеку. Datadog Agent у Kubernetes встановлюється через Helm:

helm repo add datadog https://helm.datadoghq.com
helm install datadog datadog/datadog \
  --set datadog.apiKey=${DD_API_KEY} \
  --set datadog.apm.portEnabled=true \
  --set agents.containers.agent.env[0].name=DD_APM_ENABLED \
  --set agents.containers.agent.env[0].value=true

Додатку потрібно знати адресу агента. Через Downward API:

---
env:
  - name: DD_AGENT_HOST
    valueFrom:
      fieldRef:
        fieldPath: status.hostIP
  - name: DD_TRACE_AGENT_PORT
    value: "8126"
  - name: DD_SERVICE
    value: "product-service"
  - name: DD_ENV
    value: "production"
  - name: DD_VERSION
    valueFrom:
      fieldRef:
        fieldPath: metadata.labels['tags.datadoghq.com/version']

Встановлення займає 15 хвилин для одного кластера. Агент автоматично виявляє сервіси через Service Discovery і починає отримувати трейси.

Чому Unified Service Tagging критичний для кореляції?

Unified Service Tagging — основа кореляції. Три теги env, service, version мають бути узгоджені між метриками, логами та трейсами. Тоді Datadog вміє автоматично корелювати деплой версії зі зміною error rate у трейсах. Найкращий спосіб задати теги — через labels на Kubernetes Pod:

---
labels: tags.datadoghq.com/env: production tags.datadoghq.com/service: product-service tags.datadoghq.com/version: "1.4.2" 
---

Datadog Agent читає ці labels і автоматично проставляє їх у трейси — інструментувати вручну не потрібно. Це гарантує, що при деплої нової версії Service Map одразу покаже зміну поведінки.

Інструментування: auto vs manual

Для більшості фреймворків Datadog надає auto-instrumentation: достатньо додати бібліотеку, і вона патчить стандартні клієнти HTTP, БД, черг. Node.js приклад:

// Має бути першим імпортом
const tracer = require('dd-trace').init({
  service: 'product-service',
  env: process.env.DD_ENV,
  version: process.env.DD_VERSION,
  logInjection: true,
});

logInjection: true — обов'язкове налаштування. Без нього кореляція логів і трейсів працювати не буде. Auto-instrumentation покриває 20+ фреймворків, включаючи Express, Django, Spring Boot, і займає 5-10 хвилин на сервіс.

Service Map та APM метрики

Datadog автоматично будує Service Map із трейсів — граф залежностей із latency та error rate на кожному ребрі. Це працює без додаткової конфігурації та оновлюється кожні 5 секунд. APM Metrics (trace.http.request.hits, trace.http.request.errors, trace.http.request.duration) генеруються автоматично з тегами сервісу, ресурсу, HTTP-статусу. На їхній основі можна будувати SLO прямо в Datadog без написання Prometheus-правил. Термін зберігання метрик — 15 місяців, трейсів — 30 днів (за замовчуванням).

Порівняння: Datadog APM vs OpenTelemetry

Datadog APM впроваджується в 3-5 разів швидше, ніж самостійна збірка з OpenTelemetry + Jaeger + Prometheus. Це скорочує середній час відновлення (MTTR) на 60% і економить до $2000 на місяць на інфраструктурі логування за рахунок кореляції.

Adaptive Sampling та налаштування

Datadog використовує Adaptive Sampling на стороні агента: агент сам вирішує, який відсоток трейсів надсилати, виходячи з поточного обсягу. Ручне налаштування через DD_TRACE_SAMPLE_RATE — фіксована частка (0.0–1.0). Для error traces Datadog завжди зберігає 100% — це не налаштовується. Рекомендуємо залишити адаптивний режим: він дає хороше покриття без перевищення бюджету. Зв'яжіться з нами для аудиту вашої системи трейсингу — ми проаналізуємо поточний обсяг і оптимізуємо sampling.

Процес роботи

Налаштування Datadog APM під ключ включає етапи:

• Аналітика: аудит поточної архітектури, визначення ключових сервісів, оцінка обсягів трейсів (зазвичай 2-3 дні).
• Проектування: схема тегів UST, стратегія sampling, інтеграція з CI/CD для автоматичного проставляння version.
• Реалізація: встановлення dd-agent через Helm, інструментування сервісів, налаштування кореляції логів (2-4 дні для 10 сервісів).
• Тестування: перевірка наскрізних трейсів на dev-оточенні, валідація SLO, навантажувальне тестування.
• Деплой: викат у production, моніторинг метрик APM, налаштування алертів.

Терміни та доставка

Базова установка dd-agent + автоінструментування 3-5 сервісів займає 2-3 дні. Включає UST-теги, кореляцію логів, Service SLO в Datadog, документацію. Для 10+ сервісів потрібно 5-7 днів. Оцінимо ваш проєкт — надішліть опис архітектури.

Що входить у роботу

• Встановлення та конфігурація Datadog Agent у Kubernetes (через Helm).
• Інструментування мікросервісів (auto або manual).
• Налаштування Unified Service Tagging.
• Кореляція логів з трейсами (log injection).
• Створення Service SLO на основі APM Metrics.
• Документація та навчання команди.

Сертифіковані інженери з досвідом понад 5 років у Datadog та Kubernetes реалізували 50+ проєктів з observability. Гарантуємо SLA на впровадження — під ключ за обумовлений термін. Замовте консультацію, щоб обговорити деталі. Детальніше про розподілене трасування.