Er overvåking død? — Lenge leve overvåking

Siden 2008 har selskapet vårt primært vært engasjert i infrastrukturstyring og teknisk støtte døgnet rundt for nettprosjekter: vi har mer enn 400 kunder, som er omtrent 15 % av russisk e-handel. Følgelig støttes en svært mangfoldig arkitektur. Hvis noe faller, er vi forpliktet til å fikse det innen 15 minutter. Men for å forstå at en ulykke har skjedd, må du overvåke prosjektet og reagere på hendelser. Hvordan gjøre dette?

Jeg mener det er et problem å organisere et skikkelig overvåkingssystem. Hvis det ikke hadde vært noen problemer, ville talen min bestå av en avhandling: "Vennligst installer Prometheus + Grafana og plugins 1, 2, 3." Dessverre fungerer det ikke slik lenger. Og hovedproblemet er at alle fortsetter å tro på noe som eksisterte i 2008, når det gjelder programvarekomponenter.

Når det gjelder organiseringen av overvåkingssystemet vil jeg våge å si at... prosjekter med kompetent overvåking ikke eksisterer. Og situasjonen er så ille at hvis noe faller, er det en risiko for at det går ubemerket hen - alle er tross alt sikre på at "alt er overvåket."
Kanskje blir alt overvåket. Men hvordan?

Vi har alle møtt en historie som følgende: en viss devops, en viss admin jobber, et utviklingsteam kommer til dem og sier - "vi er løslatt, overvåk nå." Overvåke hva? Hvordan det fungerer?

OK. Vi overvåker den gamle måten. Og det er allerede i endring, og det viser seg at du overvåket tjeneste A, som ble tjeneste B, som samhandler med tjeneste C. Men utviklingsteamet forteller deg: "Installer programvaren, den skal overvåke alt!"

Så hva har endret seg? - Alt har forandret seg!

2008 Alt er bra

Det er et par utviklere, en server, en databaseserver. Det hele går herfra. Vi har litt informasjon, vi installerer zabbix, Nagios, kaktuser. Og så setter vi klare varsler på CPU, på diskdrift og på diskplass. Vi foretar også et par manuelle kontroller for å sikre at siden svarer og at bestillinger kommer inn i databasen. Og det er det – vi er mer eller mindre beskyttet.

Hvis vi sammenligner mengden arbeid som administratoren gjorde da for å gi overvåking, så var 98 % av det automatisk: personen som utfører overvåkingen må forstå hvordan man installerer Zabbix, hvordan man konfigurerer det og konfigurerer varsler. Og 2% - for eksterne kontroller: at nettstedet svarer og sender en forespørsel til databasen, at nye bestillinger har kommet.

2010 Belastningen vokser

Vi begynner å skalere nettet ved å legge til en søkemotor. Vi ønsker å forsikre oss om at produktkatalogen inneholder alle produktene. Og det produktsøket fungerer. At databasen fungerer, at det blir gjort bestillinger, at siden svarer eksternt og svarer fra to servere og at brukeren ikke blir kastet ut av siden mens den rebalanseres til en annen server osv. Det er flere enheter.

Dessuten er enheten knyttet til infrastruktur fortsatt den største i lederens hode. Det er fortsatt en idé i hodet mitt om at personen som overvåker er personen som skal installere zabbix og være i stand til å konfigurere den.

Men samtidig dukker det opp arbeid med å utføre eksterne kontroller, med å lage et sett med søkeskript for søkeindeksering, et sett med skript for å sjekke at søket endres under indekseringsprosessen, et sett med skript som sjekker at varer overføres til leveringstjeneste osv. og så videre.

Merk: Jeg skrev "et sett med skript" 3 ganger. Det vil si at den som er ansvarlig for overvåking ikke lenger er den som bare installerer zabbix. Dette er en person som begynner å kode. Men ingenting har endret seg i lagets tanker ennå.

