Infrastruktūros stebėjimas: išsami šiuolaikinių metrikų rinkimo sistemų analizė

Mūsų hiper-susietame, skaitmeniniame pasaulyje IT infrastruktūros našumas ir patikimumas nebėra tik techniniai klausimai – tai fundamentalūs verslo imperatyvai. Nuo debesijoje veikiančių aplikacijų iki senų, vietoje laikomų serverių, sudėtingas sistemų tinklas, kuris palaiko šiuolaikines įmones, reikalauja nuolatinio budrumo. Būtent čia infrastruktūros stebėjimas, o ypač metrikų rinkimas, tampa operacinės kompetencijos pagrindu. Be jo jūs veikiate aklai.

Šis išsamus vadovas skirtas pasaulinei DevOps inžinierių, patikimumo inžinierių (SRE), sistemų architektų ir IT vadovų auditorijai. Mes gilinsimės į metrikų rinkimo sistemų pasaulį, pereidami nuo pagrindinių koncepcijų iki pažangių architektūrinių modelių ir geriausių praktikų. Mūsų tikslas – suteikti jums žinių, reikalingų sukurti ar pasirinkti stebėjimo sprendimą, kuris būtų mastelio keitimui pritaikytas, patikimas ir teiktų veiksmingas įžvalgas, nepriklausomai nuo to, kur yra jūsų komanda ar infrastruktūra.

Kodėl metrikos yra svarbios: stebimumo ir patikimumo pagrindas

Prieš gilinantis į rinkimo sistemų mechaniką, svarbu suprasti, kodėl metrikos yra tokios svarbios. Stebimumo kontekste, kuris dažnai apibūdinamas trimis ramsčiais – metrikos, žurnalai (logai) ir pėdsakai (traces) – metrikos yra pagrindinis kiekybinių duomenų šaltinis. Tai yra skaitiniai matavimai, fiksuojami laikui bėgant, kurie apibūdina sistemos būklę ir našumą.

Pagalvokite apie CPU apkrovą, atminties naudojimą, tinklo delsą ar HTTP 500 klaidų atsakymų skaičių per sekundę. Visa tai yra metrikos. Jų galia slypi efektyvume; jos yra lengvai suglaudinamos, paprastai apdorojamos ir matematiškai patogios, todėl idealiai tinka ilgalaikiam saugojimui, tendencijų analizei ir perspėjimams.

Proaktyvus problemų aptikimas

Pati tiesioginė metrikų rinkimo nauda yra galimybė aptikti problemas, kol jos neperaugo į vartotojams matomus sutrikimus. Nustatę išmaniuosius perspėjimus pagal pagrindinius veiklos rodiklius (PVR), komandos gali būti informuotos apie anomalius elgesio pokyčius – pavyzdžiui, staigų užklausų delsos padidėjimą ar disko užsipildymą – ir įsikišti prieš įvykstant kritiniam gedimui.

Informuotas pajėgumų planavimas

Kaip žinoti, kada reikia plėsti savo paslaugas? Spėliojimas yra brangus ir rizikingas. Metrikos pateikia duomenimis pagrįstą atsakymą. Analizuodami istorinius išteklių suvartojimo (CPU, RAM, saugyklos) ir aplikacijų apkrovos trendus, galite tiksliai prognozuoti ateities poreikius, užtikrindami, kad suteiksite pakankamai pajėgumų poreikiams patenkinti, nepermokėdami už nenaudojamus išteklius.

Našumo optimizavimas

Metrikos yra raktas į našumo didinimą. Ar jūsų aplikacija veikia lėtai? Metrikos gali padėti nustatyti kliūtį. Susiedami aplikacijos lygio metrikas (pvz., transakcijos laiką) su sistemos lygio metrikas (pvz., I/O laukimo laiką, tinklo prisotinimą), galite identifikuoti neefektyvų kodą, neteisingai sukonfigūruotas paslaugas ar nepakankamai aprūpintą aparatinę įrangą.

Verslo įžvalgos ir PVR

Šiuolaikinis stebėjimas peržengia techninės būklės ribas. Metrikos gali ir turėtų būti susietos su verslo rezultatais. Rinkdamos tokias metrikas kaip `vartotoju_registraciju_viso` ar `pajamos_uz_transakcija`, inžinierių komandos gali tiesiogiai pademonstruoti sistemos našumo poveikį įmonės pelnui. Šis suderinimas padeda prioritetizuoti darbus ir pagrįsti investicijas į infrastruktūrą.

