Er overvågning død? — Længe leve overvågning

Siden 2008 har vores virksomhed primært beskæftiget sig med infrastrukturstyring og teknisk support døgnet rundt til webprojekter: Vi har mere end 400 kunder, hvilket er omkring 15 % af russisk e-handel. Derfor understøttes en meget forskelligartet arkitektur. Hvis noget falder, er vi forpligtet til at ordne det inden for 15 minutter. Men for at forstå, at der er sket en ulykke, skal du overvåge projektet og reagere på hændelser. Hvordan gør man dette?

Jeg mener, at der er et problem med at organisere et ordentligt overvågningssystem. Hvis der ikke havde været nogen problemer, så ville min tale bestå af en afhandling: "Installer venligst Prometheus + Grafana og plugins 1, 2, 3." Sådan fungerer det desværre ikke længere. Og hovedproblemet er, at alle fortsætter med at tro på noget, der eksisterede i 2008, hvad angår softwarekomponenter.

Med hensyn til organiseringen af ​​overvågningssystemet vil jeg vove at sige, at... projekter med kompetent overvågning ikke eksisterer. Og situationen er så slem, at hvis noget falder, er der risiko for, at det går ubemærket hen - alle er trods alt sikre på, at "alt bliver overvåget."
Måske bliver alt overvåget. Men hvordan?

Vi er alle stødt på en historie som følgende: en bestemt devops, en bestemt admin arbejder, et udviklingsteam kommer til dem og siger - "vi er frigivet, overvåg nu." Overvåg hvad? Hvordan det virker?

OKAY. Vi overvåger den gammeldags måde. Og det er allerede ved at ændre sig, og det viser sig, at du overvågede tjeneste A, som blev til tjeneste B, som interagerer med tjeneste C. Men udviklingsteamet fortæller dig: "Installer softwaren, den skal overvåge alt!"

Så hvad har ændret sig? - Alting har ændret sig!

2008 Alt er fint

Der er et par udviklere, en server, en databaseserver. Det hele går herfra. Vi har nogle oplysninger, vi installerer zabbix, Nagios, kaktusser. Og så sætter vi klare advarsler på CPU'en, om diskdrift og om diskplads. Vi foretager også et par manuelle kontroller for at sikre, at siden reagerer, og at der kommer ordrer ind i databasen. Og det er det - vi er mere eller mindre beskyttet.

Hvis vi sammenligner mængden af ​​arbejde, som administratoren dengang gjorde for at levere overvågning, så var 98 % af det automatisk: den person, der udfører overvågningen, skal forstå, hvordan man installerer Zabbix, hvordan man konfigurerer det og konfigurerer advarsler. Og 2% - for ekstern kontrol: at siden reagerer og sender en anmodning til databasen, at der er kommet nye ordrer.

2010 Belastningen vokser

Vi begynder at skalere nettet ved at tilføje en søgemaskine. Vi vil gerne sikre os, at produktkataloget indeholder alle produkterne. Og den produktsøgning virker. At databasen virker, at der bliver lavet bestillinger, at siden reagerer eksternt og svarer fra to servere og brugeren ikke bliver smidt ud af siden mens den rebalanceres til en anden server osv. Der er flere enheder.

Desuden er den enhed, der er forbundet med infrastruktur, stadig den største i lederens hoved. Der er stadig en idé i mit hoved, at den person, der udfører overvågningen, er den person, der vil installere zabbix og være i stand til at konfigurere den.

Men samtidig opstår der arbejde med at udføre ekstern kontrol, med at oprette et sæt søgeindekseringsforespørgselsscripts, et sæt scripts til at kontrollere, at søgningen ændrer sig under indekseringsprocessen, et sæt scripts, der kontrollerer, at varer overføres til leveringsservice mv. og så videre.

Bemærk: Jeg skrev "et sæt scripts" 3 gange. Det vil sige, at den ansvarlige for overvågning ikke længere er den, der blot installerer zabbix. Dette er en person, der begynder at kode. Men intet har ændret sig i holdets sind endnu.

