Hei!
Vårt firma er engasjert i programvareutvikling og påfølgende teknisk støtte. Teknisk støtte krever ikke bare retting av feil, men overvåking av ytelsen til applikasjonene våre.
For eksempel, hvis en av tjenestene har krasjet, må du automatisk registrere dette problemet og begynne å løse det, og ikke vente på at misfornøyde brukere skal kontakte teknisk støtte.
Vi har et lite selskap, vi har ikke ressurser til å studere og vedlikeholde noen komplekse løsninger for overvåking av applikasjoner, vi trengte å finne en enkel og effektiv løsning.
Overvåkingsstrategi
Det er ikke lett å sjekke funksjonaliteten til en applikasjon; denne oppgaven er ikke-triviell, man kan til og med si kreativ. Det er spesielt vanskelig å verifisere et komplekst multi-link system.
Hvordan kan du spise en elefant? Kun i deler! Vi bruker denne tilnærmingen til å overvåke applikasjoner.
Essensen av vår overvåkingsstrategi:
Del søknaden din ned i komponenter.
Lag kontrollsjekker for hver komponent.
En komponent regnes som operativ hvis alle dens kontrollsjekker utføres uten feil. En applikasjon anses som sunn hvis alle komponentene er funksjonelle.
Dermed kan ethvert system representeres som et tre av komponenter. Komplekse komponenter brytes ned til enklere. Enkle komponenter har sjekker.
Benchmarks er ikke ment å utføre funksjonell testing, de er ikke enhetstester. Kontrollsjekker bør sjekke hvordan komponenten føles på det aktuelle tidspunktet, om det er alle ressursene som er nødvendige for at den skal fungere, og om det er noen problemer.
Det er ingen mirakler; de fleste sjekker må utvikles uavhengig. Men ikke vær redd, for i de fleste tilfeller tar en sjekk 5-10 linjer med kode, men du kan implementere hvilken som helst logikk, og du vil tydelig forstå hvordan sjekken fungerer.
Overvåkningsstystem
La oss si at vi delte applikasjonen inn i komponenter, kom opp med og implementerte kontroller for hver komponent, men hva skal vi gjøre med resultatene av disse sjekkene? Hvordan vet vi om en sjekk mislyktes?
Vi trenger et overvåkingssystem. Hun skal utføre følgende oppgaver:
- Motta testresultater og bruke dem til å bestemme statusen til komponenter.
Visuelt ser dette ut som å fremheve komponenttreet. Funksjonelle komponenter blir grønne, problematiske blir røde. - Utfør generelle kontroller ut av esken.
Overvåkingssystemet kan selv utføre noen kontroller. Hvorfor finne opp hjulet på nytt, la oss bruke dem. Du kan for eksempel sjekke at en nettside åpnes eller at serveren pinger. - Send meldinger om problemer til interesserte.
- Visualisering av overvåkingsdata, fremskaffelse av rapporter, grafer og statistikk.
Kort beskrivelse av ASMO-systemet
Det er best å forklare med et eksempel. La oss se på hvordan overvåking av ytelsen til ASMO-systemet er organisert.
ASMO er et automatisert meteorologisk støttesystem. Systemet hjelper veiservicespesialister med å forstå hvor og når det er nødvendig å behandle veien med avisingsmaterialer. Systemet samler inn data fra veikontrollpunkter. Et veikontrollpunkt er et sted på veien hvor utstyr er installert: en værstasjon, et videokamera, etc. For å forutsi farlige situasjoner mottar systemet værmeldinger fra eksterne kilder.
Så sammensetningen av systemet er ganske typisk: nettsted, agent, utstyr. La oss begynne å overvåke.
Å bryte ned systemet i komponenter
Følgende komponenter kan skilles i ASMO-systemet:
1. Personlig konto
Dette er en nettapplikasjon. Som et minimum må du sjekke at applikasjonen er tilgjengelig på Internett.
2. Database
Databasen lagrer data som er viktige for rapportering, og du må sørge for at sikkerhetskopiering av databaser er vellykket.
3. Server
Med server mener vi maskinvaren som applikasjonene kjører på. Det er nødvendig å sjekke statusen til HDD, RAM, CPU.
4. Agent
Dette er en Windows-tjeneste som utfører mange forskjellige oppgaver etter en tidsplan. Som et minimum må du sjekke at tjenesten kjører.
5. Agentoppgave
Bare det å vite at en agent jobber er ikke nok. En agent kan jobbe, men ikke utføre sine tildelte oppgaver. La oss dele opp agentkomponenten i oppgaver og sjekke om hver agentoppgave fungerer vellykket.
6. Veikontrollpunkter (beholder for alle MPC-er)
Det er mange veikontrollpunkter, så la oss kombinere alle MPC-er i én komponent. Dette vil gjøre det mer praktisk å lese overvåkingsdata. Når du ser på statusen til "ASMO-system"-komponenten, vil det umiddelbart være klart hvor problemene er: i applikasjoner, maskinvare eller i det maksimale kontrollsystemet.
7. Veikontrollpunkt (én maksimal grense)
Vi vil vurdere denne komponenten som brukbar hvis alle enhetene på denne MPC-en kan repareres.
8. Enhet
Dette er et videokamera eller værstasjon som er installert ved maksimal konsentrasjonsgrense. Det er nødvendig å kontrollere at enheten fungerer som den skal.
I overvåkingssystemet vil komponenttreet se slik ut:
Overvåking av nettapplikasjoner
Så vi har delt opp systemet i komponenter, nå må vi komme opp med kontroller for hver komponent.
For å overvåke en nettapplikasjon bruker vi følgende kontroller:
1. Kontroller åpningen av hovedsiden
Denne kontrollen utføres av overvåkingssystemet. For å utføre det, angir vi sideadressen, det forventede svarfragmentet og maksimal forespørselsutførelsestid.
2. Sjekke domenebetalingsfristen
En veldig viktig sjekk. Når et domene forblir ubetalt, kan ikke brukere åpne siden. Å løse problemet kan ta flere dager, fordi... DNS-endringer tas ikke i bruk umiddelbart.
3. Sjekke SSL-sertifikatet
I dag bruker nesten alle nettsteder https-protokollen for tilgang. For at protokollen skal fungere riktig, trenger du et gyldig SSL-sertifikat.
Nedenfor er "Personlig konto"-komponenten i overvåkingssystemet:
Alle kontrollene ovenfor vil fungere for de fleste applikasjoner og krever ingen koding. Dette er veldig kult fordi du kan begynne å overvåke hvilken som helst nettapplikasjon på 5 minutter. Nedenfor er ytterligere kontroller som kan utføres for en nettapplikasjon, men implementeringen er mer kompleks og applikasjonsspesifikk, så vi vil ikke dekke dem i denne artikkelen.
Hva annet kan du sjekke?
For å overvåke nettapplikasjonen mer fullstendig, kan du utføre følgende kontroller:
- Antall JavaScript-feil per periode
- Antall feil på nettapplikasjonssiden (backend) for perioden
- Antall mislykkede nettapplikasjonssvar (svarkode 404, 500 osv.)
- Gjennomsnittlig utførelsestid for spørringer
Overvåke en Windows-tjeneste (agent)
I ASMO-systemet spiller agenten rollen som en oppgaveplanlegger, som utfører planlagte oppgaver i bakgrunnen.
Hvis alle agentoppgaver fullføres, fungerer agenten som den skal. Det viser seg at for å overvåke en agent, må du overvåke dens oppgaver. Derfor deler vi "Agent"-komponenten inn i oppgaver. For hver oppgave vil vi lage en egen komponent i overvåkingssystemet, hvor "Agent"-komponenten vil være "overordnet".
Vi deler opp Agent-komponenten i underordnede komponenter (oppgaver):
Så vi har brutt ned en kompleks komponent i flere enkle. Nå må vi komme opp med sjekker for hver enkel komponent. Vær oppmerksom på at den overordnede komponenten "Agent" ikke vil ha noen kontroller, fordi overvåkingssystemet vil beregne statusen uavhengig basert på statusen til de underordnede komponentene. Med andre ord, hvis alle oppgavene er fullført, kjører agenten vellykket.
Det er mer enn hundre oppgaver i ASMO-systemet, er det virkelig nødvendig å komme opp med unike sjekker for hver oppgave? Selvsagt vil kontrollen bli bedre hvis vi kommer med og implementerer egne spesialsjekker for hver agentoppgave, men i de fleste tilfeller er det nok å bruke universelle kontroller.
ASMO-systemet bruker kun universelle kontroller for oppgaver og dette er nok til å overvåke ytelsen til systemet.
Sjekker fremdrift
Den enkleste og mest effektive kontrollen er utførelseskontrollen. Kontrollen bekrefter at oppgaven er fullført uten feil. Alle oppgaver har denne sjekken.
Verifiseringsalgoritme
Etter hver oppgavekjøring må du sende resultatet av SUKSESS-kontrollen til overvåkingssystemet hvis oppgavekjøringen var vellykket, eller ERROR hvis utførelsen ble fullført med en feil.
Denne sjekken kan oppdage følgende problemer:
- Oppgaven kjører, men mislykkes med en feil.
- Oppgaven har sluttet å kjøre, for eksempel har den frosset.
La oss se på hvordan disse problemene løses mer detaljert.
Problem 1 – Oppgaven kjører, men mislykkes med en feil
Nedenfor er et tilfelle der oppgaven kjører, men mislykkes mellom 14:00 og 16:00.
Figuren viser at når en oppgave mislykkes, sendes et signal umiddelbart til overvåkingssystemet og statusen til den tilsvarende kontrollen i overvåkingssystemet blir alarm.
Vær oppmerksom på at i overvåkingssystemet avhenger statusen til komponenten av verifikasjonsstatusen. Alarmstatusen til sjekken vil endre alle komponenter på høyere nivå til alarm, se figuren nedenfor.
Problem 2 - Oppgaven sluttet å utføre (fryst)
Hvordan vil overvåkingssystemet forstå at en oppgave står fast?
Sjekkresultatet har en gyldighetsperiode, for eksempel 1 time. Hvis det går en time og det ikke er noe nytt testresultat, vil overvåkingssystemet sette teststatusen til alarm.
På bildet over ble lyset slått av klokken 14. Klokken 00:15 vil overvåkingssystemet oppdage at testresultatet (fra kl. 00:14) er råttent, pga. Relevanstiden er utløpt (en time), men det er ikke noe nytt resultat, og vil bytte sjekken til alarmstatus.
Klokken 16:00 ble lysene slått på igjen, programmet vil fullføre oppgaven og sende utførelsesresultatet til overvåkingssystemet, teststatusen vil igjen bli suksess.
Hvilken sjekkrelevanstid bør jeg bruke?
Relevanstiden må være større enn oppgavegjennomføringsperioden. Jeg anbefaler å sette relevanstiden 2-3 ganger lengre enn oppgaveutførelsesperioden. Dette er nødvendig for å unngå å motta falske varsler når for eksempel en oppgave tok lengre tid enn vanlig eller noen lastet programmet på nytt.
Sjekker fremdrift
ASMO-systemet har en "Load Forecast"-oppgave, som prøver å laste ned en ny prognose fra en ekstern kilde en gang i timen. Nøyaktig tidspunkt for når en ny prognose dukker opp i det eksterne systemet er ikke kjent, men det er kjent at dette skjer 2 ganger om dagen. Det viser seg at hvis det ikke kommer noe nytt værvarsel på flere timer, så er dette normalt, men hvis det ikke kommer noe nytt værvarsel på mer enn et døgn, så har noe gått i stykker et sted. For eksempel kan dataformatet i et eksternt prognosesystem endres, noe som er grunnen til at ASMO ikke vil se en ny prognoseutgivelse.
Verifiseringsalgoritme
Oppgaven sender resultatet av SUKSESS-sjekken til overvåkingssystemet når det lykkes å få fremdrift (laster ned ny værmelding). Hvis det ikke er noen fremgang eller det oppstår en feil, sendes ingenting til overvåkingssystemet.
Sjekken må ha et relevansintervall slik at den i løpet av denne tiden garantert får ny fremgang.
Vær oppmerksom på at vi vil lære om problemet med en forsinkelse, fordi overvåkingssystemet venter til gyldighetsperioden for det siste skanneresultatet utløper. Derfor trenger ikke gyldighetsperioden for sjekken gjøres for lang.
Databaseovervåking
For å kontrollere databasen i ASMO-systemet, utfører vi følgende kontroller:
- Verifiserer opprettelse av sikkerhetskopi
- Sjekker ledig diskplass
Verifiserer opprettelse av sikkerhetskopi
I de fleste applikasjoner er det viktig å ha oppdaterte databasesikkerhetskopier, slik at hvis serveren svikter, kan du distribuere programmet til en ny server.
ASMO lager en sikkerhetskopi en gang i uken og sender den til lagring. Når denne prosedyren er fullført, sendes resultatet av suksesskontrollen til overvåkingssystemet. Verifikasjonsresultatet er gyldig i 9 dager. De. For å kontrollere opprettelsen av sikkerhetskopier, brukes "fremdriftssjekk"-mekanismen, som vi diskuterte ovenfor.
Sjekker ledig diskplass
Hvis det ikke er nok ledig plass på disken, vil ikke databasen kunne fungere ordentlig, så det er viktig å kontrollere hvor mye ledig plass.
Det er praktisk å bruke metrikk for å sjekke numeriske parametere.
Beregninger er en numerisk variabel, hvis verdi overføres til overvåkingssystemet. Overvåkingssystemet sjekker terskelverdiene og beregner den metriske statusen.
Nedenfor er et bilde av hvordan "Database"-komponenten ser ut i overvåkingssystemet:
Serverovervåking
For å overvåke serveren bruker vi følgende kontroller og beregninger:
1. Frigjør diskplass
Hvis diskplassen går tom, vil ikke applikasjonen kunne fungere. Vi bruker 2 terskelverdier: det første nivået er ADVARSEL, det andre nivået er ALARM.
2. Gjennomsnittlig RAM-verdi i prosent per time
Vi bruker timegjennomsnittet fordi... vi er ikke interessert i sjeldne raser.
3. Gjennomsnittlig CPU-prosent per time
Vi bruker timegjennomsnittet fordi... vi er ikke interessert i sjeldne raser.
4. Ping-sjekk
Sjekker at serveren er online. Overvåkingssystemet kan utføre denne kontrollen, det er ikke nødvendig å skrive kode.
Nedenfor er et bilde av hvordan "Server"-komponenten ser ut i overvåkingssystemet:
Overvåking av utstyr
Jeg skal fortelle deg hvordan dataene er innhentet. For hvert veikontrollpunkt (MPC) er det en oppgave i oppgaveplanleggeren, for eksempel "Survey MPC M2 km 200". Oppgaven mottar data fra alle MPC-enheter hvert 30. minutt.
Kommunikasjonskanalproblem
Det meste av utstyret er plassert utenfor byen, et GSM-nettverk brukes til dataoverføring, som ikke fungerer stabilt (det er et nettverk, eller det er ikke et).
På grunn av hyppige nettverksfeil, så først sjekk av MPC-undersøkelsen i overvåking slik ut:
Det ble klart at dette ikke var et fungerende alternativ, fordi det var mange falske varsler om problemer. Deretter ble det besluttet å bruke en "fremdriftssjekk" for hver enhet, dvs. Kun suksesssignalet sendes til overvåkingssystemet når enheten polles uten feil. Relevanstiden ble satt til 5 timer.
Nå sender overvåking varsler om problemer bare når enheten ikke kan polles på mer enn 5 timer. Med høy grad av sannsynlighet er dette ikke falske alarmer, men reelle problemer.
Nedenfor er et bilde av hvordan utstyret ser ut i overvåkingssystemet:
Viktig!
Når GSM-nettverket slutter å fungere, blir ikke alle MDC-enheter pollet. For å redusere antall e-poster fra overvåkingssystemet, abonnerer ingeniørene våre på varsler om komponentproblemer med typen "MPC" i stedet for "Enhet". Dette lar deg motta ett varsel for hver MPC, i stedet for å motta et separat varsel for hver enhet.
Endelig ASMO overvåkingsordning
La oss sette alt sammen og se hva slags overvåkingsordning vi har.
Konklusjon
La oss oppsummere.
Hva ga overvåking av ytelsen til ASMO oss?
1. Tiden for eliminering av feil har gått ned
Vi har tidligere hørt om mangler fra brukere, men ikke alle brukere melder fra om mangler. Det hendte at vi fikk vite om en funksjonsfeil i en systemkomponent en uke etter at den dukket opp. Nå varsler overvåkingssystemet oss om problemer så snart et problem oppdages.
2. Systemstabiliteten har økt
Siden defekter begynte å bli eliminert tidligere, begynte systemet som helhet å fungere mye mer stabilt.
3. Redusere antall anrop til teknisk støtte
Mange problemer er nå fikset før brukerne i det hele tatt vet om dem. Brukere begynte å kontakte teknisk støtte sjeldnere. Alt dette har en god effekt på omdømmet vårt.
4. Økende kunde- og brukerlojalitet
Kunden la merke til positive endringer i stabiliteten til systemet. Brukere støter på færre problemer med å bruke systemet.
5. Reduser kostnader for teknisk støtte
Vi har sluttet å utføre manuelle kontroller. Nå er alle sjekker automatisert. Tidligere har vi lært om problemer fra brukere, det var ofte vanskelig å forstå hvilket problem brukeren snakket om. Nå rapporteres de fleste problemene av overvåkingssystemet; varslinger inneholder tekniske data, som alltid gjør det klart hva som gikk galt og hvor.
Viktig!
Du kan ikke installere overvåkingssystemet på den samme serveren der applikasjonene dine kjører. Hvis serveren går ned, vil applikasjonene slutte å fungere, og det vil ikke være noen som kan varsle om det.
Overvåkingssystemet må kjøres på en egen server i et annet datasenter.
Hvis du ikke ønsker å bruke en dedikert server i et nytt datasenter, kan du bruke et skyovervåkingssystem. Vårt firma bruker Zidium skyovervåkingssystem, men du kan bruke et hvilket som helst annet overvåkingssystem. Kostnaden for et skyovervåkingssystem er lavere enn å leie en ny server.
anbefalinger:
- Bryt ned applikasjoner og systemer i form av et tre med komponenter så detaljert som mulig, så det vil være praktisk å forstå hvor og hva som er ødelagt, og kontrollen blir mer fullstendig.
- For å sjekke funksjonaliteten til en komponent, bruk tester. Det er bedre å bruke mange enkle sjekker enn en kompleks.
- Konfigurer metriske terskler på siden av overvåkingssystemet, i stedet for å skrive dem i kode. Dette vil spare deg for å måtte rekompilere, rekonfigurere eller starte programmet på nytt.
- For tilpassede kontroller, bruk en margin for relevanstid for å unngå å motta falske varsler fordi noen kontroller tok litt lengre tid å fullføre enn vanlig.
- Prøv å få komponentene i overvåkingssystemet til å bli røde bare når det definitivt er et problem. Hvis de blir røde for ingenting, vil du slutte å ta hensyn til varslene til overvåkingssystemet, dets betydning vil gå tapt.
Hvis du ikke bruker et overvåkingssystem ennå, start! Det er ikke så vanskelig som det ser ut til. Få et kick av å se på det grønne ingredienstreet du dyrket selv.
Lykke til.
Kilde: www.habr.com