Saugumas ir anomalijų aptikimas

Neįprasti sistemų metrikų modeliai dažnai gali būti pirmasis saugumo pažeidimo ženklas. Staigus, nepaaiškinamas išeinančio tinklo srauto padidėjimas, didelis CPU apkrovos šuolis duomenų bazės serveryje ar nenormalus nepavykusių prisijungimų skaičius – visa tai yra anomalijos, kurias gali aptikti patikima metrikų rinkimo sistema, suteikdama ankstyvą perspėjimą saugumo komandoms.

Šiuolaikinės metrikų rinkimo sistemos anatomija

Metrikų rinkimo sistema nėra vienas įrankis, o tarpusavyje susijusių komponentų konvejeris, kurių kiekvienas atlieka specifinį vaidmenį. Suprasti šią architektūrą yra raktas į sprendimo, atitinkančio jūsų poreikius, projektavimą.

1. Duomenų šaltiniai (taikiniai): Tai yra subjektai, kuriuos norite stebėti. Tai gali būti bet kas – nuo fizinės aparatinės įrangos iki trumpalaikių debesijos funkcijų.
2. Rinkimo agentas (rinkėjas): Programinė įranga, veikianti duomenų šaltinyje arba šalia jo, skirta rinkti metrikas.
3. Transportavimo sluoksnis (konvejeris): Tinklo protokolas ir duomenų formatas, naudojami metrikoms perkelti iš agento į saugyklą.
4. Laiko eilučių duomenų bazė (saugykla): Specializuota duomenų bazė, optimizuota laiku pažymėtų duomenų saugojimui ir užklausoms.
5. Užklausų ir analizės variklis: Kalba ir sistema, naudojama saugomoms metrikoms gauti, agreguoti ir analizuoti.
6. Vizualizacijos ir perspėjimų sluoksnis: Vartotojui skirti komponentai, kurie paverčia neapdorotus duomenis į skydelius ir pranešimus.

1. Duomenų šaltiniai (taikiniai)

Bet kas, kas generuoja vertingus našumo duomenis, yra potencialus taikinys. Tai apima:

• Fiziniai ir virtualūs serveriai: CPU, atmintis, disko I/O, tinklo statistika.
• Konteineriai ir orkestratoriai: Konteinerių (pvz., Docker) išteklių naudojimas ir orkestravimo platformos (pvz., Kubernetes API serverio, mazgų būklės) sveikata.
• Debesijos paslaugos: Valdomos paslaugos iš tiekėjų, tokių kaip AWS (pvz., RDS duomenų bazės metrikos, S3 segmento užklausos), Azure (pvz., VM būsena) ir Google Cloud Platform (pvz., Pub/Sub eilės gylis).
• Tinklo įrenginiai: Maršrutizatoriai, komutatoriai ir ugniasienės, pranešantys apie pralaidumą, paketų praradimą ir delsą.
• Aplikacijos: Individualios, verslui būdingos metrikos, instrumentuotos tiesiogiai aplikacijos kode (pvz., aktyvių vartotojų sesijos, prekės pirkinių krepšelyje).

2. Rinkimo agentas (rinkėjas)

Agentas yra atsakingas už metrikų rinkimą iš duomenų šaltinio. Agentai gali veikti įvairiais būdais:

• Eksportuotojai/Integracijos: Mažos, specializuotos programos, kurios išgauna metrikas iš trečiosios šalies sistemos (pvz., duomenų bazės ar pranešimų eilės) ir pateikia jas formatu, kurį gali suprasti stebėjimo sistema. Puikus pavyzdys yra didžiulė Prometheus eksportuotojų ekosistema.
• Įterptosios bibliotekos: Kodo bibliotekos, kurias programuotojai įtraukia į savo aplikacijas, kad metrikos būtų siunčiamos tiesiogiai iš kodo. Tai vadinama instrumentavimu.
• Bendrosios paskirties agentai: Universalūs agentai, tokie kaip Telegraf, Datadog Agent ar OpenTelemetry Collector, kurie gali rinkti platų sistemos metrikų spektrą ir priimti duomenis iš kitų šaltinių per įskiepius.

3. Laiko eilučių duomenų bazė (saugykla)

