OpenTelemetry ve výrobě: Zastavte ladění ve tmě

Poprvé opravdu potřebujete pozorovatelnost, když se klidně díváte na palubní desku. Když uživatel napíše "pokladna je pomalá", graf chyb vypadá normálně a v protokolech najdete pouze řadu odpojených zpráv.

OpenTelemetry byl vytvořen, aby se tomuto okamžiku vyhnul: ne proto, aby měl více grafiky, ale aby spojoval kousky. Požadavek vstoupí do API, zavolá databázi, projde externím poskytovatelem, odešle úlohu ve frontě a možná selže o tři služby později. Bez distribuovaného sledování tento příběh rekonstruujete ručně. S OpenTelemetry máte alespoň mapu.

Nejde o trace, ale o příběh

A trace je posloupnost span. Zní to tak chladně. V praxi je každé span částí příběhu: POST /checkout, SELECT inventory, call payment provider, publish order.created.

Hodnota přichází, když začnete odpovídat na skutečné otázky:

která externí služba se zpomaluje?
pocházejí chyby z konkrétní verze?
týká se problém všech nebo jen jednoho nájemce?
skrývá opakování časový limit?
asynchronní úloha se spustí, ale pak zemře někde jinde?

Tyto otázky nelze vyřešit console.log hozeným ve spěchu. Protokol přidaný v případě nouze vám často pomůže dnes a zítra se stane hlukem.

Jak bych to vložil do aplikace Node.js

Nejzdravější nastavení je jednoduché: aplikace produkuje telemetrii, Collector rozhodne, kam ji poslat.

Node.js app -> OpenTelemetry Collector -> backend di observability

Proč neexportovat přímo prodejci? Protože se to zpočátku zdá rychlejší, pak si uvědomíte, že každá služba má jiné konfigurace, jiné opakování, jiné filtry a žádný centrální bod pro odstranění citlivých dat nebo změnu cíle.

Collector je nuda ve všech správných směrech. Přijímá OTLP, provádí dávkování, umí filtrovat, umí vzorkování, může přidávat společné atributy a umí exportovat do více systémů.

Sebeinstrumentace: dobrá, ale nedostatečná

V Node.js bych začal s autoinstrumentací. Poskytuje vám okamžitý přehled o HTTP, podporovaných rámcích, databázích a běžných knihovnách.

npm install @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-http

Poté inicializujete SDK před zbytkem aplikace:

import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT,
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

To však vidí rámec, nikoli váš produkt. Ví, že jste zadali dotaz, ale neví, že dotaz byl v „vytvořit objednávku“ nebo „obnovit předplatné“. K tomu potřebujete span manuálů v bodech, kde se počítá dominance.

const span = tracer.startSpan('checkout.create_order');

try {
  span.setAttribute('cart.items_count', input.items.length);
  const order = await createOrder(input);
  span.setAttribute('order.id', order.id);
  return order;
} catch (error) {
  span.recordException(error as Error);
  throw error;
} finally {
  span.end();
}

span manuálů bych nikam nedával. Dal bych je tam, kde bych ve tři ráno rád pochopil, co se stalo, aniž bych přečetl polovinu základny kódu.

Tři pravidla, která zabrání velkému chaosu

První pravidlo: každá služba musí mít service.name, prostředí a verzi. Zdá se to triviální, ale bez těchto atributů je trace mnohem méně užitečné. Když nasazení něco pokazí, chcete filtrovat podle verze do dvou sekund.

Druhé pravidlo: nevkládejte do atributů citlivá data. E-maily, tokeny, celá čísla a adresy by neměly skončit v backendu pozorovatelnosti náhodou. Pokud potřebujete identifikovat uživatele, zvažte interní ID, hash nebo méně citlivá pole.

Třetí pravidlo: věnujte pozornost mohutnosti. user.id jako atribut trace může dávat smysl. Jako metrický štítek může zničit vaše náklady a výkon.

Metriky: málo, ale dobré

Začal bych velmi praktickými metrikami:

sazby, chyby a trvání požadavků;
latence vnějších závislostí;
počet časových limitů a opakování;
hloubka ocasů;
délka práce;
procento chyb na verzi.

Zbytek se přidá v případě potřeby. Palubní desky plné grafů, na které se nikdo nedívá, jsou nábytek, nikoli pozorovatelnost.

Protokoly: Stále užitečné, ale propojené

Protokoly nezmizí. Jednoduše se stanou mnohem užitečnějšími, když nosí trace_id a span_id. Můžete tedy začít z chybového protokolu a otevřít trace, nebo začít z pomalého trace a číst pouze protokoly vytvořené v této cestě.

Bez korelace hledáte jehly. S korelací alespoň víte, do které zásuvky se podívat.

Kontrolní seznam, který bych použil, než řeknu „jsme pokryti“

trace ve skutečnosti kříží více služeb.
Záznamy obsahují trace_id a span_id.
Collector je nakonfigurován s limity dávkování a paměti.
Chyby jsou zaznamenány v span.
Existuje zásada vzorkování.
Metriky mají řízenou mohutnost.
Citlivá data jsou filtrována.
Upozornění začínají od uživatelských příznaků, nikoli náhodných grafů.

Závěr

OpenTelemetry sama o sobě neřeší výrobní problémy. Ale způsob, jakým s nimi zacházíte, se mění. Místo slepého přidávání protokolů začnete sledovat skutečnou cestu požadavku.

Znamení, že to funguje, je pro mě jednoduché: když se něco stane, tým se přestane ptát "kam to hledáme?" a začne se ptát "proč je ten kousek pomalý?". Zde se pozorovatelnost stává nástrojem, nikoli sbírkou řídicích panelů.

Zdroje