Men verden er i endring, blir mer og mer kompleks. Et virtualiseringslag og flere nye systemer er lagt til. De begynner å samhandle med hverandre. Hvem sa "lukter som mikrotjenester?" Men hver tjeneste ser fortsatt ut som et nettsted individuelt. Vi kan henvende oss til det og forstå at det gir nødvendig informasjon og fungerer på egen hånd. Og hvis du er en administrator som konstant er involvert i et prosjekt som har vært under utvikling i 5-7-10 år, samler denne kunnskapen seg: et nytt nivå dukker opp - du innså det, et annet nivå dukker opp - du innså det ...

Men sjelden følger noen med et prosjekt i 10 år.

Monitoringmans CV

Anta at du kom til en ny oppstart som umiddelbart ansatte 20 utviklere, skrev 15 mikrotjenester, og du er en admin som får beskjed om: «Bygg CI/CD. Vær så snill." Du har bygget CI/CD og plutselig hører du: «Det er vanskelig for oss å jobbe med produksjon i en «kube», uten å forstå hvordan applikasjonen vil fungere i den. Lag oss en sandkasse i samme "kube".
Du lager en sandkasse i denne kuben. De forteller deg umiddelbart: "Vi vil ha en scenedatabase som oppdateres hver dag fra produksjonen, slik at vi forstår at den fungerer på databasen, men samtidig ikke ødelegger produksjonsdatabasen."

Du lever i alt dette. Det er 2 uker igjen før utgivelsen, de forteller deg: "Nå la oss overvåke alt dette..." Det vil si. overvåke klyngeinfrastrukturen, overvåke mikrotjenestearkitekturen, overvåke arbeid med eksterne tjenester...

Og kollegene mine tar det vanlige opplegget ut av hodet og sier: «Vel, her er alt klart! Installer et program som vil overvåke alt dette." Ja, ja: Prometheus + Grafana + plugins.
Og de legger til: "Du har to uker, sørg for at alt er sikkert."

I mange prosjekter vi ser er det tildelt én person til overvåking. Tenk deg at vi ønsker å ansette en person til å gjøre overvåking i 2 uker, og vi skriver en CV for ham. Hvilke ferdigheter bør denne personen ha, gitt alt vi har sagt så langt?

• Han må forstå overvåkingen og spesifikasjonene ved driften av jerninfrastrukturen.
• Han må forstå detaljene ved å overvåke Kubernetes (og alle vil gå til "kuben", fordi du kan abstrahere fra alt, gjemme deg, fordi administratoren vil håndtere resten) - seg selv, dens infrastruktur, og forstå hvordan man overvåker applikasjoner innsiden.
• Han må forstå at tjenester kommuniserer med hverandre på spesielle måter, og kjenne til detaljene i hvordan tjenester samhandler med hverandre. Det er fullt mulig å se et prosjekt der noen av tjenestene kommuniserer synkront, fordi det ikke er noen annen måte. For eksempel går backend via REST, via gRPC til katalogtjenesten, mottar en liste over produkter og returnerer den tilbake. Du kan ikke vente her. Og med andre tjenester fungerer det asynkront. Overfør bestillingen til leveringstjenesten, send brev osv.
  Du har sikkert allerede svømt fra alt dette? Og administratoren, som trenger å overvåke dette, ble enda mer forvirret.
• Han må kunne planlegge og planlegge riktig – ettersom arbeidet blir mer og mer.
• Han må derfor lage en strategi fra den opprettede tjenesten for å forstå hvordan man spesifikt overvåker den. Han trenger en forståelse av prosjektets arkitektur og dets utvikling + en forståelse av teknologiene som brukes i utviklingen.

