Hej alle!
Vores virksomhed er engageret i softwareudvikling og efterfølgende teknisk support. Teknisk support kræver ikke kun at rette fejl, men også at overvåge ydeevnen af vores applikationer.
For eksempel, hvis en af tjenesterne er gået ned, skal du automatisk registrere dette problem og begynde at løse det og ikke vente på, at utilfredse brugere kontakter teknisk support.
Vi har en lille virksomhed, vi har ikke ressourcerne til at studere og vedligeholde komplekse løsninger til overvågning af applikationer, vi var nødt til at finde en enkel og effektiv løsning.
Overvågningsstrategi
Det er ikke let at kontrollere funktionaliteten af en applikation; denne opgave er ikke-triviel, man kan endda sige kreativ. Det er især svært at verificere et komplekst multi-link system.
Hvordan kan du spise en elefant? Kun i dele! Vi bruger denne tilgang til at overvåge applikationer.
Essensen af vores overvågningsstrategi:
Opdel din ansøgning i komponenter.
Opret kontroltjek for hver komponent.
En komponent anses for operationel, hvis alle dens kontroltjek udføres uden fejl. En applikation anses for sund, hvis alle dens komponenter er funktionelle.
Ethvert system kan således repræsenteres som et træ af komponenter. Komplekse komponenter er opdelt i enklere. Simple komponenter har tjek.
Benchmarks er ikke beregnet til at udføre funktionelle tests, de er ikke enhedstests. Kontroltjek skal kontrollere, hvordan komponenten føles på det aktuelle tidspunkt, om der er alle de nødvendige ressourcer til dens funktion, og om der er problemer.
Der er ingen mirakler; de fleste checks skal udvikles uafhængigt. Men vær ikke bange, for i de fleste tilfælde tager et tjek 5-10 linjer kode, men du kan implementere enhver logik, og du vil tydeligt forstå, hvordan kontrollen fungerer.
Overvågningssystem
Lad os sige, at vi delte applikationen op i komponenter, fandt på og implementerede kontroller for hver komponent, men hvad skal man gøre med resultaterne af disse kontroller? Hvordan ved vi, om en kontrol mislykkedes?
Vi skal bruge et overvågningssystem. Hun vil udføre følgende opgaver:
- Modtag testresultater og brug dem til at bestemme komponenternes status.
Visuelt ser dette ud som at fremhæve komponenttræet. Funktionelle komponenter bliver grønne, problematiske bliver røde. - Udfør generelle tjek ud af boksen.
Overvågningssystemet kan selv udføre nogle kontroller. Hvorfor genopfinde hjulet, lad os bruge dem. For eksempel kan du kontrollere, at en hjemmeside åbner, eller at serveren pinger. - Send meddelelser om problemer til interesserede.
- Visualisering af overvågningsdata, levering af rapporter, grafer og statistik.
Kort beskrivelse af ASMO-systemet
Det er bedst at forklare med et eksempel. Lad os se på, hvordan overvågning af ASMO-systemets ydeevne er organiseret.
ASMO er et automatiseret meteorologisk støttesystem. Systemet hjælper vejservicespecialister med at forstå, hvor og hvornår det er nødvendigt at behandle vejen med afisningsmaterialer. Systemet indsamler data fra vejkontrolpunkter. Et vejkontrolpunkt er et sted på vejen, hvor udstyr er installeret: en vejrstation, et videokamera osv. For at forudsige farlige situationer modtager systemet vejrudsigter fra eksterne kilder.
Så sammensætningen af systemet er ret typisk: hjemmeside, agent, udstyr. Lad os begynde at overvåge.
Nedbrydning af systemet i komponenter
Følgende komponenter kan skelnes i ASMO-systemet:
1. Personlig konto
Dette er en webapplikation. Som minimum skal du kontrollere, at applikationen er tilgængelig på internettet.
2. Database
Databasen gemmer data, der er vigtige for rapportering, og du skal sikre, at databasesikkerhedskopiering er oprettet.
3. Server
Med server mener vi den hardware, som applikationer kører på. Det er nødvendigt at kontrollere status for HDD, RAM, CPU.
4. Agent
Dette er en Windows-tjeneste, der udfører mange forskellige opgaver på en tidsplan. Du skal som minimum kontrollere, at tjenesten kører.
5. Agent opgave
Bare det at vide, at en agent arbejder, er ikke nok. En agent kan arbejde, men udfører ikke sine tildelte opgaver. Lad os opdele agentkomponenten i opgaver og kontrollere, om hver agentopgave fungerer korrekt.
6. Vejkontrolpunkter (beholder med alle MPC'er)
Der er mange vejkontrolpunkter, så lad os kombinere alle MPC'er i én komponent. Dette vil gøre det mere bekvemt at læse overvågningsdata. Når du ser status for "ASMO-system"-komponenten, vil det straks være klart, hvor problemerne er: i applikationer, hardware eller i det maksimale kontrolsystem.
7. Vejkontrolpunkt (én maksimumgrænse)
Vi vil anse denne komponent for at kunne serviceres, hvis alle enheder på denne MPC kan repareres.
8. Enhed
Dette er et videokamera eller vejrstation, der er installeret ved den maksimale koncentrationsgrænse. Det er nødvendigt at kontrollere, at enheden fungerer korrekt.
I overvågningssystemet vil komponenttræet se således ud:
Overvågning af webapplikationer
Så vi har opdelt systemet i komponenter, nu skal vi komme med checks for hver komponent.
For at overvåge en webapplikation bruger vi følgende kontroller:
1. Kontrol af åbningen af hovedsiden
Denne kontrol udføres af overvågningssystemet. For at udføre det angiver vi sideadressen, det forventede svarfragment og den maksimale anmodningsudførelsestid.
2. Kontrol af domænebetalingsfristen
En meget vigtig kontrol. Når et domæne forbliver ubetalt, kan brugere ikke åbne webstedet. Løsning af problemet kan tage flere dage, fordi... DNS-ændringer anvendes ikke med det samme.
3. Kontrol af SSL-certifikatet
I dag bruger næsten alle websteder https-protokollen til adgang. For at protokollen skal fungere korrekt, skal du have et gyldigt SSL-certifikat.
Nedenfor er "Personlig konto"-komponenten i overvågningssystemet:
Alle de ovenstående kontroller fungerer for de fleste applikationer og kræver ingen kodning. Dette er meget fedt, fordi du kan begynde at overvåge enhver webapplikation på 5 minutter. Nedenfor er yderligere kontroller, der kan udføres for en webapplikation, men deres implementering er mere kompleks og applikationsspecifik, så vi vil ikke dække dem i denne artikel.
Hvad kan du ellers tjekke?
For at overvåge din webapplikation mere fuldstændigt kan du udføre følgende kontroller:
- Antal JavaScript-fejl pr. periode
- Antal fejl på webapplikationssiden (back-end) for perioden
- Antal mislykkede webapplikationssvar (svarkode 404, 500 osv.)
- Gennemsnitlig udførelsestid for forespørgsler
Overvågning af en Windows-tjeneste (agent)
I ASMO-systemet spiller agenten rollen som en opgaveplanlægger, som udfører planlagte opgaver i baggrunden.
Hvis alle agentopgaver udføres korrekt, fungerer agenten korrekt. Det viser sig, at for at overvåge en agent, skal du overvåge dens opgaver. Derfor opdeler vi "Agent"-komponenten i opgaver. Til hver opgave vil vi oprette en separat komponent i overvågningssystemet, hvor "Agent"-komponenten vil være "forælderen".
Vi opdeler Agent-komponenten i underordnede komponenter (opgaver):
Så vi har opdelt en kompleks komponent i flere simple. Nu skal vi komme med kontrol for hver enkelt komponent. Bemærk venligst, at den overordnede komponent "Agent" ikke vil have nogen kontrol, fordi overvågningssystemet vil beregne sin status uafhængigt baseret på status for dens underordnede komponenter. Med andre ord, hvis alle opgaver er fuldført med succes, kører agenten med succes.
Der er mere end hundrede opgaver i ASMO-systemet, er det virkelig nødvendigt at komme med unikke checks for hver opgave? Selvfølgelig bliver kontrollen bedre, hvis vi kommer med og implementerer vores egne specielle tjek for hver agentopgave, men i de fleste tilfælde er det nok at bruge universelle tjek.
ASMO-systemet bruger kun universelle kontroller til opgaver, og dette er nok til at overvåge systemets ydeevne.
Kontrol af fremskridt
Den enkleste og mest effektive kontrol er udførelseskontrollen. Kontrollen verificerer, at opgaven er udført uden fejl. Alle opgaver har dette tjek.
Verifikationsalgoritme
Efter hver opgaveudførelse skal du sende resultatet af SUCCES-kontrollen til overvågningssystemet, hvis opgaveudførelsen var vellykket, eller FEJL, hvis udførelsen blev fuldført med en fejl.
Denne kontrol kan opdage følgende problemer:
- Opgaven kører, men mislykkes med en fejl.
- Opgaven er holdt op med at køre, for eksempel har den frosset.
Lad os se på, hvordan disse problemer løses mere detaljeret.
Problem 1 – Opgaven kører, men mislykkes med en fejl
Nedenfor er et tilfælde, hvor opgaven kører, men fejler mellem 14:00 og 16:00.
Figuren viser, at når en opgave fejler, sendes der straks et signal til overvågningssystemet, og status for den tilsvarende kontrol i overvågningssystemet bliver alarm.
Bemærk venligst, at i overvågningssystemet afhænger komponentens status af verifikationsstatus. Kontrollens alarmstatus vil ændre alle komponenter på højere niveau til alarm, se figuren nedenfor.
Problem 2 - Opgaven stoppede med at udføre (frosset)
Hvordan vil overvågningssystemet forstå, at en opgave sidder fast?
Kontrolresultatet har en gyldighedsperiode, f.eks. 1 time. Hvis der går en time, og der ikke er noget nyt testresultat, vil overvågningssystemet indstille teststatus til alarm.
På billedet ovenfor blev lyset slukket klokken 14. Klokken 00:15 vil overvågningssystemet registrere, at testresultatet (fra kl. 00:14) er råddent, pga. Relevanstiden er udløbet (en time), men der er ikke noget nyt resultat, og vil skifte checken til alarmstatus.
16:00 blev lysene tændt igen, programmet vil fuldføre opgaven og sende udførelsesresultatet til overvågningssystemet, teststatus vil igen blive succes.
Hvilken kontrolrelevanstid skal jeg bruge?
Relevanstiden skal være større end opgavens udførelsesperiode. Jeg anbefaler at indstille relevanstiden 2-3 gange længere end opgavens udførelsesperiode. Dette er nødvendigt for at undgå at modtage falske notifikationer, når for eksempel en opgave tog længere tid end normalt, eller nogen genindlæste programmet.
Kontrol af fremskridt
ASMO-systemet har en "Load Forecast"-opgave, som forsøger at downloade en ny prognose fra en ekstern kilde en gang i timen. Det præcise tidspunkt, hvor en ny prognose dukker op i det eksterne system, kendes ikke, men det er kendt, at dette sker 2 gange om dagen. Det viser sig, at hvis der ikke er en ny vejrudsigt i flere timer, så er det normalt, men hvis der ikke kommer en ny vejrudsigt i mere end et døgn, så er der noget, der er gået i stykker et sted. For eksempel kan dataformatet i et eksternt prognosesystem ændre sig, hvorfor ASMO ikke vil se en ny prognoseudgivelse.
Verifikationsalgoritme
Opgaven sender resultatet af SUCCES-tjekket til overvågningssystemet, når det lykkes at få fremskridt (download af en ny vejrudsigt). Hvis der ikke er nogen fremskridt, eller der opstår en fejl, sendes intet til overvågningssystemet.
Checken skal have et relevansinterval, så den i løbet af denne tid garanteres at modtage nye fremskridt.
Bemærk venligst, at vi vil lære om problemet med en forsinkelse, fordi overvågningssystemet venter, indtil gyldighedsperioden for det sidste scanningsresultat udløber. Derfor behøver kontrollens gyldighedsperiode ikke gøres for lang.
Database overvågning
For at kontrollere databasen i ASMO-systemet udfører vi følgende kontroller:
- Bekræfter oprettelse af backup
- Kontrollerer ledig diskplads
Bekræfter oprettelse af backup
I de fleste applikationer er det vigtigt at have opdaterede databasebackups, så hvis serveren fejler, kan du implementere programmet til en ny server.
ASMO opretter en sikkerhedskopi en gang om ugen og sender den til lageret. Når denne procedure er gennemført med succes, sendes resultatet af succeskontrollen til overvågningssystemet. Verifikationsresultatet er gyldigt i 9 dage. De der. For at kontrollere oprettelsen af sikkerhedskopier bruges "fremskridtstjek"-mekanismen, som vi diskuterede ovenfor.
Kontrollerer ledig diskplads
Hvis der ikke er nok ledig plads på disken, vil databasen ikke kunne fungere korrekt, så det er vigtigt at kontrollere mængden af ledig plads.
Det er praktisk at bruge metrics til at kontrollere numeriske parametre.
Metrics er en numerisk variabel, hvis værdi overføres til overvågningssystemet. Overvågningssystemet kontrollerer tærskelværdierne og beregner den metriske status.
Nedenfor er et billede af, hvordan "Database"-komponenten ser ud i overvågningssystemet:
Server overvågning
For at overvåge serveren bruger vi følgende kontroller og målinger:
1. Frigør diskplads
Hvis diskpladsen løber tør, vil applikationen ikke kunne fungere. Vi bruger 2 tærskelværdier: det første niveau er ADVARSEL, det andet niveau er ALARM.
2. Gennemsnitlig RAM-værdi i procent i timen
Vi bruger timegennemsnittet, fordi... vi er ikke interesserede i sjældne racer.
3. Gennemsnitlig CPU-procent i timen
Vi bruger timegennemsnittet, fordi... vi er ikke interesserede i sjældne racer.
4. Ping-tjek
Tjek at serveren er online. Overvågningssystemet kan udføre denne kontrol, der er ingen grund til at skrive kode.
Nedenfor er et billede af, hvordan "Server"-komponenten ser ud i overvågningssystemet:
Overvågning af udstyr
Jeg vil fortælle dig, hvordan dataene er opnået. For hvert vejkontrolpunkt (MPC) er der en opgave i opgaveplanlæggeren, for eksempel "Survey MPC M2 km 200". Opgaven modtager data fra alle MPC-enheder hvert 30. minut.
Kommunikationskanal problem
Det meste af udstyret er placeret uden for byen, et GSM-netværk bruges til datatransmission, som ikke fungerer stabilt (der er et netværk, eller der er ikke et).
På grund af hyppige netværksfejl så tjek af MPC-undersøgelsen i overvågning først sådan ud:
Det blev klart, at dette ikke fungerede, fordi der var mange falske meddelelser om problemer. Derefter blev det besluttet at bruge et "fremskridtstjek" for hver enhed, dvs. Kun successignalet sendes til overvågningssystemet, når enheden polles uden fejl. Relevanstiden blev sat til 5 timer.
Nu sender overvågning kun meddelelser om problemer, når enheden ikke kan polles i mere end 5 timer. Med en høj grad af sandsynlighed er der ikke tale om falske alarmer, men reelle problemer.
Nedenfor er et billede af, hvordan udstyret ser ud i overvågningssystemet:
Vigtigt!
Når GSM-netværket holder op med at fungere, bliver alle MDC-enheder ikke pollet. For at reducere antallet af e-mails fra overvågningssystemet abonnerer vores ingeniører på meddelelser om komponentproblemer med typen "MPC" i stedet for "Enhed". Dette giver dig mulighed for at modtage én notifikation for hver MPC i stedet for at modtage en separat notifikation for hver enhed.
Endelig ASMO overvågningsskema
Lad os samle det hele og se, hvilken slags overvågningsordning vi har.
Konklusion
Lad os opsummere.
Hvad gav overvågning af ASMO's ydeevne os?
1. Defektelimineringstiden er faldet
Vi har tidligere hørt om fejl fra brugere, men det er ikke alle brugere, der melder om fejl. Det skete, at vi lærte om en funktionsfejl i en systemkomponent en uge efter, at den dukkede op. Nu giver overvågningssystemet besked om problemer, så snart et problem opdages.
2. Systemstabiliteten er øget
Da defekter begyndte at blive elimineret tidligere, begyndte systemet som helhed at arbejde meget mere stabilt.
3. Reduktion af antallet af opkald til teknisk support
Mange problemer er nu løst, før brugerne overhovedet ved om dem. Brugere begyndte at kontakte teknisk support sjældnere. Alt dette har en god effekt på vores omdømme.
4. Øget kunde- og brugerloyalitet
Kunden bemærkede positive ændringer i systemets stabilitet. Brugere støder på færre problemer med at bruge systemet.
5. Reducer omkostningerne til teknisk support
Vi er holdt op med at udføre manuelle kontroller. Nu er alle kontroller automatiseret. Tidligere lærte vi om problemer fra brugerne; det var ofte svært at forstå, hvilket problem brugeren talte om. Nu rapporteres de fleste problemer af overvågningssystemet; meddelelser indeholder tekniske data, som altid gør det klart, hvad der gik galt, og hvor.
Vigtigt!
Du kan ikke installere overvågningssystemet på den samme server, hvor dine applikationer kører. Hvis serveren går ned, vil applikationer holde op med at fungere, og der vil ikke være nogen til at give besked om det.
Overvågningssystemet skal køre på en separat server i et andet datacenter.
Hvis du ikke ønsker at bruge en dedikeret server i et nyt datacenter, kan du bruge et cloud-overvågningssystem. Vores virksomhed bruger Zidium skyovervågningssystem, men du kan bruge et hvilket som helst andet overvågningssystem. Omkostningerne ved et skyovervågningssystem er lavere end at leje en ny server.
Anbefalinger:
- Nedbryd applikationer og systemer i form af et træ af komponenter så detaljeret som muligt, så det vil være praktisk at forstå, hvor og hvad der er brudt, og kontrollen bliver mere komplet.
- Brug tests for at kontrollere funktionaliteten af en komponent. Det er bedre at bruge mange simple checks end én kompleks.
- Konfigurer metriske tærskler på siden af overvågningssystemet i stedet for at skrive dem i kode. Dette vil spare dig for at skulle genkompilere, omkonfigurere eller genstarte programmet.
- For tilpassede kontroller skal du bruge en margen for relevans for at undgå at modtage falske meddelelser, fordi nogle kontroller tog lidt længere tid at gennemføre end normalt.
- Prøv kun at få komponenterne i overvågningssystemet til at blive røde, når der helt sikkert er et problem. Hvis de bliver røde for ingenting, vil du stoppe med at være opmærksom på overvågningssystemets meddelelser, dets betydning vil gå tabt.
Hvis du ikke bruger et overvågningssystem endnu, så start! Det er ikke så svært, som det ser ud til. Få et kick ud af at se på det grønne ingredienstræ, du selv har dyrket.
Held og lykke.
Kilde: www.habr.com