Kolektorët OpenTelemetry fitojnë menaxhim qendror pa Alloy
Kolektorët OpenTelemetry tani mund të menaxhohen në mënyrë qendrore në Grafana Cloud pa kaluar fillimisht te Grafana Alloy, sipas Marko Bachvarovski të Grafana. Grafana thotë se mbështetja për Open Agent Management Protocol (OpAMP), një protokoll për menaxhimin në distancë të agjentëve softuerikë, është përgjithësisht e disponueshme në Fleet Management. Ky ndryshim e zgjeron një rrjedhë pune të ndërtuar më parë rreth Alloy edhe te shpërndarjet e mbështetura të projektit bazë OpenTelemetry Collector, pra te paketat e mbështetura të softuerit kolektor të komunitetit.
OpenTelemetry, shpesh i shkurtuar si OTel, ofron mjete për mbledhjen e telemetrisë, matjeve dhe regjistrimeve që përdoren për të kuptuar si sillet softueri. Kolektorët e tij e marrin, e përpunojnë dhe e përcjellin këtë informacion. Alloy është shpërndarja e OpenTelemetry Collector nga Grafana. Për ekipet që tashmë përdorin shpërndarje të tjera të mbështetura, njoftimi do të thotë se menaxhimi qendror nuk ka pse të fillojë me zëvendësimin e softuerit të kolektorëve, rishkrimin e konfigurimit në formatin e Alloy apo ndryshimin e vendit ku ekzekutohen kolektorët.
Problemi themelor operacional shkon përtej çdo produkti të veçantë: ndërsa një sistem monitorimi zgjerohet, ekipeve u duhen rregulla të përbashkëta pa humbur cilësimet specifike për shërbime apo mjedise të veçanta. Ato gjithashtu duhet të dinë nëse vetë kolektorët po funksionojnë. Zbatimi i Grafana bashkon caktimin e konfigurimeve për kolektorë të përzgjedhur dhe gjendjen funksionale të kolektorëve në një rrjedhë të vetme menaxhimi, duke ruajtur OTel YAML, formatin e strukturuar të tekstit që përdoret për të përshkruar cilësimet e kolektorëve.
Konfigurim i përbashkët pa ngarkesa pune identike
Fleet Management u lejon ekipeve të përcaktojnë zinxhirë telemetrie, sekuenca hapash për mbledhjen dhe përpunimin, në OTel YAML dhe t'ua caktojnë kolektorëve që përputhen me kriteret. Kështu, një rregull i përbashkët përpunimi mund të përditësohet në mënyrë qendrore, ndërsa mbledhja shtesë mbetet e kufizuar te ekipet, shërbimet apo mjediset që kanë nevojë për të. Grafana ilustron gjithashtu një test konfigurimi që kalon kontrollin e sintaksës, i cili kontrollon strukturën e konfigurimit dhe nuk demonstron sjelljen e tij nën çdo ngarkesë pune.
Për ekipet që përdorin infrastrukturën si kod, praktikën e menaxhimit të infrastrukturës përmes skedarëve të ruajtur të konfigurimit, Grafana përshkruan mbështetjen për Terraform, një mjet që zbaton këta skedarë. Ekipet mund të krijojnë zinxhirë të bazuar në YAML dhe të regjistrojnë kolektorë aktivë përmes kësaj rrjedhe pune. Si rrjedhojë, konfigurimi dhe regjistrimi mund të bëhen procese të përsëritshme, të gjurmuara përmes kontrollit të versioneve, një sistem që regjistron ndryshimet në skedarë me kalimin e kohës.
Regjistrimi aktivizon gjithashtu vetëmonitorimin e kolektorëve. Sipas Grafana, OTel Collectors të regjistruar dërgojnë automatikisht në Grafana Cloud metrika, pra matje numerike; regjistra, pra ngjarje të regjistruara; dhe gjurmë, pra regjistrime të kërkesave që kalojnë nëpër softuer. Kjo vlen pavarësisht sistemit operativ apo mënyrës së vendosjes në përdorim. Kolektorët jashtë Kubernetes, një sistem për menaxhimin e aplikacioneve të paketuara në kontejnerë, marrin gjithashtu një zinxhir monitorimi të makinës pritëse, për t'i ndihmuar ekipet të shqyrtojnë makinën ku ekzekutohet kolektori krahas vetë kolektorit.
Këta zinxhirë monitorimi nuk përfaqësojnë destinacione të pandryshueshme apo politika të detyrueshme mbledhjeje. Grafana thotë se ekipet mund t'i ndryshojnë, t'i çaktivizojnë ose t'i ridrejtojnë të dhënat e tyre te një tjetër sistem backend, sistemi marrës që ruan ose analizon telemetrinë. Ky dallim ka rëndësi kur shqyrtohet se çfarë dërgon një kolektor i regjistruar dhe ku përfundojnë këto të dhëna.
Pse kombinimi i konfigurimeve kërkon më shumë se një kontroll sintakse
Një kolektor mund të marrë disa zinxhirë nga Fleet Management dhe njëkohësisht të ruajë konfigurimin lokal. Cilësimet që rezultojnë duhet të funksionojnë së bashku. Bachvarovski shpjegon se Alloy i përcakton komponentët, blloqet individuale të përpunimit apo mbledhjes, në blloqe të lidhura përmes referencave ndaj daljeve të tyre. Në të kundërt, OTel Collectors i përcaktojnë komponentët në nivelin më të lartë të konfigurimit dhe u referohen atyre nga një ose më shumë zinxhirë telemetrie.
Ka edhe një ndryshim të dytë të rëndësishëm: Alloy i mban të ndara konfigurimet lokale dhe ato në distancë, ndërsa OTel Collectors i kombinojnë ato në një konfigurim të vetëm që zbatohet në praktikë. Nëse disa burime përcaktojnë një komponent me të njëjtin emër, një përkufizim mund të mbizotërojë mbi një tjetër dhe të ndryshojë sjelljen e zinxhirit. Prandaj, zinxhirët e hartuar në mënyrë të pavarur mund të bien ndesh edhe kur autorët e tyre kanë synuar sjellje të ndryshme për komponentët me emra identikë.
Grafana e trajton këtë me një algoritëm bashkimi, një procedurë për kombinimin e konfigurimeve, që kryen përpunim shtesë të cilësimeve në distancë. Ai ua shton emrin e zinxhirit të Fleet Management identifikuesve të zinxhirëve dhe komponentëve OTel, pastaj përditëson referencat ndaj këtyre identifikuesve. Kur komponentët kanë si të njëjtin lloj, ashtu edhe të njëjtin konfigurim, ai heq dublikatat, duke ruajtur një përkufizim të përbashkët në vend të kopjeve të panevojshme. Grafana paraqet gjithashtu një pamje vetëm për lexim të konfigurimit në distancë që i është caktuar një kolektori.
Ky mekanizëm synon t'u mundësojë ekipeve t'i mbajnë zinxhirët në distancë si pjesë të ripërdorshme, në vend që të ndërtojnë manualisht një skedar të veçantë konfigurimi për çdo kombinim të mundshëm. Mësimi që mund të zbatohet edhe në raste të tjera është se konfigurimi qendror ka nevojë për rregulla të qarta për emrat, referencat dhe bashkimin. Vetëm pranimi i YAML të vlefshëm nuk shpjegon se si do të ndërveprojnë konfigurimet e shkruara veçmas.
Ndani mbledhjen lokale nga përpunimi i përbashkët
Fleet Management mbështet mënyra të ndryshme vendosjeje në përdorim. Një mundësi që Grafana përshkruan për grupe të mëdha apo të përziera kolektorësh është modeli gateway, i cili i ndan kolektorët në dy shtresa. Kolektorët periferikë pranë aplikacioneve mbledhin telemetri nga shërbimet, pod-et e Kubernetes (grupe kontejnerësh aplikacionesh) dhe nyjet (makinat ku ato ekzekutohen). Ata e përcjellin atë te kolektorët gateway, të cilët zbatojnë përpunimin e përbashkët përpara se ta dërgojnë te një sistem backend.
Në gateway, ekipet mund t'u shtojnë metrikave etiketa ekipesh, të filtrojnë regjistrat ose të zbatojnë përzgjedhjen e gjurmëve pas përfundimit të kërkesave, të njohur si tail sampling, duke zgjedhur cilat regjistrime kërkesash të ruajnë pasi të kenë vëzhguar se si kanë ecur ato kërkesa. Mbajtja e këtyre politikave në gateway shmang vendosjen e së njëjtës logjikë përpunimi në çdo kolektor periferik. Fleet Management mund t'ua caktojë zinxhirët e mbledhjes kolektorëve periferikë dhe zinxhirët e përpunimit kolektorëve gateway, duke i menaxhuar të dy në mënyrë qendrore pa përzier përgjegjësitë e tyre.
Të dyja shtresat nuk kanë pse të përdorin softuer identik. Grafana thotë se agjentët ekzistues si Fluent Bit apo Telegraf mund të mbeten në periferi dhe të përcjellin telemetrinë te kolektorët gateway OTel përmes protokolleve të përputhshme. Fleet Management më pas menaxhon kolektorët gateway OTel të mbështetur dhe cilësimet e tyre të përbashkëta të përpunimit. Kjo është një rrugë graduale drejt përdorimit të OpenTelemetry, jo një pretendim se çdo agjent ekzistues bëhet drejtpërdrejt i menaxhueshëm përmes Fleet Management.
Kolektorët gateway janë opsionalë: kolektorët e mbështetur që dërgojnë drejtpërdrejt te një sistem backend mund të përdorin gjithashtu rrjedhën e punës të bazuar në OpAMP. Pika e nisjes që sugjeron Grafana është regjistrimi i një kolektori, caktimi i një zinxhiri YAML dhe kontrolli i gjendjes së tij funksionale përpara se qasja të shtrihet në mjedise të tjera. Njoftimi nuk rendit çdo shpërndarje të mbështetur, ndaj përputhshmëria duhet kontrolluar dhe jo marrë si e mirëqenë.
Për bizneset që po shqyrtojnë se si e mbrojnë infrastrukturën që monitorohet, shërbimet e menaxhuara cloud dhe të infrastrukturës së të dhënave të AEU Data ofrojnë një pikënisje të përshtatshme për të vlerësuar monitorimin dhe mbështetjen operacionale krahas menaxhimit të kolektorëve. Vendimi kryesor mbetet praktik: ruani modelin e mbledhjes që i përshtatet ngarkesës së punës, kuptoni si sillen cilësimet e kombinuara dhe mbani kontrollin mbi të dhënat e monitorimit që dërgojnë këta kolektorë.