Men verden ændrer sig, bliver mere og mere kompleks. Et virtualiseringslag og flere nye systemer tilføjes. De begynder at interagere med hinanden. Hvem sagde "lugter af mikrotjenester?" Men hver tjeneste ligner stadig en hjemmeside individuelt. Vi kan henvende os til det og forstå, at det giver den nødvendige information og fungerer på egen hånd. Og hvis du er en administrator konstant involveret i et projekt, der har været under udvikling i 5-7-10 år, ophobes denne viden: et nyt niveau dukker op - du indså det, et andet niveau dukker op - du indså det...

Men sjældent følger nogen med et projekt i 10 år.

Overvågningsmands CV

Antag, at du kom til en ny startup, der straks hyrede 20 udviklere, skrev 15 mikrotjenester, og du er en admin, der får at vide: "Byg CI/CD. Vær venlig." Du har bygget CI/CD og pludselig hører du: "Det er svært for os at arbejde med produktion i en "kube", uden at forstå, hvordan applikationen vil fungere i den. Lav os en sandkasse i den samme "terning".
Du laver en sandkasse i denne terning. De fortæller straks: "Vi vil have en scenedatabase, der opdateres hver dag fra produktionen, så vi forstår, at den fungerer på databasen, men samtidig ikke ødelægger produktionsdatabasen."

Du lever i alt dette. Der er 2 uger tilbage til udgivelsen, de fortæller dig: "Lad os nu overvåge alt dette..." Altså. overvåge klyngeinfrastrukturen, overvåge mikroservicearkitekturen, overvåge arbejde med eksterne tjenester...

Og mine kolleger tager den sædvanlige ordning ud af hovedet og siger: ”Jamen, her er alt klart! Installer et program, der overvåger alt dette." Ja, ja: Prometheus + Grafana + plugins.
Og de tilføjer: "Du har to uger, sørg for at alt er sikkert."

I mange projekter, som vi ser, er der afsat én person til overvågning. Forestil dig, at vi ønsker at ansætte en person til at lave overvågning i 2 uger, og vi skriver et CV til ham. Hvilke færdigheder skal denne person have i betragtning af alt, hvad vi har sagt indtil videre?

• Han skal forstå overvågningen og detaljerne i driften af ​​jerninfrastrukturen.
• Han skal forstå detaljerne ved at overvåge Kubernetes (og alle vil gå til "kuben", fordi du kan abstrahere fra alt, gemme dig, fordi administratoren vil tage sig af resten) - sig selv, dens infrastruktur og forstå, hvordan man overvåger applikationer inde.
• Han skal forstå, at tjenester kommunikerer med hinanden på særlige måder, og kende detaljerne i, hvordan tjenester interagerer med hinanden. Det er sagtens muligt at se et projekt, hvor nogle tjenester kommunikerer synkront, for der er ingen anden måde. For eksempel går backend via REST, via gRPC til katalogtjenesten, modtager en liste over produkter og returnerer den. Du kan ikke vente her. Og med andre tjenester fungerer det asynkront. Overfør ordren til leveringstjenesten, send et brev mv.
  Du har sikkert allerede svømmet fra alt dette? Og administratoren, der skal overvåge dette, blev endnu mere forvirret.
• Han skal kunne planlægge og planlægge rigtigt – i takt med at arbejdet bliver mere og mere.
• Han skal derfor lave en strategi ud fra den oprettede tjeneste for at forstå, hvordan man specifikt overvåger den. Han har brug for en forståelse af projektets arkitektur og dets udvikling + en forståelse af de teknologier, der bruges i udviklingen.