Metrikos yra laiko eilučių duomenų forma – duomenų taškų seka, indeksuota pagal laiką. Įprastos reliacinės duomenų bazės nėra skirtos unikaliam stebėjimo sistemų darbo krūviui, kuris apima itin didelius įrašymo kiekius ir užklausas, kurios paprastai agreguoja duomenis per laiko intervalus. Laiko eilučių duomenų bazė (TSDB) yra specialiai sukurta šiai užduočiai ir siūlo:

• Didelius duomenų priėmimo greičius: Gali apdoroti milijonus duomenų taškų per sekundę.
• Efektyvų glaudinimą: Pažangūs algoritmai, skirti sumažinti pasikartojančių laiko eilučių duomenų saugojimo apimtį.
• Greitas laiku pagrįstas užklausas: Optimizuota užklausoms, tokioms kaip „koks buvo vidutinis CPU panaudojimas per pastarąsias 24 valandas?“
• Duomenų saugojimo politikos: Automatinis duomenų praretinimas (senų duomenų detalumo mažinimas) ir trynimas, siekiant valdyti saugojimo išlaidas.

Populiarios atvirojo kodo TSDB apima Prometheus, InfluxDB, VictoriaMetrics ir M3DB.

4. Užklausų ir analizės variklis

Neapdoroti duomenys nėra naudingi, kol jų negalima užklausti. Kiekviena stebėjimo sistema turi savo užklausų kalbą, skirtą laiko eilučių analizei. Šios kalbos leidžia jums pasirinkti, filtruoti, agreguoti ir atlikti matematines operacijas su jūsų duomenimis. Pavyzdžiai:

• PromQL (Prometheus Query Language): Galinga ir išraiškinga funkcinė užklausų kalba, kuri yra esminė Prometheus ekosistemos savybė.
• InfluxQL ir Flux (InfluxDB): InfluxDB siūlo SQL panašią kalbą (InfluxQL) ir galingesnę duomenų scenarijų kalbą (Flux).
• SQL panašūs variantai: Kai kurios modernios TSDB, pavyzdžiui, TimescaleDB, naudoja standartinio SQL plėtinius.

5. Vizualizacijos ir perspėjimų sluoksnis

Paskutiniai komponentai yra tie, su kuriais sąveikauja žmonės:

• Vizualizacija: Įrankiai, kurie paverčia užklausų rezultatus į grafikus, šilumos žemėlapius ir skydelius. Grafana yra de facto atvirojo kodo standartas vizualizacijai, integruojamas su beveik visomis populiariomis TSDB. Daugelis sistemų taip pat turi savo integruotas vartotojo sąsajas (pvz., Chronograf, skirtas InfluxDB).
• Perspėjimai: Sistema, kuri reguliariai vykdo užklausas, vertina rezultatus pagal iš anksto nustatytas taisykles ir siunčia pranešimus, jei sąlygos yra įvykdytos. Prometheus Alertmanager yra galingas pavyzdys, tvarkantis dublikatų pašalinimą, grupavimą ir perspėjimų nukreipimą į tokias paslaugas kaip el. paštas, Slack ar PagerDuty.

Jūsų metrikų rinkimo strategijos architektūra: stūmimo (Push) ir traukimo (Pull) modeliai

Vienas iš fundamentaliausių architektūrinių sprendimų, kurį priimsite, yra ar naudoti „stūmimo“ (push) ar „traukimo“ (pull) modelį metrikoms rinkti. Kiekvienas turi aiškių privalumų ir tinka skirtingiems naudojimo atvejams.

Traukimo (Pull) modelis: paprastumas ir kontrolė

Traukimo modelyje centrinis stebėjimo serveris yra atsakingas už duomenų rinkimo inicijavimą. Jis periodiškai kreipiasi į sukonfigūruotus taikinius (pvz., aplikacijų egzempliorius, eksportuotojus) ir „nuskaito“ (scrapes) esamas metrikų vertes iš HTTP galinio taško.

Kaip tai veikia: 1. Taikiniai pateikia savo metrikas konkrečiame HTTP galiniame taške (pvz., `/metrics`). 2. Centrinis stebėjimo serveris (pvz., Prometheus) turi šių taikinių sąrašą. 3. Nustatytu intervalu (pvz., kas 15 sekundžių) serveris siunčia HTTP GET užklausą į kiekvieno taikinio galinį tašką. 4. Taikinys atsako su savo esamomis metrikos, o serveris jas išsaugo.

Privalumai:

