Vi tenkte på å lage et overvåkingssystem på stadiet med å danne produktteam. Det ble klart at vår virksomhet – utnyttelse – ikke faller inn i disse lagene. Hvorfor det?
Faktum er at alle teamene våre er bygget rundt individuelle informasjonssystemer, mikrotjenester og fronter, slik at teamene ikke ser den generelle helsen til hele systemet som en helhet. For eksempel vet de kanskje ikke hvordan en liten del i den dype bakenden påvirker frontenden. Deres interesseområde er begrenset til systemene som systemet deres er integrert med. Hvis et team og dets tjeneste A nesten ikke har noen forbindelse med tjeneste B, så er en slik tjeneste nesten usynlig for teamet.
Teamet vårt jobber på sin side med systemer som er veldig sterkt integrert med hverandre: det er mange forbindelser mellom dem, dette er en veldig stor infrastruktur. Og driften av nettbutikken avhenger av alle disse systemene (som vi forresten har et stort antall av).
Så det viser seg at vår avdeling ikke tilhører noe lag, men ligger litt til siden. I hele denne historien er vår oppgave å forstå hvordan informasjonssystemer fungerer, deres funksjonalitet, integrasjoner, programvare, nettverk, maskinvare og hvordan alt dette er koblet til hverandre.
Plattformen som våre nettbutikker opererer på ser slik ut:
- foran
- mellomkontor
- back office
Uansett hvor mye vi ønsker, skjer det ikke at alle systemer fungerer knirkefritt og feilfritt. Poenget er igjen antallet systemer og integrasjoner - med noe som vårt er noen hendelser uunngåelige, til tross for kvaliteten på testingen. Dessuten, både innenfor et eget system og når det gjelder deres integrasjon. Og du må overvåke tilstanden til hele plattformen omfattende, og ikke bare en individuell del av den.
Ideelt sett bør helseovervåking over hele plattformen automatiseres. Og vi kom til overvåking som en uunngåelig del av denne prosessen. I utgangspunktet ble den kun bygget for frontlinjedelen, mens nettverksspesialister, programvare- og maskinvareadministratorer hadde og fortsatt har sine egne lag-for-lag-overvåkingssystemer. Alle disse personene fulgte overvåkingen kun på sitt eget nivå, ingen hadde en helhetlig forståelse heller.
For eksempel, hvis en virtuell maskin krasjer, er det i de fleste tilfeller bare administratoren som er ansvarlig for maskinvaren og den virtuelle maskinen som vet om det. I slike tilfeller så frontlinjeteamet selve det faktum at applikasjonen krasjet, men den hadde ikke data om krasjet til den virtuelle maskinen. Og administratoren kan vite hvem kunden er og ha en grov ide om hva som for øyeblikket kjører på denne virtuelle maskinen, forutsatt at det er et slags stort prosjekt. Han vet mest sannsynlig ikke om de små. I alle fall må administratoren gå til eieren og spørre hva som var på denne maskinen, hva som må gjenopprettes og hva som må endres. Og hvis noe virkelig brøt sammen, begynte de å løpe rundt i sirkler – fordi ingen så systemet som en helhet.
Til syvende og sist påvirker slike uensartede historier hele frontend, brukere og kjernevirksomheten vår – nettsalg. Siden vi ikke er en del av et team, men er engasjert i driften av alle e-handelsapplikasjoner som en del av en nettbutikk, tok vi på oss oppgaven med å lage et omfattende overvåkingssystem for e-handelsplattformen.
Systemstruktur og stabel
Vi startet med å identifisere flere overvåkingslag for systemene våre, der vi måtte samle inn beregninger. Og alt dette måtte kombineres, og det var det vi gjorde i den første fasen. Nå på dette stadiet ferdigstiller vi samlingen av metrikk av høyeste kvalitet på tvers av alle lagene våre for å bygge en korrelasjon og forstå hvordan systemer påvirker hverandre.
Mangelen på omfattende overvåking i de innledende stadiene av applikasjonslanseringen (siden vi begynte å bygge den da de fleste systemene var i produksjon) førte til at vi hadde betydelig teknisk gjeld for å sette opp overvåking av hele plattformen. Vi hadde ikke råd til å fokusere på å sette opp overvåking for én IS og utarbeide overvåking for den i detalj, siden resten av systemene ville stå uten overvåking en stund. For å løse dette problemet identifiserte vi en liste over de mest nødvendige beregningene for å vurdere tilstanden til informasjonssystemet etter lag og begynte å implementere den.
Derfor bestemte de seg for å spise elefanten i deler.
Vårt system består av:
- maskinvare;
- operativsystem;
- programvare;
- UI-deler i overvåkingsapplikasjonen;
- forretningsmålinger;
- integrasjonsapplikasjoner;
- informasjonssikkerhet;
- nettverk;
- trafikkbalanser.
I sentrum av dette systemet er overvåking av seg selv. For generelt å forstå tilstanden til hele systemet, må du vite hva som skjer med applikasjoner på alle disse lagene og på tvers av hele settet med applikasjoner.
Så om stabelen.
Vi bruker åpen kildekode-programvare. På senteret har vi Zabbix, som vi først og fremst bruker som et varslingssystem. Alle vet at den er ideell for infrastrukturovervåking. Hva betyr dette? Akkurat de lavnivåmålingene som hvert selskap som vedlikeholder sitt eget datasenter har (og Sportmaster har sine egne datasentre) – servertemperatur, minnestatus, raid, nettverksenhetsmålinger.
Vi har integrert Zabbix med Telegram messenger og Microsoft Teams, som brukes aktivt i team. Zabbix dekker laget av det faktiske nettverket, maskinvaren og noe programvare, men det er ikke et universalmiddel. Vi beriker disse dataene fra noen andre tjenester. På maskinvarenivå kobler vi for eksempel direkte via API til vårt virtualiseringssystem og samler inn data.
Hva annet. I tillegg til Zabbix bruker vi Prometheus, som lar oss overvåke beregninger i en dynamisk miljøapplikasjon. Det vil si at vi kan motta applikasjonsberegninger via et HTTP-endepunkt og ikke bekymre oss for hvilke beregninger som skal lastes inn i det og hvilke som ikke. Basert på disse dataene kan analytiske spørringer utvikles.
Datakilder for andre lag, for eksempel forretningsmålinger, er delt inn i tre komponenter.
For det første er dette eksterne forretningssystemer, Google Analytics, vi samler inn beregninger fra logger. Fra dem får vi data om aktive brukere, konverteringer og alt annet relatert til virksomheten. For det andre er dette et UI-overvåkingssystem. Det bør beskrives mer detaljert.
En gang i tiden begynte vi med manuell testing og det vokste til automatiske tester av funksjonalitet og integrasjoner. Fra dette laget vi overvåking, og la bare hovedfunksjonaliteten igjen, og stolte på markører som er så stabile som mulig og ikke endres ofte over tid.
Den nye teamstrukturen betyr at alle applikasjonsaktiviteter er begrenset til produktteam, så vi sluttet å gjøre ren testing. I stedet laget vi UI-overvåking fra testene, skrevet i Java, Selenium og Jenkins (brukt som et system for å lansere og generere rapporter).
Vi hadde mange tester, men til slutt bestemte vi oss for å gå til hovedveien, metrikken på toppnivå. Og hvis vi har mange spesifikke tester, vil det være vanskelig å holde dataene oppdatert. Hver påfølgende utgivelse vil ødelegge hele systemet betydelig, og alt vi vil gjøre er å fikse det. Derfor fokuserte vi på helt grunnleggende ting som sjelden endres, og vi overvåker dem kun.
Til slutt, for det tredje, er datakilden et sentralisert loggingssystem. Vi bruker Elastic Stack for logger, og så kan vi trekke disse dataene inn i vårt overvåkingssystem for forretningsmålinger. I tillegg til alt dette har vi vår egen Monitoring API-tjeneste, skrevet i Python, som spør etter alle tjenester via API og samler inn data fra dem til Zabbix.
En annen uunnværlig egenskap ved overvåking er visualisering. Vår er basert på Grafana. Den skiller seg ut blant andre visualiseringssystemer ved at den lar deg visualisere beregninger fra forskjellige datakilder på dashbordet. Vi kan samle inn beregninger på toppnivå for en nettbutikk, for eksempel antall bestillinger som er lagt inn den siste timen fra DBMS, ytelsesmålinger for operativsystemet som denne nettbutikken kjører på fra Zabbix, og beregninger for forekomster av denne applikasjonen fra Prometheus. Og alt dette vil være på ett dashbord. Oversiktlig og tilgjengelig.
La meg merke seg angående sikkerhet - vi er i ferd med å ferdigstille systemet, som vi senere skal integrere med det globale overvåkingssystemet. Etter min mening er hovedproblemene som e-handel står overfor innen informasjonssikkerhet knyttet til bots, parsere og brute force. Vi må holde et øye med dette, for alt dette kan kritisk påvirke både driften av applikasjonene våre og omdømmet vårt fra et forretningsmessig synspunkt. Og med den valgte stabelen dekker vi disse oppgavene.
Et annet viktig poeng er at påføringslaget er satt sammen av Prometheus. Selv er han også integrert med Zabbix. Og vi har også sitespeed, en tjeneste som lar oss se parametere som lastehastigheten til siden vår, flaskehalser, sidegjengivelse, lasting av skript osv., den er også API-integrert. Så våre beregninger er samlet i Zabbix, og følgelig varsler vi også derfra. Alle varsler sendes for øyeblikket til de viktigste sendemetodene (for nå er det e-post og telegram, MS Teams har også nylig blitt koblet til). Det er planer om å oppgradere varslingen til en slik tilstand at smartroboter fungerer som en tjeneste og gir overvåkingsinformasjon til alle interesserte produktteam.
For oss er målinger viktige ikke bare for individuelle informasjonssystemer, men også generelle målinger for hele infrastrukturen som applikasjoner bruker: klynger av fysiske servere som virtuelle maskiner kjører på, trafikkbalansere, Network Load Balancers, selve nettverket, utnyttelse av kommunikasjonskanaler. . Pluss beregninger for våre egne datasentre (vi har flere av dem og infrastrukturen er ganske stor).
Fordelene med vårt overvåkingssystem er at vi med dets hjelp ser helsestatusen til alle systemene og kan vurdere deres innvirkning på hverandre og på delte ressurser. Og til syvende og sist lar det oss engasjere oss i ressursplanlegging, som også er vårt ansvar. Vi forvalter serverressurser - en pool innen e-handel, idriftsetter og tar ut nytt utstyr, kjøper inn ekstra nytt utstyr, gjennomfører revisjon av ressursutnyttelse m.m. Hvert år planlegger teamene nye prosjekter, utvikler systemene sine, og det er viktig for oss å gi dem ressurser.
Og ved hjelp av beregninger ser vi utviklingen i ressursforbruket til informasjonssystemene våre. Og basert på dem kan vi planlegge noe. På virtualiseringsnivå samler vi inn data og ser informasjon om tilgjengelige ressurser per datasenter. Og allerede inne i datasenteret kan du se resirkuleringen, den faktiske distribusjonen og ressursforbruket. Dessuten, både med frittstående servere og virtuelle maskiner og klynger av fysiske servere som alle disse virtuelle maskinene spinner kraftig på.
Prospekter
Nå har vi kjernen i systemet som helhet klar, men det er fortsatt mange ting som fortsatt må jobbes med. Dette er som et minimum et informasjonssikkerhetslag, men det er også viktig å nå nettverket, utvikle varsling og løse problemet med korrelasjon. Vi har mange lag og systemer, og på hvert lag er det mange flere beregninger. Det viser seg å være en matryoshka i samme grad som en matryoshka.
Vår oppgave er til syvende og sist å gi de riktige varslene. For eksempel, hvis det var et problem med maskinvaren, igjen, med en virtuell maskin, og det var en viktig applikasjon, og tjenesten ble ikke sikkerhetskopiert på noen måte. Vi finner ut at den virtuelle maskinen har dødd. Da vil forretningsberegninger varsle deg: brukere har forsvunnet et sted, det er ingen konvertering, brukergrensesnittet i grensesnittet er utilgjengelig, programvare og tjenester har også dødd.
I denne situasjonen vil vi motta spam fra varsler, og dette passer ikke lenger inn i formatet til et skikkelig overvåkingssystem. Spørsmålet om korrelasjon oppstår. Derfor, ideelt sett, bør overvåkingssystemet vårt si: "Gutter, deres fysiske maskin har dødd, og sammen med den denne applikasjonen og disse beregningene," ved hjelp av ett varsel, i stedet for å bombardere oss rasende med hundre varsler. Det bør rapportere det viktigste - årsaken, som hjelper til med å raskt eliminere problemet på grunn av lokaliseringen.
Vårt varslingssystem og varslingsbehandling er bygget rundt en XNUMX-timers hotline-tjeneste. Alle varsler som anses som et must-have og som er inkludert i sjekklisten sendes dit. Hvert varsel må ha en beskrivelse: hva som skjedde, hva det faktisk betyr, hva det påvirker. Og også en lenke til dashbordet og instruksjoner om hva du skal gjøre i dette tilfellet.
Alt dette handler om kravene for å bygge et varsel. Da kan situasjonen utvikle seg i to retninger – enten er det et problem og må løses, eller så har det vært svikt i overvåkingssystemet. Men i alle fall må du gå og finne ut av det.
I gjennomsnitt mottar vi nå rundt hundre varsler per dag, tatt i betraktning at korrelasjonen av varsler ennå ikke er riktig konfigurert. Og hvis vi trenger å utføre teknisk arbeid, og vi tvangsslår av noe, øker antallet betraktelig.
I tillegg til å overvåke systemene som vi driver og samle inn beregninger som anses som viktige på vår side, lar overvåkingssystemet oss samle inn data for produktteam. De kan påvirke sammensetningen av beregninger i informasjonssystemene vi overvåker.
Vår kollega kan komme og be om å legge til noen beregninger som vil være nyttige for både oss og teamet. Eller, for eksempel, teamet har kanskje ikke nok av de grunnleggende beregningene vi har; de må spore noen spesifikke. I Grafana oppretter vi en plass for hvert lag og gir administratorrettigheter. Hvis et team trenger dashbord, men de selv ikke kan/vet ikke hvordan de skal gjøre det, hjelper vi dem.
Siden vi er utenfor flyten av teamets verdiskaping, deres utgivelser og planlegging, kommer vi gradvis til den konklusjon at utgivelser av alle systemer er sømløse og kan rulles ut daglig uten koordinering med oss. Og det er viktig for oss å overvåke disse utgivelsene, fordi de potensielt kan påvirke driften av applikasjonen og ødelegge noe, og dette er kritisk. For å administrere utgivelser bruker vi Bamboo, hvorfra vi mottar data via API og kan se hvilke utgivelser som er utgitt i hvilke informasjonssystemer og deres status. Og det viktigste er til hvilken tid. Vi legger utgivelsesmarkører over de viktigste kritiske beregningene, noe som er visuelt svært veiledende i tilfelle problemer.
På denne måten kan vi se sammenhengen mellom nye utgivelser og nye problemer. Hovedideen er å forstå hvordan systemet fungerer på alle lag, raskt lokalisere problemet og fikse det like raskt. Tross alt skjer det ofte at det som tar mest tid ikke er å løse problemet, men å lete etter årsaken.
Og på dette området ønsker vi i fremtiden å fokusere på proaktivitet. Ideelt sett vil jeg gjerne vite om et problem som nærmer seg på forhånd, og ikke i etterkant, slik at jeg kan forhindre det i stedet for å løse det. Noen ganger oppstår falske alarmer fra overvåkingssystemet, både på grunn av menneskelige feil og på grunn av endringer i applikasjonen. Og vi jobber med dette, feilsøker det og prøver å advare brukere som bruker det hos oss om dette før noen manipulasjon av overvåkingssystemet , eller utfør disse aktivitetene i det tekniske vinduet.
Så systemet har blitt lansert og har fungert med suksess siden begynnelsen av våren... og viser veldig reell fortjeneste. Dette er selvfølgelig ikke den endelige versjonen; vi kommer til å introdusere mange flere nyttige funksjoner. Men akkurat nå, med så mange integrasjoner og applikasjoner, er overvåkingsautomatisering virkelig uunngåelig.
Hvis du også overvåker store prosjekter med et betydelig antall integrasjoner, skriv i kommentarfeltet hvilken sølvkule du fant for dette.
Kilde: www.habr.com