Lad os huske et helt normalt tilfælde: nogle tjenester er i PHP, nogle tjenester er i Go, nogle tjenester er i JS. De arbejder på en eller anden måde med hinanden. Det er her, udtrykket "mikroservice" kommer fra: Der er så mange individuelle systemer, at udviklere ikke kan forstå projektet som helhed. En del af teamet skriver tjenester i JS, der fungerer på egen hånd og ikke ved, hvordan resten af ​​systemet fungerer. Den anden del skriver tjenester i Python og forstyrrer ikke, hvordan andre tjenester fungerer; de er isoleret i deres eget område. Den tredje er skrivetjenester i PHP eller noget andet.
Alle disse 20 personer er opdelt i 15 tjenester, og der er kun én admin, der skal forstå alt dette. Hold op! vi har lige opdelt systemet i 15 mikrotjenester, fordi 20 personer ikke kan forstå hele systemet.

Men det skal overvåges på en eller anden måde...

Hvad er resultatet? Som et resultat er der én person, der kommer med alt det, som hele teamet af udviklere ikke kan forstå, og samtidig skal han også vide og kunne det, vi angav ovenfor – hardwareinfrastruktur, Kubernetes-infrastruktur osv.

Hvad kan jeg sige... Houston, vi har problemer.

Overvågning af et moderne softwareprojekt er et softwareprojekt i sig selv

Fra den falske tro på, at overvågning er software, udvikler vi en tro på mirakler. Men mirakler sker desværre ikke. Du kan ikke installere zabbix og forvente, at alt fungerer. Det nytter ikke noget at installere Grafana og håbe på, at alt vil være ok. Det meste af tiden vil blive brugt på at organisere kontrol af tjenesternes drift og deres interaktion med hinanden, kontrollere, hvordan eksterne systemer fungerer. Faktisk vil 90 % af tiden ikke blive brugt på at skrive scripts, men på at udvikle software. Og det bør varetages af et team, der forstår projektets arbejde.
Hvis en person i denne situation bliver kastet ind i overvågningen, vil der ske en katastrofe. Hvilket er, hvad der sker overalt.

For eksempel er der flere tjenester, der kommunikerer med hinanden via Kafka. Ordren ankom, vi sendte en besked om ordren til Kafka. Der er en service, der lytter til information om ordren og sender varerne. Der er en tjeneste, der lytter til information om ordren og sender et brev til brugeren. Og så dukker der en masse flere tjenester op, og vi begynder at blive forvirrede.

Og hvis du også giver dette til administratoren og udviklerne på det tidspunkt, hvor der er kort tid tilbage før udgivelsen, bliver personen nødt til at forstå hele denne protokol. De der. Et projekt af denne skala tager en betydelig mængde tid, og dette bør tages med i systemudviklingen.
Men meget ofte, især i startups, ser vi, hvordan overvågningen udskydes til senere. "Nu vil vi lave et Proof of Concept, vi vil lancere med det, lad det falde - vi er klar til at ofre. Og så vil vi overvåge det hele.” Når (eller hvis) projektet begynder at tjene penge, vil virksomheden gerne tilføje endnu flere funktioner – fordi det er begyndt at virke, så det skal rulles videre ud! Og du er på det punkt, hvor du først skal overvåge alt det foregående, hvilket ikke tager 1 % af tiden, men meget mere. Og i øvrigt vil der være behov for udviklere til overvågning, og det er nemmere at lade dem arbejde på nye funktioner. Som et resultat bliver der skrevet nye funktioner, alt bliver skruet sammen, og du er i en endeløs dødvande.

Så hvordan overvåger du et projekt fra begyndelsen, og hvad skal du gøre, hvis du får et projekt, der skal overvåges, men du ikke ved, hvor du skal starte?

Først skal du planlægge.

Lyrisk digression: meget ofte starter de med infrastrukturovervågning. For eksempel har vi Kubernetes. Lad os starte med at installere Prometheus med Grafana, installere plugins til overvågning af "kuben". Ikke kun udviklere, men også administratorer har den uheldige praksis: "Vi installerer dette plugin, men plugin'et ved sandsynligvis, hvordan det skal gøres." Folk kan lide at starte med det enkle og ligetil, snarere end med de vigtige handlinger. Og infrastrukturovervågning er let.