• Centralizuota konfigūracija: Galite tiksliai matyti, kas yra stebima, peržiūrėję centrinio serverio konfigūraciją.
• Paslaugų aptikimas: Traukimo sistemos puikiai integruojasi su paslaugų aptikimo mechanizmais (pvz., Kubernetes ar Consul), automatiškai surasdamos ir nuskaitydamos naujus taikinius, kai jie atsiranda.
• Taikinio būklės stebėjimas: Jei taikinys neveikia ar lėtai atsako į nuskaitymo užklausą, stebėjimo sistema tai iš karto sužino. `up` metrika yra standartinė funkcija.
• Supaprastintas saugumas: Stebėjimo serveris inicijuoja visus ryšius, o tai gali būti lengviau valdyti ugniasienėmis apsaugotose aplinkose.

Trūkumai:

• Tinklo pasiekiamumas: Stebėjimo serveris turi galėti pasiekti visus taikinius per tinklą. Tai gali būti sudėtinga sudėtingose, kelių debesijų ar NAT gausiose aplinkose.
• Trumpalaikės darbo apkrovos: Gali būti sunku patikimai nuskaityti labai trumpai veikiančias užduotis (pvz., serverless funkciją ar paketų apdorojimo procesą), kurios gali neegzistuoti pakankamai ilgai iki kito nuskaitymo intervalo.

Pagrindinis atstovas: Prometheus yra ryškiausias traukimo modeliu pagrįstos sistemos pavyzdys.

Stūmimo (Push) modelis: lankstumas ir mastelis

Stūmimo modelyje atsakomybė už metrikų siuntimą tenka agentams, veikiantiems stebimose sistemose. Šie agentai renka metrikas vietoje ir periodiškai jas „stumia“ (push) į centrinį duomenų priėmimo galinį tašką.

Kaip tai veikia: 1. Agentas taikinio sistemoje renka metrikas. 2. Nustatytu intervalu agentas supakuoja metrikas ir siunčia jas per HTTP POST arba UDP paketą į žinomą stebėjimo serverio galinį tašką. 3. Centrinis serveris klausosi šio galinio taško, gauna duomenis ir įrašo juos į saugyklą.

Privalumai:

• Tinklo lankstumas: Agentams reikia tik išeinančios prieigos prie centrinio serverio galinio taško, o tai idealu sistemoms, esančioms už griežtų ugniasienių ar NAT.
• Tinka trumpalaikėms ir serverless apkrovoms: Puikiai tinka trumpai veikiančioms užduotims. Paketų apdorojimo užduotis gali nusiųsti savo galutines metrikas prieš pat baigdama darbą. Serverless funkcija gali nusiųsti metrikas baigus vykdymą.
• Supaprastinta agento logika: Agento darbas paprastas: rinkti ir siųsti. Jam nereikia paleisti web serverio.

Trūkumai:

• Duomenų priėmimo kliūtys: Centrinis duomenų priėmimo galinis taškas gali tapti kliūtimi, jei per daug agentų vienu metu siunčia duomenis. Tai žinoma kaip „griaudžiančios bandos“ (thundering herd) problema.
• Konfigūracijos išsibarstymas: Konfigūracija yra decentralizuota tarp visų agentų, todėl sunkiau valdyti ir audituoti, kas yra stebima.
• Taikinio būklės neaiškumas: Jei agentas nustoja siųsti duomenis, ar taip yra todėl, kad sistema neveikia, ar todėl, kad sugedo agentas? Sunkiau atskirti sveiką, tylią sistemą nuo neveikiančios.

Pagrindiniai atstovai: InfluxDB rinkinys (su Telegraf kaip agentu), Datadog ir originalus StatsD modelis yra klasikiniai stūmimo modeliu pagrįstų sistemų pavyzdžiai.

Hibridinis požiūris: geriausia iš abiejų pasaulių

Praktikoje daugelis organizacijų naudoja hibridinį požiūrį. Pavyzdžiui, galite naudoti traukimo modeliu pagrįstą sistemą, tokią kaip Prometheus, kaip pagrindinį stebėjimo įrankį, bet naudoti įrankį, pvz., Prometheus Pushgateway, kad aptarnautumėte tas kelias paketų apdorojimo užduotis, kurių negalima nuskaityti. Pushgateway veikia kaip tarpininkas, priimdamas stumiamas metrikas ir tada pateikdamas jas Prometheus nuskaitymui.

