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 aspan_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é.