OpenTelemetry éles környezetben: A sötétben végzett hibakeresés leállítása

Nem akkor van először igazán szükséged a megfigyelhetőségre, ha nyugodtan nézel egy műszerfalat. Amikor a felhasználó azt írja ki, hogy "lassú a kijelentkezés", a hibadiagram normálisnak tűnik, és a naplókban csak egy sor megszakadt üzenet található.

A OpenTelemetry azért jött létre, hogy elkerüljük ezt a pillanatot: nem azért, hogy több grafika legyen, hanem hogy összekapcsoljuk a darabokat. Egy kérés belép a API-be, felhív egy adatbázist, átmegy egy külső szolgáltatón, felad egy sorban állást, és később három szolgáltatás is meghiúsul. Elosztott nyomkövetés nélkül kézzel rekonstruálhatja a történetet. A OpenTelemetry-vel legalább van térképed.

A lényeg nem a trace, hanem a történet

A trace a span sorozata. Így fogalmazva hidegnek hangzik. A gyakorlatban minden span a történet egy darabja: POST /checkout, SELECT inventory, call payment provider, publish order.created.

Az érték akkor jön létre, amikor elkezdesz válaszolni a valódi kérdésekre:

melyik külső szolgáltatás lassul?
a hibák egy adott verzióból származnak?
mindenkit érint a probléma vagy csak egy bérlőt?
az újrapróbálkozás időtúllépést rejt?
az aszinkron munka elindul, de máshol meghal?

Ezeket a kérdéseket nem lehet megoldani egy sietve dobott console.log-vel. Valójában gyakran a vészhelyzetben hozzáadott napló ma segít, holnap pedig zaj lesz.

Hogyan helyezném el ezt egy alkalmazásban Node.js

A legegészségesebb beállítás egyszerű: az alkalmazás telemetriát állít elő, a Collector dönti el, hova küldje.

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

Miért nem exportálhatja közvetlenül az eladóhoz? Mivel eleinte gyorsabbnak tűnik, aztán rájössz, hogy minden szolgáltatás más-más konfigurációval, különböző újrapróbálkozásokkal, különböző szűrőkkel rendelkezik, és nincs központi pont az érzékeny adatok eltávolítására vagy a célhely megváltoztatására.

A Collector a megfelelő módon unalmas. OTLP fogad, kötegelést végez, tud szűrni, mintavételt végezni, általános attribútumokat adhat hozzá, és több rendszerbe is exportálhat.

Önműszer: jó, de nem elég

A Node.js-ben az automatikus műszerezéssel kezdeném. Azonnali rálátást biztosít a HTTP-re, a támogatott keretrendszerekre, adatbázisokra és általános könyvtárakra.

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

Ezután inicializálja a SDK-t az alkalmazás többi része előtt:

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();

Ez azonban a keretet látja, nem a termékét. Tudja, hogy lekérdezést hajtott végre, de nem tudja, hogy a lekérdezés „megrendelés létrehozása” vagy „előfizetés megújítása” volt. Ehhez span kézikönyvre van szüksége azokon a pontokon, ahol a dominancia számít.

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 kézikönyveket nem tennék sehova. Oda tenném őket, ahol hajnali háromkor szeretném megérteni, mi történt anélkül, hogy elolvasnám a fél kódbázist.

Három szabály, amely elkerüli a sok káoszt

Első szabály: minden szolgáltatásnak rendelkeznie kell service.name-vel, környezettel és verzióval. Triviálisnak tűnik, de ezen attribútumok nélkül a trace sokkal kevésbé hasznos. Ha egy központi telepítés megszakít valamit, két másodpercen belül verzió szerint kell szűrni.

Második szabály: ne tegyen érzékeny adatokat az attribútumok közé. Az e-mailek, tokenek, egész számok és címek nem kerülhetnek véletlenül megfigyelhetőségi háttérrendszerbe. Ha azonosítania kell egy felhasználót, vegye figyelembe a belső azonosítókat, a hash-t vagy a kevésbé érzékeny mezőket.

Harmadik szabály: figyelj a kardinalitásra. A user.id mint az trace attribútuma értelmes lehet. Mérési címkeként tönkreteheti költségeit és teljesítményét.

Mutatók: kevés, de jó

Nagyon praktikus mérőszámokkal kezdeném:

a kérések aránya, hibái és időtartama;
külső függőségek késleltetése;
időtúllépések és újrapróbálkozások száma;
a farok mélysége;
a munkavégzés időtartama;
a hibák százalékos aránya verziónként.

A többit hozzáadjuk, ha szükséges. A grafikonokkal teli műszerfalak, amelyeket senki sem néz meg, bútorok, nem megfigyelhetőség.

Naplók: Még mindig hasznos, de linkelve

A naplók nem tűnnek el. Egyszerűen sokkal hasznosabbá válnak, ha trace_id és span_id jelet hordoznak. Tehát elindíthatja egy hibanaplóból, és megnyithatja a trace-t, vagy kezdheti a lassú trace-t, és csak az ezen az útvonalon előállított naplókat olvashatja el.

Korreláció nélkül tűket keresel. A korrelációval legalább tudod, melyik fiókba nézz.

Az ellenőrző lista, amelyet használnék, mielőtt azt mondanám, hogy "elég vagyunk"

A trace valójában több szolgáltatást is keresztez.
A naplók közé tartozik a trace_id és a span_id.
A Collector kötegelési és memóriakorlátokkal van konfigurálva.
A hibákat a span tartalmazza.
Van mintavételi szabályzat.
A mérőszámok szabályozták a kardinalitást.
Az érzékeny adatok kiszűrésre kerülnek.
A riasztások a felhasználói tünetekből indulnak ki, nem véletlenszerű grafikonokból.

Következtetés

A OpenTelemetry önmagában nem oldja meg a termelési problémákat. De megváltozik a velük való bánásmód. A naplók vakon történő hozzáadása helyett elkezdi követni a kérés tényleges elérési útját.

Számomra a jele annak, hogy működik, egyszerű: ha valami történik, a csapat abbahagyja a „hol keresünk?” kérdést. és elkezdi kérdezni "miért lassú az a darab?". Ekkor válik a megfigyelhetőség eszközzé, nem pedig műszerfalak gyűjteményévé.

Források