La oss huske et helt normalt tilfelle: noen tjenester er i PHP, noen tjenester er i Go, noen tjenester er i JS. De jobber på en eller annen måte med hverandre. Det er her begrepet "mikrotjeneste" kommer fra: det er så mange individuelle systemer at utviklere ikke kan forstå prosjektet som helhet. En del av teamet skriver tjenester i JS som fungerer på egenhånd og som ikke vet hvordan resten av systemet fungerer. Den andre delen skriver tjenester i Python og forstyrrer ikke hvordan andre tjenester fungerer; de er isolert i sitt eget område. Den tredje er skrivetjenester i PHP eller noe annet.
Alle disse 20 personene er delt inn i 15 tjenester, og det er bare én admin som må forstå alt dette. Stoppe! vi har nettopp delt systemet i 15 mikrotjenester fordi 20 personer ikke kan forstå hele systemet.

Men det må overvåkes på en eller annen måte...

Hva er resultatet? Som et resultat er det en person som kommer med alt som hele teamet av utviklere ikke kan forstå, og samtidig må han også vite og kunne gjøre det vi indikerte ovenfor - maskinvareinfrastruktur, Kubernetes-infrastruktur, etc.

Hva kan jeg si... Houston, vi har problemer.

Overvåking av et moderne programvareprosjekt er et programvareprosjekt i seg selv

Fra den falske troen på at overvåking er programvare, utvikler vi en tro på mirakler. Men mirakler, dessverre, skjer ikke. Du kan ikke installere zabbix og forvente at alt fungerer. Det er ingen vits i å installere Grafana og håpe at alt ordner seg. Mesteparten av tiden vil gå til å organisere kontroller av driften av tjenester og deres interaksjon med hverandre, sjekke hvordan eksterne systemer fungerer. Faktisk vil 90 % av tiden ikke brukes på å skrive manus, men på å utvikle programvare. Og det bør håndteres av et team som forstår arbeidet med prosjektet.
Hvis i denne situasjonen én person blir kastet inn i overvåking, vil katastrofe skje. Det er det som skjer overalt.

For eksempel er det flere tjenester som kommuniserer med hverandre via Kafka. Bestillingen kom, vi sendte melding om bestillingen til Kafka. Det er en tjeneste som lytter til informasjon om bestillingen og sender varene. Det er en tjeneste som lytter til informasjon om bestillingen og sender et brev til brukeren. Og så dukker det opp flere tjenester, og vi begynner å bli forvirret.

Og hvis du også gir dette til administratoren og utviklerne på det stadiet når det er kort tid igjen før utgivelsen, må personen forstå hele denne protokollen. De. Et prosjekt av denne skalaen tar betydelig tid, og dette bør tas med i systemutviklingen.
Men veldig ofte, spesielt i startups, ser vi hvordan overvåking utsettes til senere. "Nå skal vi lage et Proof of Concept, vi vil lansere med det, la det falle - vi er klare til å ofre. Og så vil vi overvåke det hele." Når (eller hvis) prosjektet begynner å tjene penger, ønsker virksomheten å legge til enda flere funksjoner – fordi det har begynt å fungere, så det må rulles ut videre! Og du er på det punktet hvor du først må overvåke alt tidligere, noe som ikke tar 1% av tiden, men mye mer. Og forresten, utviklere vil være nødvendig for overvåking, og det er lettere å la dem jobbe med nye funksjoner. Som et resultat blir nye funksjoner skrevet, alt blir ødelagt, og du er i en endeløs vranglås.

Så hvordan overvåke et prosjekt fra begynnelsen, og hva skal du gjøre hvis du får et prosjekt som må overvåkes, men du ikke vet hvor du skal begynne?

Først må du planlegge.

Lyrisk digresjon: veldig ofte starter de med infrastrukturovervåking. For eksempel har vi Kubernetes. La oss starte med å installere Prometheus med Grafana, installere plugins for å overvåke "kuben". Ikke bare utviklere, men også administratorer har den uheldige praksisen: "Vi installerer denne plugin-en, men plugin-en vet sannsynligvis hvordan det skal gjøres." Folk liker å starte med det enkle og greie, snarere enn med de viktige handlingene. Og infrastrukturovervåking er enkelt.