Pasaulinė pirmaujančių metrikų rinkimo sistemų apžvalga

Stebėjimo peizažas yra platus. Štai keletas įtakingiausių ir plačiausiai naudojamų sistemų, nuo atvirojo kodo gigantų iki valdomų SaaS platformų.

Atvirojo kodo galybė: Prometheus ekosistema

Iš pradžių sukurta SoundCloud ir dabar tapusi Cloud Native Computing Foundation (CNCF) baigtu projektu, Prometheus tapo de facto standartu stebėjimui Kubernetes ir debesijos pasaulyje. Tai yra visa ekosistema, sukurta aplink traukimo modelį ir jo galingą užklausų kalbą, PromQL.

• Stiprybės:
  • PromQL: Neįtikėtinai galinga ir išraiškinga kalba laiko eilučių analizei.
  • Paslaugų aptikimas: Vidinė integracija su Kubernetes, Consul ir kitomis platformomis leidžia dinamiškai stebėti paslaugas.
  • Plati eksportuotojų ekosistema: Didžiulė bendruomenės palaikoma eksportuotojų biblioteka leidžia stebėti beveik bet kokią programinę ar aparatinę įrangą.
  • Efektyvus ir patikimas: Prometheus yra sukurtas būti ta viena sistema, kuri veikia, kai visa kita genda.
• Apsvarstymai:
  • Vietinės saugyklos modelis: Vienas Prometheus serveris saugo duomenis savo vietiniame diske. Ilgalaikiam saugojimui, aukštam pasiekiamumui ir globaliam vaizdui per kelis klasterius reikia jį papildyti tokiais projektais kaip Thanos, Cortex ar VictoriaMetrics.

Didelio našumo specialistas: InfluxDB (TICK) rinkinys

InfluxDB yra specialiai sukurta laiko eilučių duomenų bazė, žinoma dėl didelio našumo duomenų priėmimo ir lankstaus duomenų modelio. Ji dažnai naudojama kaip TICK Stack dalis – atvirojo kodo platforma, skirta laiko eilučių duomenims rinkti, saugoti, vizualizuoti ir perspėti.

• Pagrindiniai komponentai:
  • Telegraf: Įskiepiais paremtas, bendrosios paskirties rinkimo agentas (stūmimo modelis).
  • InfluxDB: Didelio našumo TSDB.
  • Chronograf: Vartotojo sąsaja vizualizacijai ir administravimui.
  • Kapacitor: Duomenų apdorojimo ir perspėjimų variklis.
• Stiprybės:
  • Našumas: Puikus įrašymo ir užklausų našumas, ypač didelio kardinalumo duomenims.
  • Lankstumas: Stūmimo modelis ir universalus Telegraf agentas daro jį tinkamu įvairiems naudojimo atvejams, neapsiribojant infrastruktūra, pavyzdžiui, daiktų internetui (IoT) ir realaus laiko analitikai.
  • Flux kalba: Naujesnė Flux užklausų kalba yra galinga, funkcinė kalba sudėtingam duomenų transformavimui ir analizei.
• Apsvarstymai:
  • Klasterizavimas: Atvirojo kodo versijoje klasterizavimo ir aukšto pasiekiamumo funkcijos istoriškai buvo komercinio enterprise pasiūlymo dalis, nors tai keičiasi.

Atsirandantis standartas: OpenTelemetry (OTel)

OpenTelemetry, tikėtina, yra stebimumo duomenų rinkimo ateitis. Kaip dar vienas CNCF projektas, jo tikslas yra standartizuoti, kaip mes generuojame, renkame ir eksportuojame telemetrijos duomenis (metrikas, žurnalus ir pėdsakus). Tai nėra galinė sistema kaip Prometheus ar InfluxDB; tai yra tiekėjų atžvilgiu neutralus API, SDK ir įrankių rinkinys instrumentavimui ir duomenų rinkimui.

• Kodėl tai svarbu:
  • Tiekėjų neutralumas: Instrumentuokite savo kodą vieną kartą su OpenTelemetry, ir galėsite siųsti savo duomenis į bet kurią suderinamą galinę sistemą (Prometheus, Datadog, Jaeger ir t. t.), tiesiog pakeisdami OpenTelemetry Collector konfigūraciją.
  • Vieningas rinkimas: OpenTelemetry Collector gali priimti, apdoroti ir eksportuoti metrikas, žurnalus ir pėdsakus, suteikdamas vieną agentą, kurį reikia valdyti visiems stebimumo signalams.
  • Ateities užtikrinimas: OpenTelemetry priėmimas padeda išvengti priklausomybės nuo tiekėjo ir užtikrina, kad jūsų instrumentavimo strategija atitinka pramonės standartą.

