Overvågning af Pivotal Platforms Helbred

At drive en Pivotal Platform (nu en del af VMware Tanzu) kan sammenlignes med at passe på en kompleks organisme. For at sikre, at den fungerer optimalt og er sund, er det afgørende at overvåge dens vitale tegn. Ligesom en læge bruger målinger som puls og blodtryk til at vurdere en patients helbred, skal platformoperatører overvåge specifikke metrikker for at forstå systemets tilstand, kapacitet og ydeevne. Uden denne overvågning risikerer man nedsat ydeevne, flaskehalse og i værste fald nedbrud, der påvirker både udviklere og slutbrugere. I denne artikel vil vi fungere som dine speciallæger og guide dig gennem de vigtigste metrikker, du skal holde øje med for at stille en præcis diagnose og opretholde et sundt og robust system.

Pivotal Platforms Anatomi: En Kort Gennemgang

Før vi dykker ned i de specifikke målinger, er det vigtigt at forstå de centrale 'organer', der udgør Pivotal Platform-systemet. Hver komponent spiller en unik og afgørende rolle for platformens samlede funktion.

• BOSH: Kan betragtes som platformens skelet og nervesystem. Det er et værktøj, der provisionerer og administrerer den underliggende infrastruktur, herunder de virtuelle maskiner (VM'er), som hele systemet kører på.
• User Account and Authentication (UAA): Systemets sikkerhedsvagt. UAA håndterer identitetsstyring, opbevarer brugeroplysninger og udsteder godkendelsestokens.
• Gorouter: Platformens trafikdirigent. Den er indgangspunktet for al trafik, uanset om det er udviklere, der interagerer med API'et, eller slutbrugere, der tilgår applikationer. Den vedligeholder et kort over, hvor alle applikationsinstanser kører.
• Diego: Hjertet i container-orkestreringen. Diego er ansvarlig for at oprette, køre og administrere de containere, hvor applikationerne lever. Det sikrer, at det korrekte antal instanser altid kører og genstarter dem, hvis de fejler.
• Loggregator: Platformens centrale nervesystem for data. Det indsamler og streamer logs og metrikker fra alle komponenter og applikationer, hvilket giver et samlet overblik over, hvad der sker i hele systemet.

BOSH: Fundamentets Helbred

BOSH-metrikker giver indsigt i den systemdækkende tilstand af de virtuelle maskiner, der udgør din platforms infrastruktur. De er de første indikatorer på ressourceproblemer. Utilstrækkelig hukommelse eller diskplads på en VM, der kører Diego-celler, kan for eksempel forhindre nye containere i at starte.

Vigtige BOSH-metrikker

Et konstant højt CPU- eller hukommelsesforbrug (Pivotal anbefaler advarsler ved 80-85% og kritiske alarmer ved 90-95%) er et klart tegn på, at en VM er under pres. Dette kan føre til langsommere respons og flaskehalse, især for kritiske komponenter som Gorouter og UAA. Løsningen er ofte at skalere ressourcerne op, enten ved at øge VM'ens kapacitet eller ved at tilføje flere instanser.

Gorouter: Overvågning af Trafikflowet

Da Gorouter er indgangsporten til hele din platform, er dens helbred altafgørende. Metrikker herfra hjælper dig med at spore den samlede mængde indgående trafik, svartider og eventuelle fejl, som brugerne oplever. Problemer med Gorouter kan hurtigt lamme hele platformen.

Centrale Gorouter-metrikker

En stigning i latency (svartid) kan skyldes mange ting: netværksproblemer, en usund applikation eller simpelthen en overbelastet Gorouter. Ved at korrelere latency med CPU-udnyttelse og det samlede antal anmodninger kan du indsnævre årsagen. En pludselig stigning i 5xx-fejl indikerer ofte, at backend-applikationer crasher eller er overbelastede. Et højt antal bad_gateways kan specifikt pege på, at Gorouters rutetabeller ikke opdateres korrekt, hvilket forhindrer den i at finde de korrekte applikationsinstanser.

Diego: Container-orkestreringshjertet

Diego er kernen, der sikrer, at applikationer kører som de skal. Dets metrikker fokuserer på platformens evne til at tildele opgaver, tilgængeligheden af ressourcer til at køre disse opgaver, og om det korrekt overvåger og balancerer antallet af kørende instanser. Problemer i Diego kan føre til, at applikationer ikke kan startes, skaleres eller genstartes efter et nedbrud.

Auctioneer: Fordeling af Arbejde

Auctioneer-komponenten fordeler arbejdsbyrden (kaldet Tasks og LRPs) ud på de tilgængelige Diego-celler. Fejl her indikerer ofte ressourcemangel.

• AuctioneerLRPAuctionsFailed: Tæller antallet af gange, det ikke lykkedes at placere en applikationsinstans (LRP) på en celle. En stigning i denne værdi er et alvorligt tegn på, at dine Diego-celler er ved at løbe tør for kapacitet (hukommelse, disk eller container-slots). Det er et kritisk signal om, at du skal skalere op.

BBS: Systemets Hukommelse

BBS (Bulletin Board System) holder styr på den ønskede tilstand (hvor mange app-instanser der burde køre) versus den faktiske tilstand. Afvigelser her kan betyde, at applikationer ikke kører som forventet.

• LRPsMissing: Antallet af applikationsinstanser, der er ønskede, men som ikke kører. En vedvarende høj værdi indikerer et problem med BBS eller manglende ressourcer i cellerne.
• crashedActualLRPs: Det samlede antal LRP-instanser, der er crashet. Selvom enkelte crashes kan ske, er en vedvarende stigning et tegn på enten en ustabil applikation eller et platformsproblem, der kræver nærmere undersøgelse.

Diego Cell Rep: Cellernes Sundhedsrapport

Hver Diego-celle rapporterer om sin egen tilstand og kapacitet. Disse metrikker er afgørende for kapacitetsplanlægning.

Hvis den samlede resterende hukommelse eller diskplads på tværs af alle celler falder under en kritisk grænse (Pivotal anbefaler en kritisk alarm ved 32 GB hukommelse eller 6 GB disk), kan det forhindre nye apps i at blive implementeret eller eksisterende i at blive skaleret. Overvågning af disse kapacitetsmetrikker er essentielt for at undgå, at platformen 'kvæles' af ressourcemangel.

Loggregator: Diagnosticering af Datatab

Loggregator er ansvarlig for at transportere alle logs og metrikker. Hvis dette system bliver overbelastet, kan vigtige diagnostiske data gå tabt. Det er som at have en patient, hvis nervesignaler ikke når frem til hjernen. Hovedårsagen til datatab er, når en komponent i kæden ikke kan følge med den mængde data, den modtager. Dette fører til, at meddelelser bliver droppet.

• doppler.dropped: Det samlede antal meddelelser, som Doppler-serveren har droppet. En stigning i denne værdi indikerer, at Doppler- eller Traffic Controller-komponenterne er overbelastede og skal skaleres.
• healthwatch.Firehose.LossRate.1M: En afledt metrik fra Pivotal Healthwatch, der beregner procentdelen af tabte meddelelser over det seneste minut. Pivotal anbefaler en kritisk alarm, hvis denne rate overstiger 1%. Dette er en klar indikator på, at dit overvågningssystem mister data.

Ofte Stillede Spørgsmål (FAQ)

Hvad er de vigtigste tegn på, at min Pivotal Platform er 'usund'?

De mest kritiske tegn er en stigning i Gorouter latency og 5xx-fejl, et højt antal AuctioneerLRPAuctionsFailed, en vedvarende værdi for LRPsMissing, og et fald i den samlede CapacityRemainingMemory eller CapacityRemainingDisk på tværs af dine Diego-celler. Disse indikerer henholdsvis trafikproblemer, ressourcemangel og applikationsinstabilitet.

Hvorfor er det vigtigt at overvåge BOSH-metrikker?

BOSH-metrikker er fundamentet for alt andet. De fortæller dig om helbredet på de virtuelle maskiner, som hele platformen kører på. Højt CPU- eller hukommelsesforbrug på en kritisk VM kan skabe en dominoeffekt og forårsage problemer i de komponenter, der kører på den, f.eks. Gorouter eller Diego-databasen.

Hvad sker der, hvis Diego-celler løber tør for ressourcer?

Hvis cellerne løber tør for hukommelse, diskplads eller container-slots, vil Diego's Auctioneer ikke kunne placere nye applikationsinstanser. Dette betyder, at udviklere ikke kan implementere nye apps, skalere eksisterende apps op, eller at systemet ikke kan genstarte nedbrudte instanser. Platformen mister sin elasticitet og selvhelbredende evne.

Hvordan kan jeg opdage tab af data i Loggregator?

Den bedste måde er at overvåge doppler.dropped-metrikken eller, endnu bedre, den afledte healthwatch.Firehose.LossRate.1M-metrik. En tabsrate på over 1% er kritisk og indikerer, at du mister værdifulde log- og metrikdata, som er nødvendige for at diagnosticere andre problemer i platformen. Løsningen er typisk at skalere antallet af Doppler- eller Traffic Controller-instanser.