Bestem først hva og hvordan du vil overvåke, og velg deretter et verktøy, fordi andre ikke kan tenke for deg. Og burde de? Andre mennesker tenkte for seg selv, om et universelt system - eller tenkte ikke i det hele tatt da denne plugin ble skrevet. Og bare fordi denne plugin har 5 tusen brukere betyr ikke det at den er til noen nytte. Kanskje du blir den 5001. rett og slett fordi det allerede var 5000 mennesker der før.

Hvis du begynner å overvåke infrastrukturen og bakenden av applikasjonen din slutter å svare, vil alle brukere miste forbindelsen til mobilapplikasjonen. En feil vises. De vil komme til deg og si "Applikasjonen fungerer ikke, hva gjør du her?" – Vi overvåker. — "Hvordan overvåker du hvis du ikke ser at applikasjonen ikke fungerer?!"

1. Jeg tror at du må begynne å overvåke nøyaktig fra brukerens inngangspunkt. Hvis brukeren ikke ser at applikasjonen fungerer, er det det, det er en feil. Og overvåkingssystemet bør varsle om dette først.
2. Og først da kan vi overvåke infrastrukturen. Eller gjør det parallelt. Det er enklere med infrastruktur - her kan vi endelig bare installere zabbix.
3. Og nå må du gå til røttene til applikasjonen for å forstå hvor ting ikke fungerer.

Hovedtanken min er at overvåking skal gå parallelt med utviklingsprosessen. Hvis du distraherer overvåkingsteamet for andre oppgaver (opprette CI/CD, sandboxing, omorganisering av infrastruktur), vil overvåkingen begynne å halte, og du vil kanskje aldri ta igjen utviklingen (eller før eller siden må du stoppe den).

Alt etter nivåer

Slik ser jeg organiseringen av et overvåkingssystem.

1) Søknadsnivå:

• overvåking av applikasjoner forretningslogikk;
• overvåking av helsemålinger for tjenester;
• integrasjonsovervåking.

2) Infrastrukturnivå:

• overvåking av orkestreringsnivå;
• system programvare overvåking;
• overvåking av jernnivå.

3) Igjen applikasjonsnivået - men som et ingeniørprodukt:

• samle og overvåke applikasjonslogger;
• APM;
• sporing.

4) Varsler:

• organisering av et varslingssystem;
• organisering av et pliktsystem;
• organisering av en «kunnskapsbase» og arbeidsflyt for hendelsesbehandling.

Det er viktig: vi kommer til varslingen ikke etter, men med en gang! Det er ikke nødvendig å starte overvåking og "på en eller annen måte senere" finne ut hvem som vil motta varsler. Tross alt, hva er oppgaven med å overvåke: å forstå hvor i systemet noe fungerer feil, og å la de rette personene få vite om det. Hvis du lar dette være til slutten, vil de rette personene vite at noe går galt bare ved å kalle "ingenting fungerer for oss."

Application Layer - Business Logic Monitoring

Her snakker vi om å sjekke at applikasjonen fungerer for brukeren.

Dette nivået bør gjøres i utviklingsfasen. For eksempel har vi en betinget Prometheus: den går til serveren som gjør sjekkene, trekker endepunktet, og endepunktet går og sjekker API.

Når de ofte blir bedt om å overvåke hjemmesiden for å sikre at siden fungerer, gir programmerere et håndtak som kan trekkes hver gang de trenger for å sikre at API-en fungerer. Og programmerere for øyeblikket tar og skriver fortsatt /api/test/helloworld
Den eneste måten å sikre at alt fungerer? - Nei!

• Å lage slike sjekker er i hovedsak utviklernes oppgave. Enhetstester bør skrives av programmererne som skriver koden. Fordi hvis du lekker det til administratoren, "Dude, her er en liste over API-protokoller for alle 25 funksjoner, vennligst overvåk alt!" - ingenting vil ordne seg.
• Hvis du skriver ut "hello world", vil ingen noen gang få vite at API-en skal og fungerer. Hver API-endring må føre til en endring i sjekker.
• Hvis du allerede har et slikt problem, stopp funksjonene og tildel utviklere som vil skrive disse sjekkene, eller akseptere tapene, godta at ingenting er sjekket og vil mislykkes.

