Mūsdienu sarežģītās IT sistēmas ģenerē milzīgi daudz datu - žurnālfailus (logs), metrikas un izsekošanas datus (traces). Tomēr bieži vien šī datu lavīna rada vairāk jautājumu nekā atbilžu. Divi vadošie OpenTelemetry eksperti, Severins Neimanis un Juraci Paišau Krolings, šī gada aprīlī notikušajā tiešsaistes konferencē “Mastering Observability” paziņoja: “Observability” nav tikai rīku kopums, bet gan inženiertehniska problēma, kurā mazāk patiesībā var nozīmēt vairāk.
Datu pārbagātība: klusais izmaksu un haosa avots
Daudzi uzņēmumi joprojām strādā pēc principa “vāc visu, izlems vēlāk”, veicot neizvēlīgu datu vākšanu, ko eksperti nodēvēja par “telemetrijas krāšanu” (Telemetry Hoarding). Šādai pieejai ir nopietnas sekas: strauji augošas izmaksas par datu uzglabāšanu, izvadu un apstrādi, pieaugoša neuzticība pašu datiem un, pats kritiskākais, garāks vidējais remonta laiks (Mean Time to Repair jeb MTTR). Tā vietā, lai proaktīvi nodrošinātu sistēmu uzticamību, komandas ir spiestas pastāvīgi “dzēst ugunsgrēkus”.
Neimanis un Krolings definē “observability” vienkārši: tā ir spēja uzdot jautājumus par sistēmu un saņemt uz tiem ticamas atbildes. Žurnālfaili, metrikas un izsekošanas dati ir tikai šī pamata pamats. Viņi piedāvā pārdomāt šo procesu ar “pulksten 2 naktī scenāriju”: ja pakalpojums sabrūk nakts vidū, kādus jautājumus uzdotu dežurējošā komanda, un vai esošie dati sniegtu atbildes? Šī perspektīva maina fokusu no “ko mēs varam savākt?” uz “kas man jāzina, lai lietotāji droši sasniegtu savu mērķi?”.
Stratēģija “augšup-lejup”: no lietotāja līdz infrastruktūrai
Eksperti iesaka pakāpenisku, “augšup-lejup” vērstu pieeju datu vākšanai. Jāsāk ar kritiskām lietotāju transakcijām, piemēram, reģistrēšanos, pirkumu veikšanu vai maksājumiem. Pēc tam jāvirzās uz pakalpojumu robežām un visbeidzot - uz zemāka līmeņa infrastruktūru, piemēram, datubāzēm, rindu sistēmām un tīklu.
Metriku jomā galvenā uzmanība jāpievērš “Zelta signāliem” (Golden Signals): reakcijas laikam (Latency), datu plūsmai (Traffic), kļūdām (Errors) un noslodzei (Saturation). Brīdinājumiem (alerts) jābūt tikai par tiem rādītājiem, kas tieši ietekmē lietotāju mērķu uzticamību, un katram brīdinājumam jābūt “darbībai” - skaidrai atbildībai un paredzamai rīcībai.
Izsekojamība kā stūrakmens: Traces un Logs
Izsekošanas dati (traces) veido šīs stratēģijas pamatu. Tā vietā, lai vāktu visu, eksperti iesaka stratēģisku datu paraugu ņemšanu (sampling) kritiskajās klientu transakcijās un selektīvu paraugu ņemšanu no citiem ceļiem, lai kontrolētu datu apjomu un izmaksas. Automātiskā instrumentācija aptver atkarības un atbalsta pakalpojumus, piemēram, datubāzes, ziņojumu starpniekus (message brokers) un ārējās API, savukārt uz kodu balstīta instrumentācija fiksē biznesa kontekstu ar atribūtiem, piemēram, order_value (pasūtījuma vērtība), tenant_id (lietotāja ID) vai feature_flag (funkciju slēdzis).
Žurnālfaili (logs), savukārt, jāglabā tikai tad, ja tie sniedz būtisku informāciju un ir saistīti ar “trace” un “span” ID, nevis vispārīgiem paziņojumiem, piemēram, [Error] Transaction failed.
Vienota valoda: OpenTelemetry Semantic Conventions
Centrālais elements ir OpenTelemetry Semantic Conventions - semantiskās konvencijas. Tās nodrošina, ka komandas, rīki un mākoņpakalpojumu sniedzēji izmanto vienādus terminus vienādā veidā. Trīs pamatnoteikumi ir: konsekvence (piemēram, vienoti deployment.environment.name = "production", nevis env = "live"), unikalitāte (viens nosaukums apzīmē precīzi vienu reālu objektu) un stabilitāte (piemēram, service.name = "checkout" ar atsevišķu service.version, nevis service.name = "checkout-v1"). Šīs konvencijas ne tikai uzlabo “signāla-trokšņa attiecību”, bet arī padara telemetriju saprotamu mašīnām. Jo īpaši AI aģentiem un uz lielo valodu modeļiem (LLM) balstītām atkļūdošanas sistēmām ir nepieciešami semantiski skaidri, konsekventi dati, lai spētu atpazīt cēloņsakarības. Vienotu konvenciju trūkums rada “Semantic Sprawl” (semantisko haosu), kas apgrūtina savietojamību starp dažādiem “backend” risinājumiem un mākoņpakalpojumiem.
Praktiski soļi un ātri ieguvumi
Ko var darīt, lai sāktu? “Collector” līmenī iespējams atbrīvoties no liela datu apjoma: audits var samazināt resursu atribūtu skaitu (piemēram, no 236 uz 85, vairāk nekā 60% samazinājums). Atkārtoti savienojuma mēģinājumu žurnālfaili, kas rada 300 identiskus ierakstus, ar deduplikācijas palīdzību var sarukt līdz vienam ierakstam par katru incidentu. SDK līmenī palīdz deklaratīva konfigurācija YAML formātā, nevis “boilerplate” kods, kā arī vienoti SDK “wrappers” katrai programmēšanas valodai. Rīki, piemēram, OpenTelemetry Weaver un uz AI balstīti aģenti, automātiski pārbauda kodu un telemetriju atbilstoši konvencijām.
Šī stratēģija ļauj lieliem uzņēmumiem ar stingrām atbilstības prasībām atbrīvoties no nevajadzīgām “debug” ziņām, dublētiem atkārtotas mēģināšanas žurnāliem un detalizētām metrikām bez tiešas saiknes ar lietotāju mērķiem. Sākšana ar vienu vai diviem biznesam kritiskiem pakalpojumiem un pakāpeniska ieviešana ir visefektīvākais veids, kā nesarežģīt ikdienas darbu. Ja vēlies uzzināt vairāk, CLC-konference, kas notiks 2026. gada 11. - 12. novembrī Manheimā, piedāvās padziļinātu informāciju par DevEx, Platform Engineering, AI aģentiem un digitālo suverenitāti.
Kā Tu nodrošini, ka Tavā uzņēmumā “observability” sniedz reālas atbildes, nevis tikai datu pārplūdi?
Iezīmē tekstu un spied ziņot par kļūdu.