Beslut først, hvad og hvordan du vil overvåge, og vælg derefter et værktøj, fordi andre mennesker ikke kan tænke for dig. Og skal de? Andre mennesker tænkte ved sig selv, om et universelt system - eller tænkte slet ikke, da dette plugin blev skrevet. Og bare fordi dette plugin har 5 tusinde brugere, betyder det ikke, at det er til nogen nytte. Måske bliver du den 5001. simpelthen fordi der allerede var 5000 mennesker der før.

Hvis du begynder at overvåge infrastrukturen, og din applikations backend holder op med at reagere, vil alle brugere miste forbindelsen til mobilapplikationen. Der vises en fejl. De vil komme til dig og sige "Ansøgningen virker ikke, hvad laver du her?" - Vi overvåger. — "Hvordan overvåger du, hvis du ikke kan se, at applikationen ikke virker?!"

1. Jeg mener, at du skal begynde at overvåge nøjagtigt fra brugerens indgangspunkt. Hvis brugeren ikke kan se, at applikationen virker, er det det, det er en fejl. Og overvågningssystemet bør advare om dette først.
2. Og først da kan vi overvåge infrastrukturen. Eller gør det parallelt. Det er nemmere med infrastruktur - her kan vi endelig bare installere zabbix.
3. Og nu skal du gå til applikationens rødder for at forstå, hvor tingene ikke fungerer.

Min hovedidé er, at overvågning skal gå sideløbende med udviklingsprocessen. Hvis du distraherer overvågningsteamet til andre opgaver (oprettelse af CI/CD, sandboxing, omorganisering af infrastrukturen), vil overvågningen begynde at halte, og du kan aldrig indhente udviklingen (eller før eller siden bliver du nødt til at stoppe den).

Alt efter niveauer

Sådan ser jeg organiseringen af ​​et overvågningssystem.

1) Anvendelsesniveau:

• overvågning af applikationens forretningslogik;
• overvågning af sundhedsmålinger af tjenester;
• integrationsovervågning.

2) Infrastrukturniveau:

• overvågning af orkestreringsniveau;
• systemsoftware overvågning;
• overvågning af jernniveau.

3) Igen anvendelsesniveauet - men som et ingeniørprodukt:

• indsamling og overvågning af applikationslogfiler;
• APM;
• sporing.

4) Advarsel:

• organisering af et advarselssystem;
• organisering af et vagtsystem;
• organisering af en ”vidensbase” og arbejdsgang for hændelsesbehandling.

Det er vigtigt: vi kommer til alarmen ikke efter, men med det samme! Der er ingen grund til at starte overvågning og "på en eller anden måde senere" finde ud af, hvem der vil modtage advarsler. Når alt kommer til alt, hvad er opgaven med at overvåge: at forstå, hvor i systemet noget fungerer forkert, og at lade de rigtige personer vide om det. Hvis du lader dette stå til slutningen, vil de rigtige mennesker vide, at noget går galt, kun ved at kalde "intet virker for os."

Application Layer - Business Logic Monitoring

Her taler vi om at tjekke, at applikationen fungerer for brugeren.

Dette niveau bør udføres i udviklingsfasen. For eksempel har vi en betinget Prometheus: den går til serveren, der foretager kontrollen, trækker endepunktet, og endepunktet går og tjekker API'et.

Når de ofte bliver bedt om at overvåge hjemmesiden for at sikre, at webstedet fungerer, giver programmører et håndtag, der kan trækkes, hver gang de skal sikre sig, at API'en fungerer. Og programmører i dette øjeblik tager og skriver stadig /api/test/helloworld
Den eneste måde at sikre, at alt fungerer? - Nej!