Tekniske tips:

• Sørg for å organisere en ekstern server for å organisere sjekker - du må være sikker på at prosjektet ditt er tilgjengelig for omverdenen.
• Organiser sjekker på tvers av hele API-protokollen, ikke bare individuelle endepunkter.
• Lag et prometheus-endepunkt med testresultatene.

Applikasjonslag - overvåking av helsemålinger

Nå snakker vi om eksterne helsemålinger av tjenester.

Vi bestemte oss for at vi overvåker alle "håndtakene" til applikasjonen ved hjelp av eksterne kontroller, som vi kaller fra et eksternt overvåkingssystem. Men dette er "håndtakene" som brukeren "ser". Vi vil være sikre på at selve tjenestene våre fungerer. Her er historien bedre: K8s har helsesjekker, slik at i det minste «kuben» selv kan overbevises om at tjenesten fungerer. Men halvparten av sjekkene jeg har sett er det samme trykket "hallo verden". De. Så han trekker en gang etter utplasseringen, svarte han at alt er bra - det er alt. Og tjenesten, hvis den har sitt eget API, har et stort antall inngangspunkter for det samme API, som også må overvåkes, fordi vi vil vite at det fungerer. Og vi overvåker det allerede inne.

Hvordan implementere dette riktig teknisk: hver tjeneste avslører et endepunkt om dens nåværende ytelse, og i grafene til Grafana (eller en hvilken som helst annen applikasjon) ser vi statusen til alle tjenestene.

• Hver API-endring må føre til en endring i sjekker.
• Opprett en ny tjeneste med en gang med helsemålinger.
• En administrator kan komme til utviklerne og spørre "legg meg til et par funksjoner slik at jeg forstår alt og legg til informasjon om dette til overvåkingssystemet mitt." Men utviklere svarer vanligvis: "Vi vil ikke legge til noe to uker før utgivelsen."
  Gi beskjed til utviklingslederne om at det vil bli slike tap, gi beskjed til ledelsen til utviklingslederne også. For når alt faller, vil noen fortsatt ringe og kreve å overvåke den "stadig fallende tjenesten" (c)
• Forresten, alloker utviklere til å skrive plugins for Grafana - dette vil være en god hjelp for administratorer.

Applikasjonslag - Integrasjonsovervåking

Integrasjonsovervåking fokuserer på å overvåke kommunikasjon mellom forretningskritiske systemer.

For eksempel er det 15 tjenester som kommuniserer med hverandre. Dette er ikke lenger separate nettsteder. De. vi kan ikke trekke tjenesten på egen hånd, få /helloworld og forstå at tjenesten kjører. Fordi bestillingsnetttjenesten skal sende informasjon om bestillingen til bussen - fra bussen, må lagertjenesten motta denne meldingen og jobbe videre med den. Og e-postdistribusjonstjenesten må behandle dette på en eller annen måte videre osv.

Følgelig kan vi ikke forstå, når vi ser på hver enkelt tjeneste, at alt fungerer. Fordi vi har en viss buss som alt kommuniserer og samhandler gjennom.
Derfor bør dette stadiet markere stadiet for testing av tjenester for interaksjon med andre tjenester. Det er umulig å organisere kommunikasjonsovervåking ved å overvåke meldingsmegleren. Hvis det er en tjeneste som utsteder data og en tjeneste som mottar den, vil vi ved overvåking av megler kun se data som flyr fra side til side. Selv om vi på en eller annen måte klarte å overvåke interaksjonen mellom disse dataene internt - at en bestemt produsent legger ut dataene, noen leser dem, denne strømmen fortsetter å gå til Kafka - vil dette fortsatt ikke gi oss informasjon hvis en tjeneste sendte meldingen i én versjon , men den andre tjenesten forventet ikke denne versjonen og hoppet over den. Vi vil ikke vite om dette, siden tjenestene vil fortelle oss at alt fungerer.