Valdomi SaaS sprendimai: Datadog, New Relic ir Dynatrace

Organizacijoms, kurios nori atsikratyti savo stebėjimo infrastruktūros valdymo, programinės įrangos kaip paslaugos (SaaS) platformos siūlo patrauklią alternatyvą. Šios platformos teikia vieningą, „viskas viename“ sprendimą, kuris paprastai apima metrikas, žurnalus, APM (aplikacijų našumo stebėjimą) ir daugiau.

• Privalumai:
  • Paprastas naudojimas: Greitas paleidimas su minimaliomis operacinėmis sąnaudomis. Tiekėjas rūpinasi mastelio keitimu, patikimumu ir priežiūra.
  • Integruota patirtis: Sklandus metrikų susiejimas su žurnalais ir aplikacijų pėdsakais vienoje vartotojo sąsajoje.
  • Pažangios funkcijos: Dažnai iškart siūlo galingas funkcijas, tokias kaip dirbtiniu intelektu paremtas anomalijų aptikimas ir automatizuota pagrindinės priežasties analizė.
  • Įmonės lygio palaikymas: Prieinamos specializuotos palaikymo komandos, padedančios su diegimu ir problemų sprendimu.
• Trūkumai:
  • Kaina: Gali tapti labai brangu, ypač dideliu mastu. Kaina dažnai priklauso nuo serverių skaičiaus, duomenų apimties ar individualių metrikų.
  • Priklausomybė nuo tiekėjo: Migracija nuo SaaS tiekėjo gali būti didelis iššūkis, jei stipriai pasikliaujate jų patentuotais agentais ir funkcijomis.
  • Mažiau kontrolės: Turite mažiau kontrolės duomenų konvejeriui ir galite būti apriboti platformos galimybėmis bei duomenų formatais.

Pasaulinės geriausios metrikų rinkimo ir valdymo praktikos

Nepriklausomai nuo pasirinktų įrankių, laikydamiesi geriausių praktikų rinkinio užtikrinsite, kad jūsų stebėjimo sistema išliks mastelio keitimui pritaikyta, valdoma ir vertinga jūsų organizacijai augant.

Standartizuokite savo pavadinimų suteikimo taisykles

Nuosekli pavadinimų schema yra kritiškai svarbi, ypač pasaulinėms komandoms. Dėl jos metrikas lengva rasti, suprasti ir užklausti. Įprasta taisyklė, įkvėpta Prometheus, yra:

posistemė_metrika_vienetas_tipas

• posistemė: Komponentas, kuriam priklauso metrika (pvz., `http`, `api`, `duomenubaze`).
• metrika: Aprašymas, kas yra matuojama (pvz., `uzklausos`, `delsa`).
• vienetas: Pagrindinis matavimo vienetas, daugiskaita (pvz., `sekundes`, `baitai`, `uzklausos`).
• tipas: Metrikos tipas, skaitikliams tai dažnai yra `_viso` (pvz., `http_uzklausos_viso`).

Pavyzdys: `api_http_uzklausos_viso` yra aiškus ir nedviprasmiškas.

Atsargiai naudokite kardinalumą

Kardinalumas reiškia unikalių laiko eilučių skaičių, kurį sukuria metrikos pavadinimas ir jo etikečių (raktas-reikšmė porų) rinkinys. Pavyzdžiui, metrika `http_uzklausos_viso{metodas="GET", kelias="/api/vartotojai", busena="200"}` atstovauja vieną laiko eilutę.

Didelis kardinalumas, kurį sukelia etiketės su daug galimų verčių (pvz., vartotojų ID, konteinerių ID ar užklausų laiko žymės), yra pagrindinė našumo ir sąnaudų problemų priežastis daugelyje TSDB. Tai dramatiškai padidina saugyklos, atminties ir CPU poreikius.

Geriausia praktika: Apgalvotai naudokite etiketes. Naudokite jas žemo ir vidutinio kardinalumo dimensijoms, kurios yra naudingos agregavimui (pvz., galinis taškas, būsenos kodas, regionas). NIEKADA nenaudokite neribotų verčių, tokių kaip vartotojų ID ar sesijų ID, kaip metrikų etikečių.