• At oprette sådanne kontroller er i bund og grund udviklernes opgave. Enhedstest bør skrives af de programmører, der skriver koden. For hvis du lækker det til administratoren, "Dude, her er en liste over API-protokoller for alle 25 funktioner, overvåg venligst alt!" - intet lykkes.
• Hvis du udskriver "hej verden", vil ingen nogensinde vide, at API'en burde og virker. Hver API-ændring skal føre til en ændring i kontroller.
• Hvis du allerede har et sådant problem, skal du stoppe funktionerne og tildele udviklere, der vil skrive disse kontroller, eller acceptere tabene, acceptere, at intet er kontrolleret og vil fejle.

Tekniske tips:

• Sørg for at organisere en ekstern server til at organisere checks – du skal være sikker på, at dit projekt er tilgængeligt for omverdenen.
• Organiser kontroller på tværs af hele API-protokollen, ikke kun individuelle slutpunkter.
• Opret et prometheus-endepunkt med testresultaterne.

Applikationslag - overvågning af sundhedsmetrikker

Nu taler vi om eksterne sundhedsmålinger for tjenester.

Vi besluttede, at vi overvåger alle "håndtag" af applikationen ved hjælp af eksterne kontroller, som vi kalder fra et eksternt overvågningssystem. Men det er de "håndtag", som brugeren "ser". Vi vil være sikre på, at vores tjenester i sig selv fungerer. Der er en bedre historie her: K8s har helbredstjek, så i det mindste "kuben" selv kan blive overbevist om, at tjenesten virker. Men halvdelen af ​​de checks, jeg har set, er det samme tryk "hej verden". De der. Så han trækker en gang efter udsendelse, svarede han, at alt er i orden - det er alt. Og tjenesten, hvis den leverer sin egen API, har et stort antal indgangspunkter for den samme API, som også skal overvåges, fordi vi gerne vil vide, at den virker. Og vi overvåger det allerede indeni.

Sådan implementeres dette korrekt teknisk: hver tjeneste afslører et slutpunkt om dens nuværende ydeevne, og i graferne for Grafana (eller enhver anden applikation) ser vi status for alle tjenester.

• Hver API-ændring skal føre til en ændring i kontroller.
• Opret en ny tjeneste med det samme med sundhedsmålinger.
• En administrator kan komme til udviklerne og spørge "tilføj mig et par funktioner, så jeg forstår alt og tilføje oplysninger om dette til mit overvågningssystem." Men udviklere svarer normalt: "Vi tilføjer ikke noget to uger før udgivelsen."
  Lad udviklingslederne vide, at der vil være sådanne tab, lad også udviklingsledernes ledelse vide det. For når alt falder, vil nogen stadig ringe og forlange at overvåge den "konstant faldende tjeneste" (c)
• Tildel i øvrigt udviklere til at skrive plugins til Grafana - dette vil være en god hjælp for administratorer.

Application Layer - Integrationsovervågning

Integrationsovervågning fokuserer på overvågning af kommunikation mellem forretningskritiske systemer.

For eksempel er der 15 tjenester, der kommunikerer med hinanden. Disse er ikke længere separate websteder. De der. vi kan ikke trække tjenesten alene, få /helloworld og forstå, at tjenesten kører. Fordi den bestillende webservice skal sende information om ordren til bussen - fra bussen, skal lagerservicen modtage denne besked og arbejde videre med den. Og e-mail-distributionstjenesten skal behandle dette på en eller anden måde videre osv.

Derfor kan vi ikke forstå, når vi kigger på hver enkelt tjeneste, at det hele virker. Fordi vi har en bestemt bus, hvorigennem alt kommunikerer og interagerer.
Derfor bør denne fase markere stadiet for test af tjenester til interaktion med andre tjenester. Det er umuligt at organisere kommunikationsovervågning ved at overvåge meddelelsesmægleren. Hvis der er en tjeneste, der udsteder data, og en tjeneste, der modtager dem, vil vi ved overvågning af mægleren kun se data, der flyver fra side til side. Selvom vi på en eller anden måde formåede at overvåge interaktionen af ​​disse data internt - at en bestemt producent poster dataene, nogen læser dem, fortsætter dette flow med at gå til Kafka - vil dette stadig ikke give os information, hvis en tjeneste sendte beskeden i én version , men den anden tjeneste forventede ikke denne version og sprang den over. Vi ved ikke om dette, da tjenesterne vil fortælle os, at alt fungerer.

