Зауважте: коли 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: покрокова інструкція
- Встановіть пакети:
npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-trace-otlp-http. - Створіть файл
tracing.ts(імпортуйте першим). - Налаштуйте експортер: вкажіть URL Jaeger або іншого бекенду.
- Додайте авто-інструментації для HTTP, Express, PostgreSQL, Redis тощо.
- Запустіть 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?
| Zipkin | Jaeger | |
|---|---|---|
| Сховище | MySQL, Elasticsearch, Cassandra | Elasticsearch, Cassandra, Kafka |
| UI | Базовий | Більш багатий |
| OTel підтримка | Є | Нативна |
| Sampling | Базове | Розширене |
Для нових проєктів — Jaeger. Zipkin — якщо вже використовується або потрібна сумісність. Jaeger в середньому в 1.5–2 рази швидше розгортається та надає більш детальні дашборди. Ми гарантуємо, що обраний бекенд буде оптимально інтегрований у вашу інфраструктуру.
Як налаштувати sampling під навантаження?
OpenTelemetry Specification рекомендує head-based sampling для високонавантажених систем.
| Стратегія | Відсоток захвату | Ресурси | Коли застосовувати |
|---|---|---|---|
| Head-based (з ймовірністю) | 1–10% | Низькі | Високонавантажені системи з великим обсягом трейсів |
| Tail-based | 100% з фільтрацією | Високі | Потрібні всі трейси з помилками, рідкісні події |
Приклад конфігурації head-based sampling з OpenTelemetry:
import { ParentBasedSampler, TraceIdRatioBased } from '@opentelemetry/sdk-trace-base'; const sampler = new ParentBasedSampler({ root: new TraceIdRatioBased(0.1) }); Так ви відстежуєте 10% запитів, але завжди — якщо батьківський вже відстежується.
Приклад конфігурації tail-based sampling з OpenTelemetry Collector
Tail-based sampling вимагає OpenTelemetry Collector з функцією tail_sampling. Конфігурація:
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 скоротить час налагодження у вашій системі.