Monitoring s OpenTelemetry: kde sa stratila objednávka?

Úspešné HTTP nie je vybavená objednávka

V ilustračnom e-shope server prijme objednávku a vráti HTTP 202. Worker ju má odovzdať do ERP. Zákazník vidí potvrdenie, ale pracovník skladu objednávku nenájde. Monitoring dostupnosti ukazuje zelenú: web aj API odpovedajú. Tím potrebuje poznať stav celého procesu, pretože úspešné prijatie požiadavky ešte nepotvrdzuje výsledok ďalšieho spracovania.

Najprv pomenujte pozorovateľné stavy: prijatá, čakajúca, odovzdaná, potvrdená alebo zlyhaná. Určte, ktorý systém je pre každý stav rozhodujúci. Ak ERP nevydáva potvrdenie, integrácia nemá predstierať dokončenie iba podľa odoslaného HTTP volania. Tento model poslúži aj podpore, ktorá musí zákazníkovi povedať, čo sa s objednávkou skutočne deje.

Metriky ukážu rozsah, trace konkrétnu cestu

Metriky odpovedia, koľko objednávok čaká a ako dlho trvá spracovanie. Logy zachytia jednotlivé udalosti a vysvetlenie zlyhania. Trace spojí časové úseky práce naprieč službami. OpenTelemetry prenáša identifikátory kontextu, aby prijímateľ vedel priradiť svoju činnosť k predchádzajúcemu kroku. Samotná inštalácia knižnice však nepozná obchodné stavy objednávky.

V návrhu zaznamenajte prijatie, zápis do fronty, pokus workera a odpoveď ERP. Log chyby môže obsahovať trace ID a interný identifikátor pokusu bez celého zákazníckeho payloadu. Ak tím sleduje iba trvanie webového requestu, dvojhodinové čakanie vo fronte zostane mimo merania. Preto treba merať aj vek najstaršej čakajúcej úlohy a čas od prijatia po potvrdenie.

Kontext musí prejsť aj asynchrónnou hranicou

Pri zaradení správy preneste povolený trace kontext v metadátach a pri spracovaní ho načítajte podporovanou propagáciou. Model väzby medzi producentom a konzumentom zvoľte podľa použitého messaging nástroja. Pri dávke alebo opakovaných pokusoch môže byť vhodné prepojenie spanov. Jeden znovu použitý span pre všetky retry by skresľoval samostatné pokusy aj ich trvanie.

Identifikátor udalosti a identifikátor trace majú odlišný účel. Udalosť zostáva tá istá aj pri novom pokuse; jej identita môže chrániť pred duplicitným obchodným účinkom. Trace pomáha diagnostike. V ilustračnom návrhu stav udalosti uchováva databáza a telemetria vysvetľuje jednotlivé pokusy. Výpadok exportu traces preto nesmie vymazať evidenciu vybavených objednávok.

Do metrík nedávajte každé číslo objednávky

Label metriky vytvára samostatný časový rad pre každú kombináciu hodnôt. ID objednávky, e-mail alebo úplná URL s parametrami vytvoria rastúci počet kombinácií. Prometheus preto odporúča vyhnúť sa neobmedzeným hodnotám labelov. Pre čas spracovania sú užitočnejšie konečné kategórie, napríklad typ integrácie a výsledok pokusu.

Konkrétnu objednávku dohľadajte v chránenej evidencii a povolených logoch. Určte retenčné lehoty, prístup a maximálny objem telemetrie. Sampling pomáha riadiť náklady, ale neznamená, že sa zachová každý problém. Pre zriedkavé chyby si tím musí overiť použitú stratégiu aj správanie pri preťažení. Biznis evidencia nemôže závisieť od náhodného zachovania trace.

Prenos kontextu nie je prenos oprávnenia

OpenTelemetry baggage môže preniesť doplnkové hodnoty cez viac služieb. Nie je vhodným miestom pre heslá, tokeny alebo celý profil zákazníka. Hlavičky môžu pokračovať aj do externého volania. Hodnota tenant_id prijatá v baggage tiež nedokazuje, že používateľ do daného klienta patrí. Autorizácia musí vychádzať z overenej identity a pravidiel servera.

Nastavte výslovný zoznam povolených atribútov a odstraňujte citlivé hodnoty pred exportom. Vhodné kontroly patria do aplikácie aj telemetrického pipeline. Preverte automaticky zachytávané URL, exception texty a databázové parametre. Chybová správa z externého systému môže obsahovať osobné údaje, aj keď ich aplikácia do logu zámerne nepridáva.

Upozornenie musí viesť k zásahu

Pre ilustračnú integráciu môže tím dohodnúť upozornenie pri prekročení povoleného veku čakajúcej objednávky. Konkrétny čas odvodí od prevádzky skladu, nie od predvoleného dashboardu. Upozornenie má obsahovať dotknutú integráciu, rozsah problému a odkaz na postup riešenia. Opakované správy bez zodpovednej osoby a možnosti zásahu rýchlo stratia účinok.

• Simulovaný výpadok ERP vytvorí upozornenie, aj keď webové API stále odpovedá.
• Jedna udalosť sa dá dohľadať cez frontu a všetky jej pokusy.
• Testovací token ani osobné údaje sa neobjavia v exportovanej telemetrii.
• Výpadok telemetrie neovplyvní dokončenie a evidenciu objednávky.

Od témy ku konkrétnemu riešeniu.