Hva jeg anbefaler å gjøre:

• For synkron kommunikasjon: endepunktet sender forespørsler til relaterte tjenester. De. vi tar dette endepunktet, trekker et skript inne i tjenesten, som går til alle punktene og sier "Jeg kan trekke dit, og trekke dit, jeg kan trekke dit ..."
• For asynkron kommunikasjon: innkommende meldinger - endepunktet sjekker bussen for testmeldinger og viser behandlingsstatus.
• For asynkron kommunikasjon: utgående meldinger - endepunktet sender testmeldinger til bussen.

Som vanlig: vi har en tjeneste som kaster data inn i bussen. Vi kommer til denne tjenesten og ber deg fortelle oss om dens integreringshelse. Og hvis tjenesten trenger å produsere en melding et annet sted (WebApp), vil den produsere denne testmeldingen. Og hvis vi kjører en tjeneste på OrderProcessing-siden, legger den først ut hva den kan poste uavhengig, og hvis det er noen avhengige ting, så leser den et sett med testmeldinger fra bussen, forstår at den kan behandle dem, rapportere det og , om nødvendig, post dem videre, og om dette sier han - alt er ok, jeg er i live.

Svært ofte hører vi spørsmålet "hvordan kan vi teste dette på kampdata?" Vi snakker for eksempel om samme bestillingstjeneste. Ordren sender meldinger til lageret der varene er avskrevet: vi kan ikke teste dette på kampdata, fordi "varene mine vil bli avskrevet!" Løsning: Planlegg hele denne testen i begynnelsen. Du har også enhetstester som gjør narr. Så, gjør det på et dypere nivå der du har en kommunikasjonskanal som ikke skader driften av virksomheten.

Infrastrukturnivå

Infrastrukturovervåking er noe som lenge har vært ansett som å overvåke seg selv.

• Infrastrukturovervåking kan og bør lanseres som en egen prosess.
• Du bør ikke starte med infrastrukturovervåking på et løpende prosjekt, selv om du virkelig ønsker det. Dette er en smerte for alle devops. "Først overvåker jeg klyngen, jeg vil overvåke infrastrukturen" - dvs. Først vil den overvåke hva som ligger under, men vil ikke gå inn i søknaden. Fordi applikasjonen er en uforståelig ting for devops. Det ble lekket til ham, og han forstår ikke hvordan det fungerer. Og han forstår infrastrukturen og begynner med den. Men nei - du må alltid overvåke applikasjonen først.
• Ikke gå over bord med antall varsler. Tatt i betraktning kompleksiteten til moderne systemer, flyr varsler konstant, og du må på en eller annen måte leve med denne haugen av varsler. Og den tilkallende personen, etter å ha sett på hundre av de neste varslene, vil bestemme "Jeg vil ikke tenke på det." Varsler skal kun varsle om kritiske ting.

Søknadsnivå som forretningsenhet

Viktige punkter:

• ELK. Dette er industristandarden. Hvis du av en eller annen grunn ikke samler logger, begynn å gjøre det umiddelbart.
• APM. Eksterne APM-er som en måte å raskt lukke applikasjonsovervåking (NewRelic, BlackFire, Datadog). Du kan installere denne tingen midlertidig for i det minste på en eller annen måte å forstå hva som skjer med deg.
• Sporing. I dusinvis av mikrotjenester må du spore alt, fordi forespørselen ikke lenger lever av seg selv. Det er veldig vanskelig å legge til senere, så det er bedre å umiddelbart planlegge sporing i utviklingen - dette er arbeidet og nytten til utviklerne. Hvis du ikke har implementert det ennå, implementer det! Se Jaeger/Zipkin

Varsler

