Ako narábať s protokolmi v mikroslužbách

Ťažba dreva je jednou z najdôležitejších častí softvérových systémov. Či už ste práve začali pracovať na novom softvéri, alebo váš systém beží v produkčnom prostredí veľkého rozsahu, vždy nájdete pomocníka v súboroch denníka.

Z tohto dôvodu sú protokoly prvou vecou, ​​ktorú vývojári hľadajú, keď sa niečo pokazí alebo niečo nefunguje podľa očakávaní.

Zaznamenávanie správnych informácií správnym spôsobom uľahčuje vývojárom život. A aby ste sa zlepšili v ťažbe, musíte vedieť, čo a ako sa má prihlásiť.

V tomto článku sa pozrieme na zopár základných etikiet protokolovania, ktoré vám môžu pomôcť vyťažiť z vašich protokolov maximum.

Čo sa má zaznamenávať a ako funguje protokolovanie

Začnime príkladom systému elektronického obchodu a poďme sa pozrieť na prihlásenie do jeho služby správy objednávok (OMS).

Predpokladajme, že objednávka zákazníka zlyhá kvôli chybe zo služby správy zásob (IMS), nadväzujúcej služby, ktorú OMS používa na overenie dostupného inventára.

Predpokladajme, že OMS už objednávku prijala. Počas posledného overovacieho kroku ale IMS vráti nasledujúcu chybu, pretože produkt už nie je k dispozícii v inventári.

404 Product Not Available

Čo sa má prihlásiť

Za normálnych okolností by ste chybu prihlásili týmto spôsobom:

log.error(“Exception in fetching product information - {}”, ex.getResponseBodyAsString())

Týmto sa vygeneruje protokol v nasledujúcom formáte:

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in fetching product information - Product Not Available

V tomto protokolovom vyhlásení nie je k dispozícii veľa informácií, však? Takýto denník neslúži moc, pretože mu chýbajú akékoľvek kontextové informácie o chybe.

Môžeme do tohto denníka pridať ďalšie informácie, aby bol relevantnejší pre ladenie? Čo tak pridať ID objednávky a ID produktu?

log.error("Exception in processing Order #{} for Product #{} due to exception - {}", orderId, productId, ex.getResponseBodyAsString())

Týmto sa vygeneruje protokol v nasledujúcom formáte:

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #182726 for Product #21 due to exception - Product Not Available

Toto má teraz veľký zmysel! Pri pohľade na protokoly môžeme pochopiť, že pri spracovaní objednávky č. 182726 došlo k chybe, pretože produkt č. 21 nebol k dispozícii.

Ako sa prihlásiť

Aj keď vyššie uvedený protokol má pre nás ľudí perfektný zmysel, nemusí to byť najlepší formát pre stroje. Pozrime sa na príklad, aby sme pochopili prečo.

Predpokladajme, že existuje problém v dostupnosti určitého produktu (napríklad produktu # 21), v dôsledku ktorého zlyhávajú všetky objednávky obsahujúce tento produkt. Bola vám pridelená úloha vyhľadať všetky neúspešné objednávky tohto produktu.

V grepzáznamoch šťastne urobíte produkt č. 21 a vzrušene čakáte na výsledky. Po dokončení vyhľadávania získate niečo také

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #182726 for Product #21 due to exception - Product Not Available [2020-09-27T18:53:29,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #972526 for Product #217 due to exception - Product Not Available [2020-09-27T18:52:34,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #46675754 for Product #21 due to exception - Product Not Available [2020-09-27T18:52:13,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #332254 for Product #2109 due to exception - Product Not Available

Nie celkom to, čo ste čakali, že? Ako to teda môžete vylepšiť? Štruktúrované ťaženie dreva na záchranu.

Čo je to štruktúrované protokolovanie?

Štruktúrované protokolovanie rieši tieto bežné problémy a umožňuje nástrojom na analýzu protokolov poskytnúť ďalšie funkcie. Denníky napísané v štruktúrovanom formáte sú strojovo prívetivejšie, čo znamená, že ich stroj môže ľahko analyzovať.

To môže byť užitočné v nasledujúcich scenároch:

  • Vývojári môžu prehľadávať protokoly a korelovať udalosti, čo je neoceniteľné tak počas vývoja, ako aj pri riešení problémov s produkciou.
  • Obchodné tímy môžu tieto protokoly analyzovať a vykonať analýzu v určitých poliach (napríklad jedinečný počet produktov za deň) extrakciou a zosumarizovaním týchto polí.
  • Môžete vytvoriť dashboardy (obchodné aj technické) analýzou protokolov a vykonaním agregácií cez príslušné polia.

Použijme naše skoršie vyhlásenie o protokole a urobme malú zmenu, aby bola štruktúrovaná.

log.error("Exception in processing OrderId={} for ProductId={} due to Error={}", orderId, productId, ex.getResponseBodyAsString())

Týmto sa vygeneruje protokol v nasledujúcom formáte:

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing OrderId=182726 for ProductId=21 due to Error=Product Not Available

Teraz je táto správa protokolu možno ľahko analyzovať strojom pomocou "=" ako oddeľovač na extrakciu OrderId, ProductIda Errorpolí. Teraz môžeme vykonať presný prehľad, ProductId=21aby sme splnili našu úlohu.

To nám tiež umožňuje vykonávať pokročilejšiu analýzu protokolov, napríklad pripraviť správu o všetkých objednávkach, ktoré zlyhali s takýmito chybami.

Ak používate systém správy protokolov, ako je Splunk, dotaz Error=”Product Not Available” | stats count by ProductIdmôže teraz priniesť nasledujúci výsledok:

+-----------+-------+ | ProductId | count | +-----------+-------+ | 21 | 5 | | 27 | 12 | +-----------+-------+

Mohli by sme tiež použiť rozloženie JSON na tlač našich protokolov vo formáte JSON:

{ "timestamp":"2020-09-27T18:54:41,500+0530" "level":"ERROR" "class":"InventoryValidator" "line":"13" "OrderId":"182726" "ProductId":"21" "Error":"Product Not Available" }

Je dôležité pochopiť prístup, ktorý stojí za štruktúrovaným protokolovaním. Neexistuje žiadny pevný štandard a je možné ho vykonať mnohými rôznymi spôsobmi.

Záver

V tomto článku sme videli nástrahy neštruktúrovaného ťažby dreva a výhody a výhody, ktoré ponúka štruktúrované ťaženie dreva.

Systémy na správu protokolov, ako napríklad Splunk, majú obrovskú výhodu z dobre štruktúrovanej správy o protokole a môžu ponúknuť ľahké vyhľadávanie a analýzu udalostí protokolu.

Najväčšou výzvou, pokiaľ ide o štruktúrované protokolovanie, je vytvorenie štandardnej sady polí pre váš softvér. To sa dá dosiahnuť sledovaním vlastného modelu protokolovania alebo centralizovaného protokolovania, ktoré zaručuje, že všetci vývojári používajú vo svojich správach protokolu rovnaké polia.

Ďakujem, že ste so mnou zatiaľ ostali. Dúfam, že sa vám článok páčil. Môžete sa so mnou spojiť na LinkedIn, kde pravidelne diskutujem o technológiách a živote. Prezrite si tiež niektoré moje ďalšie články. Príjemné čítanie. ?