Hvad jeg anbefaler at gøre:

• Til synkron kommunikation: endepunktet sender anmodninger til relaterede tjenester. De der. vi tager dette endepunkt, trækker et script inde i tjenesten, som går til alle punkterne og siger "Jeg kan trække der, og trække der, jeg kan trække der..."
• For asynkron kommunikation: indgående meddelelser - endepunktet kontrollerer bussen for testmeddelelser og viser behandlingsstatus.
• For asynkron kommunikation: udgående beskeder - endepunktet sender testmeddelelser til bussen.

Som det plejer at ske: Vi har en tjeneste, der smider data ind i bussen. Vi kommer til denne service og beder dig fortælle os om dens integrationssundhed. Og hvis tjenesten skal producere en besked et andet sted længere (WebApp), så vil den producere denne testmeddelelse. Og hvis vi kører en tjeneste på OrderProcessing-siden, poster den først, hvad den kan poste uafhængigt, og hvis der er nogle afhængige ting, så læser den et sæt testmeddelelser fra bussen, forstår, at den kan behandle dem, rapportere det og , hvis det er nødvendigt, post dem videre, og om dette siger han - alt er ok, jeg er i live.

Meget ofte hører vi spørgsmålet "hvordan kan vi teste dette på kampdata?" Vi taler for eksempel om den samme bestillingsservice. Ordren sender beskeder til det lager, hvor varerne afskrives: vi kan ikke teste dette på kampdata, fordi "mine varer bliver afskrevet!" Løsning: Planlæg hele denne test fra starten. Du har også enhedstest, der gør hån. Så gør det på et dybere niveau, hvor du har en kommunikationskanal, der ikke skader driften af ​​virksomheden.

Infrastruktur niveau

Infrastrukturovervågning er noget, der længe har været anset for at overvåge sig selv.

• Infrastrukturovervågning kan og bør lanceres som en separat proces.
• Du bør ikke starte med infrastrukturovervågning på et igangværende projekt, selvom du virkelig ønsker det. Dette er en smerte for alle devops. "Først vil jeg overvåge klyngen, jeg vil overvåge infrastrukturen" - dvs. Først vil den overvåge, hvad der ligger nedenfor, men vil ikke gå ind i ansøgningen. Fordi applikationen er en uforståelig ting for devops. Det blev lækket til ham, og han forstår ikke, hvordan det fungerer. Men han forstår infrastrukturen og starter med den. Men nej - du skal altid overvåge applikationen først.
• Gå ikke overbord med antallet af advarsler. I betragtning af kompleksiteten af ​​moderne systemer flyver advarsler konstant, og du må på en eller anden måde leve med denne flok advarsler. Og vagtpersonen, efter at have set på hundrede af de næste alarmer, vil beslutte "Jeg vil ikke tænke på det." Advarsler bør kun give besked om kritiske ting.

Anvendelsesniveau som forretningsenhed

Centrale punkter:

• ELK. Dette er industristandarden. Hvis du af en eller anden grund ikke samler logfiler, skal du begynde at gøre det med det samme.
• APM. Eksterne APM'er som en måde til hurtigt at lukke applikationsovervågning (NewRelic, BlackFire, Datadog). Du kan installere denne ting midlertidigt for i det mindste på en eller anden måde at forstå, hvad der sker med dig.
• Sporing. I snesevis af mikrotjenester skal du spore alt, fordi anmodningen ikke længere lever af sig selv. Det er meget svært at tilføje senere, så det er bedre straks at planlægge sporing i udviklingen - dette er udviklernes arbejde og nytte. Hvis du ikke har implementeret det endnu, så implementer det! Se Jaeger/Zipkin

Alarmer