Apibrėžkite aiškias duomenų saugojimo politikas

Aukštos raiškos duomenų saugojimas amžinai yra nepaprastai brangus. Būtina pakopinė saugojimo strategija:

• Neapdoroti, aukštos raiškos duomenys: Laikykite trumpą laiką (pvz., 7–30 dienų) išsamiam, realaus laiko problemų sprendimui.
• Praretinti, vidutinės raiškos duomenys: Agreguokite neapdorotus duomenis į 5 minučių ar 1 valandos intervalus ir laikykite juos ilgesnį laiką (pvz., 90–180 dienų) tendencijų analizei.
• Agreguoti, žemos raiškos duomenys: Laikykite stipriai agreguotus duomenis (pvz., dienos suvestines) metus ar ilgiau ilgalaikiam pajėgumų planavimui.

Įgyvendinkite „stebėjimą kaip kodą“

Jūsų stebėjimo konfigūracija – skydeliai, perspėjimai ir rinkimo agentų nustatymai – yra kritinė jūsų aplikacijos infrastruktūros dalis. Ji turėtų būti traktuojama būtent taip. Laikykite šias konfigūracijas versijų kontrolės sistemoje (pvz., Git) ir valdykite jas naudodami infrastruktūros kaip kodo įrankius (pvz., Terraform, Ansible) ar specializuotus operatorius (pvz., Prometheus Operator, skirtą Kubernetes).

Šis požiūris suteikia versijavimą, kodo peržiūrą ir automatizuotus, pakartojamus diegimus, o tai yra būtina valdant stebėjimą dideliu mastu keliose komandose ir aplinkose.

Sutelkite dėmesį į veiksmingus perspėjimus

Perspėjimų tikslas yra ne pranešti apie kiekvieną problemą, o pranešti apie problemas, kurioms reikalingas žmogaus įsikišimas. Nuolatiniai, mažos vertės perspėjimai sukelia „perspėjimų nuovargį“, kai komandos pradeda ignoruoti pranešimus, įskaitant ir kritinius.

Geriausia praktika: Perspėti apie simptomus, o ne priežastis. Simptomas yra vartotojui matoma problema (pvz., „svetainė veikia lėtai“, „vartotojai mato klaidas“). Priežastis yra pagrindinė problema (pvz., „CPU apkrova yra 90%“). Aukšta CPU apkrova nėra problema, nebent ji sukelia didelę delsą ar klaidas. Perspėdami pagal paslaugų lygio tikslus (SLO), jūs sutelkiate dėmesį į tai, kas iš tikrųjų svarbu jūsų vartotojams ir verslui.

Metrikų ateitis: nuo stebėjimo iki tikro stebimumo

Metrikų rinkimas nebėra tik CPU ir atminties skydelių kūrimas. Tai yra kiekybinis pagrindas daug platesnei praktikai: stebimumui. Galingiausios įžvalgos gaunamos susiejant metrikas su išsamiais žurnalais ir paskirstytais pėdsakais, siekiant suprasti ne tik kas yra blogai, bet ir kodėl tai blogai.

Kurdami ar tobulindami savo infrastruktūros stebėjimo strategiją, prisiminkite šias pagrindines išvadas:

• Metrikos yra pagrindas: Tai efektyviausias būdas suprasti sistemos būklę ir tendencijas laikui bėgant.
• Architektūra yra svarbi: Pasirinkite tinkamą rinkimo modelį (stūmimo, traukimo ar hibridinį) savo konkretiems naudojimo atvejams ir tinklo topologijai.
• Standartizuokite viską: Nuo pavadinimų suteikimo taisyklių iki konfigūracijos valdymo, standartizacija yra raktas į mastelio keitimą ir aiškumą.
• Žiūrėkite toliau nei įrankiai: Galutinis tikslas yra ne rinkti duomenis, o gauti veiksmingas įžvalgas, kurios pagerina sistemos patikimumą, našumą ir verslo rezultatus.

Kelionė į patikimą infrastruktūros stebėjimą yra nuolatinė. Pradėdami nuo tvirtos metrikų rinkimo sistemos, pagrįstos patikimais architektūriniais principais ir pasaulinėmis geriausiomis praktikomis, jūs klojate pagrindus atsparesnei, našesnei ir labiau stebimai ateičiai.