Hej alla!
Vårt företag är engagerat i mjukvaruutveckling och efterföljande teknisk support. Teknisk support kräver inte bara att åtgärda fel, utan även att övervaka prestandan för våra applikationer.
Till exempel, om en av tjänsterna har kraschat, måste du automatiskt registrera det här problemet och börja lösa det, och inte vänta på att missnöjda användare ska kontakta teknisk support.
Vi har ett litet företag, vi har inte resurserna att studera och underhålla några komplexa lösningar för övervakning av applikationer, vi behövde hitta en enkel och effektiv lösning.
Övervakningsstrategi
Det är inte lätt att kontrollera en applikations funktionalitet, den här uppgiften är icke-trivial, man kan till och med säga kreativ. Det är särskilt svårt att verifiera ett komplext flerlänkssystem.
Hur kan man äta en elefant? Endast i delar! Vi använder detta tillvägagångssätt för att övervaka applikationer.
Kärnan i vår övervakningsstrategi:
Dela upp din ansökan i komponenter.
Skapa kontrollkontroller för varje komponent.
En komponent anses fungerande om alla dess kontrollkontroller utförs utan fel. En applikation anses vara hälsosam om alla dess komponenter är funktionella.
Således kan vilket system som helst representeras som ett träd av komponenter. Komplexa komponenter delas upp i enklare. Enkla komponenter har kontroller.
Benchmarks är inte avsedda att utföra funktionstestning, de är inte enhetstester. Kontrollkontroller bör kontrollera hur komponenten känns i det aktuella ögonblicket, om det finns alla resurser som behövs för att den ska fungera och om det finns några problem.
Det finns inga mirakel, de flesta kontroller kommer att behöva utvecklas oberoende. Men var inte rädd, för i de flesta fall tar en kontroll 5-10 rader kod, men du kan implementera vilken logik som helst och du kommer tydligt att förstå hur kontrollen fungerar.
Övervakningssystem
Låt oss säga att vi delade upp applikationen i komponenter, kom fram till och implementerade kontroller för varje komponent, men vad ska vi göra med resultaten av dessa kontroller? Hur vet vi om någon kontroll misslyckades?
Vi kommer att behöva ett övervakningssystem. Hon kommer att utföra följande uppgifter:
- Ta emot testresultat och använd dem för att fastställa komponenternas status.
Visuellt ser det ut som att markera komponentträdet. Funktionella komponenter blir gröna, problematiska blir röda. - Utför allmänna kontroller utanför lådan.
Övervakningssystemet kan själv utföra vissa kontroller. Varför uppfinna hjulet på nytt, låt oss använda dem. Du kan till exempel kontrollera att en webbsida öppnas eller att servern plingar. - Skicka meddelanden om problem till berörda parter.
- Visualisering av övervakningsdata, tillhandahållande av rapporter, grafer och statistik.
Kort beskrivning av ASMO-systemet
Det är bäst att förklara med ett exempel. Låt oss titta på hur övervakningen av ASMO-systemets prestanda är organiserad.
ASMO är ett automatiserat meteorologiskt stödsystem. Systemet hjälper vägservicespecialister att förstå var och när det är nödvändigt att behandla vägen med avisningsmaterial. Systemet samlar in data från vägkontrollpunkter. En vägkontrollpunkt är en plats på vägen där utrustning är installerad: en väderstation, en videokamera, etc. För att förutse farliga situationer tar systemet emot väderprognoser från externa källor.
Så sammansättningen av systemet är ganska typiskt: webbplats, agent, utrustning. Låt oss börja övervaka.
Dela upp systemet i komponenter
Följande komponenter kan urskiljas i ASMO-systemet:
1. Personligt konto
Detta är en webbapplikation. Som ett minimum måste du kontrollera att applikationen är tillgänglig på Internet.
2. Databas
Databasen lagrar data som är viktiga för rapportering, och du måste se till att säkerhetskopior av databas skapas framgångsrikt.
3. Server
Med server menar vi den hårdvara som applikationer körs på. Det är nödvändigt att kontrollera statusen för HDD, RAM, CPU.
4. Agent
Detta är en Windows-tjänst som utför många olika uppgifter enligt ett schema. Som ett minimum måste du kontrollera att tjänsten körs.
5. Agentuppgift
Det räcker inte att bara veta att en agent arbetar. En agent kan arbeta, men inte utföra sina tilldelade uppgifter. Låt oss dela upp agentkomponenten i uppgifter och kontrollera om varje agentuppgift fungerar framgångsrikt.
6. Vägkontrollpunkter (behållare för alla MPC)
Det finns många vägkontrollpunkter, så låt oss kombinera alla MPC i en komponent. Detta kommer att göra det mer bekvämt att läsa övervakningsdata. När man tittar på statusen för komponenten "ASMO-system", kommer det omedelbart att vara klart var problemen finns: i applikationer, hårdvara eller i det maximala styrsystemet.
7. Vägkontrollpunkt (en maxgräns)
Vi kommer att betrakta den här komponenten som servicebar om alla enheter på denna MPC är servicebara.
8. Enhet
Detta är en videokamera eller väderstation som är installerad vid den maximala koncentrationsgränsen. Det är nödvändigt att kontrollera att enheten fungerar korrekt.
I övervakningssystemet kommer komponentträdet att se ut så här:
Övervakning av webbapplikationer
Så, vi har delat upp systemet i komponenter, nu måste vi komma med kontroller för varje komponent.
För att övervaka en webbapplikation använder vi följande kontroller:
1. Kontrollera öppningen av huvudsidan
Denna kontroll utförs av övervakningssystemet. För att utföra det anger vi sidadressen, det förväntade svarsfragmentet och den maximala exekveringstiden för begäran.
2. Kontrollera domänens betalningsdeadline
En mycket viktig kontroll. När en domän förblir obetald kan användare inte öppna webbplatsen. Att lösa problemet kan ta flera dagar, eftersom... DNS-ändringar tillämpas inte omedelbart.
3. Kontrollera SSL-certifikatet
Numera använder nästan alla webbplatser https-protokollet för åtkomst. För att protokollet ska fungera korrekt behöver du ett giltigt SSL-certifikat.
Nedan är komponenten "Personligt konto" i övervakningssystemet:
Alla kontrollerna ovan fungerar för de flesta applikationer och kräver ingen kodning. Detta är väldigt coolt eftersom du kan börja övervaka vilken webbapplikation som helst på 5 minuter. Nedan finns ytterligare kontroller som kan utföras för en webbapplikation, men deras implementering är mer komplex och applikationsspecifik, så vi kommer inte att behandla dem i den här artikeln.
Vad mer kan du kolla?
För att övervaka din webbapplikation mer fullständigt kan du utföra följande kontroller:
- Antal JavaScript-fel per period
- Antal fel på webbapplikationssidan (back-end) för perioden
- Antal misslyckade webbapplikationssvar (svarskod 404, 500, etc.)
- Genomsnittlig körningstid för frågor
Övervaka en Windows-tjänst (agent)
I ASMO-systemet spelar agenten rollen som en uppgiftsschemaläggare, som utför schemalagda uppgifter i bakgrunden.
Om alla agentuppgifter slutförs fungerar agenten korrekt. Det visar sig att för att övervaka en agent måste du övervaka dess uppgifter. Därför delar vi in "Agent"-komponenten i uppgifter. För varje uppgift kommer vi att skapa en separat komponent i övervakningssystemet, där "Agent"-komponenten kommer att vara "föräldern".
Vi delar upp Agent-komponenten i underordnade komponenter (uppgifter):
Så vi har delat upp en komplex komponent i flera enkla. Nu måste vi komma med kontroller för varje enkel komponent. Observera att den överordnade komponenten "Agent" inte kommer att ha några kontroller, eftersom övervakningssystemet kommer att beräkna sin status oberoende baserat på statusen för dess underordnade komponenter. Med andra ord, om alla uppgifter har slutförts framgångsrikt, körs agenten framgångsrikt.
Det finns mer än hundra uppgifter i ASMO-systemet, är det verkligen nödvändigt att komma med unika kontroller för varje uppgift? Självklart blir kontrollen bättre om vi kommer på och implementerar våra egna specialkontroller för varje agentuppgift, men i de flesta fall räcker det med att använda universella kontroller.
ASMO-systemet använder endast universella kontroller för uppgifter och detta är tillräckligt för att övervaka systemets prestanda.
Kontrollerar framsteg
Den enklaste och mest effektiva kontrollen är exekveringskontrollen. Kontrollen verifierar att uppgiften är klar utan fel. Alla uppgifter har denna kontroll.
Verifieringsalgoritm
Efter varje aktivitetsexekvering måste du skicka resultatet av SUCCESS-kontrollen till övervakningssystemet om aktivitetsexekveringen lyckades, eller ERROR om exekveringen slutfördes med ett fel.
Denna kontroll kan upptäcka följande problem:
- Uppgiften körs men misslyckas med ett fel.
- Uppgiften har slutat köra, till exempel har den frusit.
Låt oss titta på hur dessa problem löses mer i detalj.
Problem 1 – Uppgiften körs men misslyckas med ett fel
Nedan är ett fall där uppgiften körs men misslyckas mellan 14:00 och 16:00.
Bilden visar att när en uppgift misslyckas skickas en signal omedelbart till övervakningssystemet och statusen för motsvarande kontroll i övervakningssystemet blir larm.
Observera att i övervakningssystemet beror komponentens status på verifieringsstatusen. Kontrollens larmstatus kommer att ändra alla komponenter på högre nivå till larm, se figuren nedan.
Problem 2 - Uppgiften slutade köras (fryst)
Hur kommer övervakningssystemet att förstå att en uppgift har fastnat?
Kontrollresultatet har en giltighetstid, till exempel 1 timme. Om det går en timme och det inte finns något nytt testresultat kommer övervakningssystemet att ställa in teststatus på larm.
På bilden ovan släcktes belysningen vid 14-tiden. Klockan 00:15 kommer övervakningssystemet att upptäcka att testresultatet (från 00:14) är ruttet, p.g.a. Relevanstiden har löpt ut (en timme), men det finns inget nytt resultat och kommer att växla kontrollen till larmstatus.
Klockan 16:00 tändes lamporna igen, programmet kommer att slutföra uppgiften och skicka exekveringsresultatet till övervakningssystemet, teststatusen kommer igen att bli framgångsrik.
Vilken kontrolltid ska jag använda?
Relevanstiden måste vara längre än uppgiftens genomförandeperiod. Jag rekommenderar att du ställer in relevanstiden 2-3 gånger längre än aktivitetskörningsperioden. Detta är nödvändigt för att undvika att få falska meddelanden när till exempel en uppgift tog längre tid än vanligt eller någon laddade om programmet.
Kontrollerar framsteg
ASMO-systemet har en uppgift "Load Forecast", som försöker ladda ner en ny prognos från en extern källa en gång i timmen. Den exakta tidpunkten när en ny prognos dyker upp i det externa systemet är inte känd, men det är känt att detta händer 2 gånger om dagen. Det visar sig att om det inte kommer någon ny prognos på flera timmar så är detta normalt, men om det inte kommer någon ny prognos på mer än ett dygn så har något gått sönder någonstans. Till exempel kan dataformatet i ett externt prognossystem ändras, varför ASMO inte kommer att se en ny prognosrelease.
Verifieringsalgoritm
Uppgiften skickar resultatet av SUCCESS-kontrollen till övervakningssystemet när den lyckas få framsteg (laddar ner en ny väderprognos). Om det inte sker några framsteg eller ett fel uppstår, skickas ingenting till övervakningssystemet.
Kontrollen måste ha ett relevansintervall så att den under denna tid garanterat får nya framsteg.
Observera att vi kommer att lära oss om problemet med en fördröjning, eftersom övervakningssystemet väntar tills giltighetstiden för det senaste skanningsresultatet löper ut. Därför behöver inte kontrollens giltighetstid göras för lång.
Databasövervakning
För att kontrollera databasen i ASMO-systemet utför vi följande kontroller:
- Verifierar skapande av säkerhetskopia
- Kontrollerar ledigt diskutrymme
Verifierar skapande av säkerhetskopia
I de flesta applikationer är det viktigt att ha uppdaterade databasbackuper så att om servern misslyckas kan du distribuera programmet till en ny server.
ASMO skapar en säkerhetskopia en gång i veckan och skickar den till lagring. När denna procedur har slutförts framgångsrikt skickas resultatet av framgångskontrollen till övervakningssystemet. Verifieringsresultatet är giltigt i 9 dagar. De där. För att kontrollera skapandet av säkerhetskopior används mekanismen "förloppskontroll", som vi diskuterade ovan.
Kontrollerar ledigt diskutrymme
Om det inte finns tillräckligt med ledigt utrymme på disken kommer databasen inte att kunna fungera korrekt, så det är viktigt att kontrollera mängden ledigt utrymme.
Det är bekvämt att använda mått för att kontrollera numeriska parametrar.
Metrik är en numerisk variabel, vars värde överförs till övervakningssystemet. Övervakningssystemet kontrollerar tröskelvärdena och beräknar metrisk status.
Nedan är en bild på hur "Databas"-komponenten ser ut i övervakningssystemet:
Serverövervakning
För att övervaka servern använder vi följande kontroller och mätvärden:
1. Frigör diskutrymme
Om diskutrymmet tar slut kommer programmet inte att fungera. Vi använder 2 tröskelvärden: den första nivån är VARNING, den andra nivån är ALARM.
2. Genomsnittligt RAM-värde i procent per timme
Vi använder timgenomsnittet eftersom... vi är inte intresserade av sällsynta raser.
3. Genomsnittlig CPU-procent per timme
Vi använder timgenomsnittet eftersom... vi är inte intresserade av sällsynta raser.
4. Pingcheck
Kontrollerar att servern är online. Övervakningssystemet kan utföra denna kontroll, det finns ingen anledning att skriva kod.
Nedan är en bild på hur "Server"-komponenten ser ut i övervakningssystemet:
Utrustningsövervakning
Jag ska berätta hur uppgifterna erhålls. För varje vägkontrollpunkt (MPC) finns en uppgift i uppgiftsplaneraren, till exempel ”Survey MPC M2 km 200”. Uppgiften tar emot data från alla MPC-enheter var 30:e minut.
Kommunikationskanalproblem
Det mesta av utrustningen är placerad utanför staden, ett GSM-nät används för dataöverföring, vilket inte fungerar stabilt (det finns ett nätverk, eller det finns inget).
På grund av frekventa nätverksfel såg till en början en kontroll av MPC-undersökningen i övervakning ut så här:
Det blev tydligt att detta inte var ett fungerande alternativ, eftersom det fanns många falska meddelanden om problem. Då beslutades att använda en ”förloppskontroll” för varje enhet, d.v.s. Endast framgångssignalen skickas till övervakningssystemet när enheten pollas utan fel. Relevanstiden sattes till 5 timmar.
Nu skickar övervakning meddelanden om problem endast när enheten inte kan pollas på mer än 5 timmar. Med en hög grad av sannolikhet är det inga falska larm, utan verkliga problem.
Nedan är en bild på hur utrustningen ser ut i övervakningssystemet:
Viktigt!
När GSM-nätverket slutar fungera pollas inte alla MDC-enheter. För att minska antalet e-postmeddelanden från övervakningssystemet prenumererar våra ingenjörer på meddelanden om komponentproblem med typen "MPC" snarare än "Enhet". Detta gör att du kan få ett meddelande för varje MPC, istället för att få ett separat meddelande för varje enhet.
Slutligt ASMO-övervakningsschema
Låt oss sätta ihop allt och se vilken typ av övervakningssystem vi har.
Slutsats
Låt oss sammanfatta.
Vad gav övervakningen av ASMOs prestanda oss?
1. Tiden för eliminering av defekter har minskat
Vi har tidigare hört talas om fel från användare, men alla användare rapporterar inte om fel. Det hände att vi fick reda på ett fel på en systemkomponent en vecka efter att den dök upp. Nu meddelar övervakningssystemet oss om problem så snart ett problem upptäcks.
2. Systemstabiliteten har ökat
Eftersom defekter började elimineras tidigare började systemet som helhet att fungera mycket mer stabilt.
3. Minska antalet samtal till teknisk support
Många problem är nu åtgärdade innan användarna ens vet om dem. Användare började kontakta teknisk support mer sällan. Allt detta har en bra effekt på vårt rykte.
4. Öka kund- och användarlojalitet
Kunden märkte positiva förändringar i systemets stabilitet. Användare stöter på färre problem med att använda systemet.
5. Minska kostnaderna för teknisk support
Vi har slutat utföra några manuella kontroller. Nu är alla kontroller automatiserade. Tidigare har vi lärt oss om problem från användare, det var ofta svårt att förstå vilket problem användaren pratade om. Nu rapporteras de flesta problem av övervakningssystemet, aviseringar innehåller tekniska data som alltid gör det tydligt vad som gick fel och var.
Viktigt!
Du kan inte installera övervakningssystemet på samma server där dina applikationer körs. Om servern går ner kommer applikationer att sluta fungera och det kommer ingen att meddela om det.
Övervakningssystemet måste köras på en separat server i ett annat datacenter.
Om du inte vill använda en dedikerad server i ett nytt datacenter kan du använda ett molnövervakningssystem. Vårt företag använder Zidium molnövervakningssystem, men du kan använda vilket annat övervakningssystem som helst. Kostnaden för ett molnövervakningssystem är lägre än att hyra en ny server.
Rekommendationer:
- Bryt ner applikationer och system i form av ett träd av komponenter så detaljerat som möjligt, så att det blir bekvämt att förstå var och vad som är trasigt, och kontrollen blir mer komplett.
- För att kontrollera funktionaliteten hos en komponent, använd tester. Det är bättre att använda många enkla kontroller än en komplex.
- Konfigurera metriska trösklar på sidan av övervakningssystemet, istället för att skriva dem i kod. Detta kommer att spara dig från att behöva kompilera om, konfigurera om eller starta om programmet.
- För anpassade kontroller, använd en relevanstid för att undvika att få falska meddelanden eftersom vissa kontroller tog lite längre tid att slutföra än vanligt.
- Försök att få komponenterna i övervakningssystemet att bli röda endast när det definitivt finns ett problem. Om de blir röda för ingenting, kommer du att sluta uppmärksamma övervakningssystemets meddelanden, dess betydelse kommer att gå förlorad.
Om du inte använder ett övervakningssystem ännu, börja! Det är inte så svårt som det verkar. Få en kick av att titta på trädet med gröna ingredienser som du själv odlat.
Lycka till.
Källa: will.com