Налаштування Distributed Tracing (Jaeger/Zipkin) для мікросервісів

Зауважте: коли p95 latency мікросервісного API несподівано злітає до 10 секунд, а логи в Order Service ідеально чисті — починається полювання на привида. У таких ситуаціях ми розгортаємо distributed tracing: OpenTelemetry + Jaeger (або Zipkin) для повної видимості. Докладніше про distributed tracing можна дізнатися у Wikipedia. Кожен запит залишає цифровий слід через усі сервіси — від API Gateway до Payment Service — з часовими мітками. Ви бачите, що 80% часу витрачається на один запит до Elasticsearch, а не на розподілене блокування. Після впровадження клієнти скорочують час діагностики з трьох тижнів до двох днів — у 3 рази швидше. Один із клієнтів заощадив $11k–16kів на рік за рахунок скорочення простоїв та швидкої локалізації проблем. Інший клієнт із 25 мікросервісами скоротив час діагностики на 70%, що призвело до економії $7.2k–10kів на рік.

Які проблеми вирішує розподілене трасування

Типова ситуація: N+1 query в Inventory Service перетворює відповідь на 5 секунд. Або Redis кеш не працює через неправильний TTL — трейс покаже відсутність кеш-хіта. Distributed tracing розкриває час у кожному сервісі, виклики БД (PostgreSQL, MongoDB), зовнішніх API та контекст propagation. Ви бачите, що 80% часу йде на один запит до Elasticsearch, а не на розподілене блокування. Ми налаштовуємо трасування, щоб виявити вузькі місця за години, а не тижні. Конкретний приклад: для одного клієнта з 15 мікросервісами distributed tracing показав, що 40% запитів зависали через неправильний таймаут в HTTP-клієнті. Виправлення зайняло 2 години замість тижня гадань.

Чому OpenTelemetry — стандарт де-факто?

OpenTelemetry (OTel) — vendor-neutral SDK, який дозволяє надсилати трейси в будь-який бекенд без зміни коду. Ми використовуємо його у всіх проєктах: один раз інтегрували, потім обираємо Jaeger для розробки, Datadog для продакшну — без переписування. Підтримка зараз вже 20+ мов та інтеграцій. Порівняно з пропрієтарними SDK, OpenTelemetry знижує час інтеграції у 2 рази та спрощує міграцію між бекендами. Наш досвід впровадження на десятках проєктів підтверджує надійність цього підходу.

Як впровадити OpenTelemetry в Node.js: покрокова інструкція

1. Встановіть пакети: npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-trace-otlp-http.
2. Створіть файл tracing.ts (імпортуйте першим).
3. Налаштуйте експортер: вкажіть URL Jaeger або іншого бекенду.
4. Додайте авто-інструментації для HTTP, Express, PostgreSQL, Redis тощо.
5. Запустіть SDK викликом sdk.start().

Приклад ініціалізації для Order Service:

// tracing.ts — ініціалізація, імпортувати до всього іншого
import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { Resource } from '@opentelemetry/resources';
import { SEMRESATTRS_SERVICE_NAME } from '@opentelemetry/semantic-conventions';

const sdk = new NodeSDK({
  resource: new Resource({
    [SEMRESATTRS_SERVICE_NAME]: 'order-service',
  }),
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT || 'http://jaeger:4318/v1/traces',
  }),
  instrumentations: [
    getNodeAutoInstrumentations({
      '@opentelemetry/instrumentation-http': {
        enabled: true,
      },
      '@opentelemetry/instrumentation-express': {
        enabled: true,
      },
      '@opentelemetry/instrumentation-pg': {
        enabled: true,
      },
      '@opentelemetry/instrumentation-redis': {
        enabled: true,
      },
    }),
  ],
});

sdk.start();

Авто-інструментації перехоплюють Express, pg, redis, axios без написання коду.

Ручне створення спанів

Для бізнес-операцій, які не перехоплюються авто-інструментацією:

import { trace, SpanStatusCode, context } from '@opentelemetry/api';

const tracer = trace.getTracer('order-service');

async function processOrder(orderId: string): Promise<void> {
  const span = tracer.startSpan('processOrder', {
    attributes: {
      'order.id': orderId,
      'service.operation': 'process'
    }
  });

  try {
    await context.with(trace.setSpan(context.active(), span), async () => {
      const order = await loadOrder(orderId);
      // дочірній спан створюється авто
      await validateOrder(order);
      await reserveInventory(order);
      // виклик іншого сервісу з propagation
      await chargePayment(order);
    });
    span.setStatus({ code: SpanStatusCode.OK });
  } catch (error) {
    span.recordException(error);
    span.setStatus({ code: SpanStatusCode.ERROR, message: error.message });
    throw error;
  } finally {
    span.end();
  }
}

Як обрати бекенд: Jaeger чи Zipkin?

Для нових проєктів — Jaeger. Zipkin — якщо вже використовується або потрібна сумісність. Jaeger в середньому в 1.5–2 рази швидше розгортається та надає більш детальні дашборди. Ми гарантуємо, що обраний бекенд буде оптимально інтегрований у вашу інфраструктуру.

Як налаштувати sampling під навантаження?

OpenTelemetry Specification рекомендує head-based sampling для високонавантажених систем.

Приклад конфігурації head-based sampling з OpenTelemetry:

import { ParentBasedSampler, TraceIdRatioBased } from '@opentelemetry/sdk-trace-base';
const sampler = new ParentBasedSampler({ root: new TraceIdRatioBased(0.1) });

Так ви відстежуєте 10% запитів, але завжди — якщо батьківський вже відстежується.

---
processors:
  tail_sampling:
    decision_wait: 30s
    num_traces: 100
    expected_new_traces_per_sec: 10
    policies:
      - name: sample_errors
        type: status_code
        properties:
          status_codes: [ERROR]
      - name: sample_slow
        type: latency
        properties:
          threshold_ms: 500

Що входить у роботу з налаштування трасування?

Ми надаємо:

• Вибір та розгортання бекенду (Jaeger/Zipkin) зі сховищем (Elasticsearch/Cassandra)
• Інтеграція OpenTelemetry SDK з авто-інструментаціями для всіх сервісів
• Ручне інструментування критичних бізнес-операцій
• Налаштування контекстного поширення через HTTP-заголовки (W3C Trace Context)
• Конфігурування sampling під навантаження
• Документація з експлуатації та дашборди в Grafana
• Навчання команди роботі з трейсами

Строки орієнтовно

• OpenTelemetry SDK + Jaeger + авто-інструментації для 3–5 сервісів — 3–5 днів
• Ручне інструментування бізнес-операцій + налаштування sampling — ще 3–5 днів
• Налаштування алертів на p95 latency через Prometheus + Grafana — 2–3 дні

Отримайте консультацію інженера — ми допоможемо обрати оптимальний бекенд та налаштувати трасування під вашу архітектуру. Замовте трасування під ключ — і ви отримаєте повну картину роботи мікросервісів. Зв'яжіться з нами, щоб оцінити ваш проект та дізнатися, як distributed tracing скоротить час налагодження у вашій системі.