• Organisering af et meddelelsessystem: i forhold til overvågning af en masse ting, bør der være et samlet system til at sende meddelelser. Det kan du i Grafana. I Vesten bruger alle PagerDuty. Advarsler skal være tydelige (f.eks. hvor de kom fra...). Og det er tilrådeligt at kontrollere, at der overhovedet modtages notifikationer
• Organisering af et vagtsystem: advarsler bør ikke sendes til alle (enten vil alle reagere i en menneskemængde, eller også vil ingen reagere). Udviklere skal også være tilkalde: sørg for at definere ansvarsområder, lave klare instruktioner og skrive i den, hvem de præcist skal ringe til mandag og onsdag, og hvem de skal ringe til tirsdag og fredag ​​(ellers ringer de ikke til nogen selv i tilfælde af et stort problem - de vil være bange for at vække dig eller forstyrre: folk bryder sig generelt ikke om at ringe og vække andre mennesker, især om natten). Og forklar, at det at bede om hjælp ikke er en indikator for inkompetence ("Jeg beder om hjælp, det betyder, at jeg er en dårlig arbejder"), opmuntre anmodninger om hjælp.
• Organisering af en "videnbase" og arbejdsgang for hændelsesbehandling: For hver alvorlig hændelse bør der planlægges en obduktion, og som en midlertidig foranstaltning skal handlinger, der løser hændelsen, registreres. Og gør det til en praksis, at gentagne alarmer er en synd; de skal rettes i kode- eller infrastrukturarbejde.

Teknologi stak

Lad os forestille os, at vores stak er som følger:

• dataindsamling - Prometheus + Grafana;
• log analyse - ELK;
• til APM eller Tracing - Jaeger (Zipkin).

Valget af muligheder er ikke kritisk. For hvis du i begyndelsen forstod, hvordan du skulle overvåge systemet og skrev en plan ned, så begynder du at vælge værktøjer, der passer til dine krav. Spørgsmålet er, hvad du valgte at overvåge i første omgang. For måske passer det værktøj, du valgte i begyndelsen, slet ikke til dine krav.

Et par tekniske punkter, som jeg ser overalt på det seneste:

Prometheus bliver skubbet indenfor i Kubernetes – hvem fandt på det her?! Hvis din klynge går ned, hvad vil du så gøre? Hvis du har en kompleks klynge indeni, så burde der være en form for overvågningssystem inde i klyngen, og noget udenfor, som vil indsamle data inde fra klyngen.

Inde i klyngen samler vi logs og alt muligt andet. Men overvågningssystemet skal være udenfor. Meget ofte, i en klynge, hvor der er Promtheus installeret internt, er der også systemer, der udfører ekstern kontrol af webstedets drift. Hvad hvis dine forbindelser til omverdenen er faldet, og applikationen ikke virker? Det viser sig, at alt er fint indeni, men det gør ikke tingene nemmere for brugerne.

Fund

• Overvågning af udvikling er ikke installation af hjælpeprogrammer, men udvikling af et softwareprodukt. 98 % af dagens overvågning er kodning. Kodning i tjenester, kodning af eksterne kontroller, kontrol af eksterne tjenester, og det er alt.
• Spild ikke dine udvikleres tid på overvågning: det kan tage op til 30 % af deres arbejde, men det er det værd.
• Devops, bare rolig, at du ikke kan overvåge noget, for nogle ting er en helt anden måde at tænke på. Du var ikke programmør, og overvågningsarbejde er præcis deres job.
• Hvis projektet allerede kører og ikke overvåges (og du er leder), så allokér ressourcer til overvågning.
• Hvis produktet allerede er i produktion, og du er en devops, der fik besked på at "opsætte overvågning" - så prøv at forklare ledelsen, hvad jeg skrev alt dette om.

Dette er en udvidet version af rapporten på Saint Highload++ konferencen.

Hvis du er interesseret i mine ideer og tanker om det og relaterede emner, så kan du her læs kanalen 🙂

Kilde: www.habr.com