• Organisering av et varslingssystem: i forhold til å overvåke en haug med ting, bør det være et enhetlig system for å sende varsler. Det kan du i Grafana. I Vesten bruker alle PagerDuty. Varsler skal være tydelige (f.eks. hvor de kom fra...). Og det er lurt å kontrollere at varsler i det hele tatt mottas
• Organisering av et vaktsystem: varsler skal ikke sendes til alle (enten vil alle reagere i en folkemengde, eller ingen vil reagere). Utviklere må også være på vakt: sørg for å definere ansvarsområder, lage klare instruksjoner og skrive i den nøyaktig hvem de skal ringe på mandag og onsdag, og hvem de skal ringe på tirsdag og fredag ​​(ellers ringer de ikke noen engang i hendelse av et stort problem - de vil være redde for å vekke deg eller forstyrre : folk liker vanligvis ikke å ringe og vekke andre mennesker, spesielt om natten). Og forklar at det å be om hjelp ikke er en indikator på inkompetanse ("Jeg ber om hjelp, det betyr at jeg er en dårlig arbeider"), oppmuntre forespørsler om hjelp.
• Organisering av en "kunnskapsbase" og arbeidsflyt for hendelsesbehandling: For hver alvorlig hendelse bør det planlegges en obduksjon, og som et midlertidig tiltak bør handlinger som vil løse hendelsen registreres. Og gjør det til en praksis at gjentatte varsler er synd; de må fikses i kode- eller infrastrukturarbeid.

Teknologistabel

La oss forestille oss at stabelen vår er som følger:

• datainnsamling - Prometheus + Grafana;
• logganalyse - ELK;
• for APM eller Tracing - Jaeger (Zipkin).

Valget av alternativer er ikke kritisk. For hvis du i begynnelsen forsto hvordan du skulle overvåke systemet og skrev ned en plan, så begynner du å velge verktøy som passer dine behov. Spørsmålet er hva du valgte å overvåke i utgangspunktet. For kanskje verktøyet du valgte i begynnelsen ikke passer dine behov i det hele tatt.

Noen tekniske punkter som jeg ser overalt i det siste:

Prometheus blir presset inne i Kubernetes – hvem kom på dette?! Hvis klyngen din krasjer, hva vil du gjøre? Hvis du har en kompleks klynge inne, bør det være et slags overvåkingssystem inne i klyngen, og noen utenfor, som samler inn data fra klyngen.

Inne i klyngen samler vi tømmerstokker og alt annet. Men overvåkingssystemet må være utenfor. Svært ofte, i en klynge der det er Promtheus installert internt, er det også systemer som utfører eksterne kontroller av nettstedets drift. Hva om forbindelsene dine til omverdenen har falt og applikasjonen ikke fungerer? Det viser seg at alt er bra inni, men det gjør ikke ting enklere for brukerne.

Funn

• Overvåking av utvikling er ikke installasjon av verktøy, men utvikling av et programvareprodukt. 98 % av dagens overvåking er koding. Koding i tjenester, koding av eksterne sjekker, kontroll av eksterne tjenester, og det er alt.
• Ikke kast bort utviklernes tid på overvåking: det kan ta opptil 30 % av arbeidet deres, men det er verdt det.
• Devops, ikke bekymre deg for at du ikke kan overvåke noe, fordi noen ting er en helt annen måte å tenke på. Du var ikke en programmerer, og overvåkingsarbeid er akkurat deres jobb.
• Hvis prosjektet allerede kjører og ikke overvåkes (og du er leder), alloker ressurser for overvåking.
• Hvis produktet allerede er i produksjon, og du er en devops som ble bedt om å "sette opp overvåking" - prøv å forklare ledelsen hva jeg skrev alt dette om.

Dette er en utvidet versjon av rapporten på Saint Highload++-konferansen.

Hvis du er interessert i mine ideer og tanker om det og relaterte emner, så kan du her les kanalen ????

Kilde: www.habr.com