Hallo iedereen!
Ons bedrijf houdt zich bezig met softwareontwikkeling en daaropvolgende technische ondersteuning. Technische ondersteuning vereist niet alleen het oplossen van fouten, maar ook het monitoren van de prestaties van onze applicaties.
Als een van de services bijvoorbeeld is gecrasht, moet u dit probleem automatisch registreren en beginnen met het oplossen ervan, en niet wachten tot ontevreden gebruikers contact opnemen met de technische ondersteuning.
We hebben een klein bedrijf, we hebben niet de middelen om complexe oplossingen voor monitoringtoepassingen te bestuderen en te onderhouden, we moesten een eenvoudige en effectieve oplossing vinden.
Monitoringstrategie
Het is niet eenvoudig om de functionaliteit van een applicatie te controleren; deze taak is niet triviaal, je zou zelfs creatief kunnen zeggen. Het is vooral moeilijk om een complex multi-linksysteem te verifiëren.
Hoe kun je een olifant eten? Alleen in delen! Deze aanpak gebruiken wij om applicaties te monitoren.
De essentie van onze monitoringstrategie:
Deel uw applicatie op in componenten.
Maak controlecontroles voor elk onderdeel.
Een component wordt als operationeel beschouwd als alle controlecontroles foutloos zijn uitgevoerd. Een applicatie wordt als gezond beschouwd als alle componenten ervan functioneel zijn.
Elk systeem kan dus worden weergegeven als een boom van componenten. Complexe componenten worden opgesplitst in eenvoudigere componenten. Eenvoudige componenten hebben controles.
Benchmarks zijn niet bedoeld om functionele tests uit te voeren, het zijn geen unit-tests. Controlecontroles moeten controleren hoe het onderdeel op het huidige moment aanvoelt, of alle middelen aanwezig zijn die nodig zijn voor het functioneren ervan en of er problemen zijn.
Er zijn geen wonderen; de meeste controles zullen onafhankelijk moeten worden ontwikkeld. Maar wees niet bang, want in de meeste gevallen duurt één controle 5-10 regels code, maar u kunt elke logica implementeren en u zult duidelijk begrijpen hoe de controle werkt.
Controlesysteem
Laten we zeggen dat we de applicatie in componenten hebben gesplitst en voor elk onderdeel controles hebben bedacht en geïmplementeerd, maar wat moeten we doen met de resultaten van deze controles? Hoe weten we of een controle is mislukt?
We hebben een monitoringsysteem nodig. Zij zal de volgende taken uitvoeren:
- Ontvang testresultaten en gebruik deze om de status van componenten te bepalen.
Visueel lijkt dit op het markeren van de componentenboom. Functionele componenten worden groen, problematische componenten worden rood. - Voer standaard algemene controles uit.
Het monitoringsysteem kan een aantal controles zelf uitvoeren. Waarom het wiel opnieuw uitvinden, laten we ze gebruiken. U kunt bijvoorbeeld controleren of een websitepagina wordt geopend of dat de server pingt. - Stuur meldingen van problemen naar geïnteresseerde partijen.
- Visualisatie van monitoringgegevens, verstrekken van rapporten, grafieken en statistieken.
Korte beschrijving van het ASMO-systeem
Het is het beste om uit te leggen met een voorbeeld. Laten we eens kijken hoe de monitoring van de prestaties van het ASMO-systeem is georganiseerd.
ASMO is een geautomatiseerd meteorologisch ondersteuningssysteem. Het systeem helpt wegenonderhoudsspecialisten te begrijpen waar en wanneer het nodig is om de weg te behandelen met ontdooimiddelen. Het systeem verzamelt gegevens van wegcontrolepunten. Een wegcontrolepunt is een plaats op de weg waar apparatuur is geïnstalleerd: een weerstation, een videocamera, enz. Om gevaarlijke situaties te voorspellen ontvangt het systeem weersvoorspellingen van externe bronnen.
De samenstelling van het systeem is dus vrij typisch: website, agent, apparatuur. Laten we beginnen met monitoren.
Het systeem opdelen in componenten
In het ASMO-systeem kunnen de volgende componenten worden onderscheiden:
1. Persoonlijk account
Dit is een webapplicatie. U moet in ieder geval controleren of de applicatie beschikbaar is op internet.
2. Gegevensbestand
In de database worden gegevens opgeslagen die belangrijk zijn voor de rapportage, en u moet ervoor zorgen dat databaseback-ups met succes worden gemaakt.
3. Serveerster
Met server bedoelen we de hardware waarop applicaties draaien. Het is noodzakelijk om de status van HDD, RAM, CPU te controleren.
4. Agent
Dit is een Windows-service die volgens een schema veel verschillende taken uitvoert. U moet op zijn minst controleren of de service actief is.
5. Agenttaak
Alleen weten dat er een agent aan het werk is, is niet voldoende. Een agent kan werken, maar de toegewezen taken niet uitvoeren. Laten we de agentcomponent opsplitsen in taken en controleren of elke agenttaak succesvol werkt.
6. Wegcontrolepunten (container van alle MPC’s)
Er zijn veel wegcontrolepunten, dus laten we alle MPC’s in één component combineren. Dit maakt het gemakkelijker om monitoringgegevens te lezen. Wanneer je de status van het “ASMO-systeem”-onderdeel bekijkt, wordt meteen duidelijk waar de problemen zitten: in applicaties, hardware of in het maximale besturingssysteem.
7. Wegcontrolepunt (één maximumlimiet)
We beschouwen dit onderdeel als bruikbaar als alle apparaten op deze MPC bruikbaar zijn.
8. Apparaat
Dit is een videocamera of weerstation dat op de maximale concentratielimiet is geïnstalleerd. Het is noodzakelijk om te controleren of het apparaat goed werkt.
In het monitoringsysteem ziet de componentenboom er als volgt uit:
Monitoring van webapplicaties
We hebben het systeem dus in componenten verdeeld, nu moeten we voor elk onderdeel controles bedenken.
Om een webapplicatie te monitoren gebruiken wij de volgende controles:
1. De opening van de hoofdpagina controleren
Deze controle wordt uitgevoerd door het monitoringsysteem. Om het uit te voeren, geven we het paginaadres, het verwachte antwoordfragment en de maximale uitvoeringstijd van het verzoek aan.
2. Controleren van de betalingstermijn voor het domein
Een heel belangrijke controle. Wanneer een domein onbetaald blijft, kunnen gebruikers de site niet openen. Het oplossen van het probleem kan enkele dagen duren, omdat... DNS-wijzigingen worden niet onmiddellijk toegepast.
3. Controle van het SSL-certificaat
Tegenwoordig gebruiken bijna alle websites het https-protocol voor toegang. Om het protocol correct te laten werken, heeft u een geldig SSL-certificaat nodig.
Hieronder vindt u het onderdeel “Persoonlijk account” in het monitoringsysteem:
Alle bovenstaande controles werken voor de meeste toepassingen en vereisen geen codering. Dit is erg gaaf omdat je binnen 5 minuten kunt beginnen met het monitoren van elke webapplicatie. Hieronder staan aanvullende controles die kunnen worden uitgevoerd voor een webapplicatie, maar de implementatie ervan is complexer en applicatiespecifiek, daarom zullen we deze in dit artikel niet behandelen.
Wat kun je nog meer controleren?
Om uw webapplicatie beter te monitoren, kunt u de volgende controles uitvoeren:
- Aantal JavaScript-fouten per periode
- Aantal fouten aan de webapplicatiezijde (back-end) voor de periode
- Aantal mislukte webapplicatiereacties (antwoordcode 404, 500, etc.)
- Gemiddelde uitvoeringstijd van query's
Een Windows-service monitoren (agent)
In het ASMO-systeem speelt de agent de rol van een taakplanner, die geplande taken op de achtergrond uitvoert.
Als alle agenttaken met succes zijn voltooid, werkt de agent correct. Het blijkt dat als je een agent wilt monitoren, je zijn taken moet monitoren. Daarom verdelen we de component “Agent” in taken. Voor elke taak zullen we een aparte component in het monitoringsysteem creëren, waarbij de component “Agent” de “ouder” zal zijn.
We splitsen de Agent-component op in onderliggende componenten (taken):
Daarom hebben we een complex onderdeel opgesplitst in verschillende eenvoudige onderdelen. Nu moeten we controles bedenken voor elk eenvoudig onderdeel. Houd er rekening mee dat de bovenliggende component “Agent” geen controles zal ondergaan, omdat het monitoringsysteem zijn status onafhankelijk zal berekenen op basis van de status van de onderliggende componenten. Met andere woorden: als alle taken met succes zijn voltooid, wordt de agent met succes uitgevoerd.
Er zijn meer dan honderd taken in het ASMO-systeem. Is het echt nodig om voor elke taak unieke controles te bedenken? Natuurlijk zal de controle beter zijn als we onze eigen speciale controles voor elke agenttaak bedenken en implementeren, maar in de meeste gevallen is het voldoende om universele controles te gebruiken.
Het ASMO-systeem gebruikt alleen universele controles voor taken en dit is voldoende om de prestaties van het systeem te monitoren.
Het controleren van de voortgang
De eenvoudigste en meest effectieve controle is de uitvoeringscontrole. De controle verifieert dat de taak zonder fouten is voltooid. Alle taken hebben deze controle.
Verificatie-algoritme
Na elke taakuitvoering moet u het resultaat van de SUCCESS-controle naar het monitoringsysteem sturen als de taakuitvoering succesvol was, of ERROR als de uitvoering met een fout werd voltooid.
Met deze controle kunnen de volgende problemen worden gedetecteerd:
- De taak wordt uitgevoerd, maar mislukt vanwege een fout.
- De taak is gestopt met uitvoeren en is bijvoorbeeld vastgelopen.
Laten we eens kijken hoe deze problemen in meer detail worden opgelost.
Probleem 1 – De taak wordt uitgevoerd maar mislukt vanwege een fout
Hieronder ziet u een geval waarin de taak wordt uitgevoerd, maar mislukt tussen 14:00 en 16:00 uur.
De figuur laat zien dat wanneer een taak mislukt, er onmiddellijk een signaal naar het monitoringsysteem wordt gestuurd en de status van de bijbehorende controle in het monitoringsysteem alarm wordt.
Houd er rekening mee dat in het monitoringsysteem de status van het onderdeel afhankelijk is van de verificatiestatus. De alarmstatus van de controle zorgt ervoor dat alle componenten op een hoger niveau in alarm gaan, zie onderstaande afbeelding.
Probleem 2 - De uitvoering van de taak is gestopt (bevroren)
Hoe begrijpt het monitoringsysteem dat een taak vastzit?
Het controleresultaat heeft een geldigheidsduur van bijvoorbeeld 1 uur. Als er een uur verstrijkt en er geen nieuw testresultaat is, zal het monitoringsysteem de teststatus op alarm zetten.
Op de foto hierboven gingen de lichten om 14 uur uit. Om 00 uur zal het monitoringsysteem detecteren dat de testuitslag (vanaf 15 uur) rot is, omdat De relevantietijd is verstreken (één uur), maar er is geen nieuw resultaat en de controle wordt overgeschakeld naar de alarmstatus.
Om 16 uur gingen de lichten weer aan, het programma voltooit de taak en stuurt het uitvoeringsresultaat naar het monitoringsysteem, de teststatus wordt opnieuw succesvol.
Welke controlerelevantietijd moet ik gebruiken?
De relevantietijd moet groter zijn dan de taakuitvoeringsperiode. Ik raad aan om de relevantietijd 2-3 keer langer in te stellen dan de taakuitvoeringsperiode. Dit is nodig om te voorkomen dat je valse meldingen ontvangt wanneer bijvoorbeeld een taak langer duurde dan normaal of iemand het programma opnieuw laadde.
Het controleren van de voortgang
Het ASMO-systeem heeft een taak “Load Forecast”, die probeert één keer per uur een nieuwe voorspelling van een externe bron te downloaden. Het exacte tijdstip waarop een nieuwe voorspelling in het externe systeem verschijnt is niet bekend, maar wel is bekend dat dit 2 keer per dag gebeurt. Het blijkt dat als er gedurende enkele uren geen nieuwe voorspelling is, dit normaal is, maar als er langer dan een dag geen nieuwe voorspelling is, dan is er ergens iets kapot. Het gegevensformaat in een extern prognosesysteem kan bijvoorbeeld veranderen. Daarom zal ASMO geen nieuwe prognosevrijgave zien.
Verificatie-algoritme
De taak stuurt het resultaat van de SUCCES-controle naar het monitoringsysteem wanneer het erin slaagt voortgang te boeken (het downloaden van een nieuwe weersvoorspelling). Als er geen voortgang is of er een fout optreedt, wordt er niets naar het monitoringsysteem gestuurd.
De controle moet een zodanig relevantie-interval hebben dat gedurende deze tijd gegarandeerd nieuwe voortgang wordt geboekt.
Houd er rekening mee dat we het probleem met vertraging zullen leren kennen, omdat het monitoringsysteem wacht tot de geldigheidsperiode van het laatste scanresultaat is verstreken. Daarom hoeft de geldigheidsduur van de cheque niet te lang te worden gemaakt.
Databasebewaking
Om de database in het ASMO-systeem te controleren, voeren we de volgende controles uit:
- Het verifiëren van het maken van back-ups
- Vrije schijfruimte controleren
Het verifiëren van het maken van back-ups
In de meeste toepassingen is het belangrijk om up-to-date databaseback-ups te hebben, zodat u het programma op een nieuwe server kunt implementeren als de server uitvalt.
ASMO maakt één keer per week een reservekopie en stuurt deze naar de opslag. Wanneer deze procedure succesvol is afgerond, wordt het resultaat van de succescontrole naar het monitoringsysteem verzonden. Het verificatieresultaat is 9 dagen geldig. Die. Om het maken van back-ups te controleren, wordt het ‘voortgangscontrole’-mechanisme gebruikt, dat we hierboven hebben besproken.
Vrije schijfruimte controleren
Als er niet voldoende vrije ruimte op de schijf is, zal de database niet goed kunnen functioneren. Het is dus belangrijk om de hoeveelheid vrije ruimte te controleren.
Het is handig om metrieken te gebruiken om numerieke parameters te controleren.
Metrische gegevens is een numerieke variabele waarvan de waarde naar het monitoringsysteem wordt verzonden. Het monitoringsysteem controleert de drempelwaarden en berekent de metrische status.
Hieronder ziet u een afbeelding van hoe de component “Database” eruit ziet in het monitoringsysteem:
Serverbewaking
Om de server te monitoren gebruiken we de volgende controles en statistieken:
1. Vrije schijfruimte
Als er geen schijfruimte meer is, kan de applicatie niet werken. We hanteren 2 drempelwaarden: het eerste niveau is WAARSCHUWING, het tweede niveau is ALARM.
2. Gemiddelde RAM-waarde in procenten per uur
Wij hanteren het uurgemiddelde omdat... we zijn niet geïnteresseerd in zeldzame rassen.
3. Gemiddeld CPU-percentage per uur
Wij hanteren het uurgemiddelde omdat... we zijn niet geïnteresseerd in zeldzame rassen.
4. Pingcontrole
Controleert of de server online is. Het monitoringsysteem kan deze controle uitvoeren; er hoeft geen code te worden geschreven.
Hieronder ziet u een afbeelding van hoe de component “Server” eruit ziet in het monitoringsysteem:
Bewaking van apparatuur
Ik zal je vertellen hoe de gegevens worden verkregen. Voor ieder wegcontrolepunt (MPC) staat er een taak in de taakplanner, bijvoorbeeld “Onderzoek MPC M2 km 200”. De taak ontvangt elke 30 minuten gegevens van alle MPC-apparaten.
Communicatiekanaalprobleem
De meeste apparatuur bevindt zich buiten de stad; voor de datatransmissie wordt een GSM-netwerk gebruikt, dat niet stabiel werkt (er is een netwerk, of er is er geen).
Vanwege frequente netwerkstoringen zag het controleren van de MPC-enquête in de monitoring er in eerste instantie als volgt uit:
Het werd duidelijk dat dit geen werkende optie was, omdat er veel valse meldingen waren over problemen. Vervolgens werd besloten om voor elk apparaat een ‘voortgangscontrole’ te gebruiken, d.w.z. Alleen het successignaal wordt naar het monitoringsysteem verzonden wanneer het apparaat zonder fout wordt ondervraagd. De relevantietijd werd ingesteld op 5 uur.
Monitoring verzendt nu alleen meldingen over problemen als het apparaat langer dan 5 uur niet kan worden ondervraagd. Met een hoge mate van waarschijnlijkheid zijn dit geen valse alarmen, maar echte problemen.
Hieronder ziet u een afbeelding van hoe de apparatuur er in het monitoringsysteem uitziet:
Belangrijk!
Wanneer het GSM-netwerk niet meer werkt, worden niet alle MDC-apparaten ondervraagd. Om het aantal e-mails van het monitoringsysteem te verminderen, abonneren onze technici zich op meldingen over componentproblemen met het type “MPC” in plaats van “Apparaat”. Hierdoor kunt u per MPC één melding ontvangen, in plaats van dat u voor ieder apparaat een aparte melding ontvangt.
Laatste ASMO-monitoringschema
Laten we alles samenvoegen en kijken wat voor soort monitoringsysteem we hebben.
Conclusie
Laten we het samenvatten.
Wat heeft het monitoren van de prestaties van ASMO ons opgeleverd?
1. De tijd voor het elimineren van defecten is korter geworden
We hebben eerder gehoord over gebreken van gebruikers, maar niet alle gebruikers melden gebreken. Het gebeurde dat we een week na het verschijnen hoorden van een storing in een systeemcomponent. Nu brengt het monitoringsysteem ons op de hoogte van problemen zodra er een probleem wordt gedetecteerd.
2. De systeemstabiliteit is toegenomen
Omdat defecten eerder begonnen te worden geëlimineerd, begon het systeem als geheel veel stabieler te werken.
3. Het aantal oproepen naar technische ondersteuning verminderen
Veel problemen zijn nu opgelost voordat gebruikers er zelfs maar van op de hoogte zijn. Gebruikers begonnen minder vaak contact op te nemen met technische ondersteuning. Dit alles heeft een goed effect op onze reputatie.
4. Het vergroten van de loyaliteit van klanten en gebruikers
De klant merkte positieve veranderingen op in de stabiliteit van het systeem. Gebruikers ondervinden minder problemen bij het gebruik van het systeem.
5. Verlaag de kosten voor technische ondersteuning
We zijn gestopt met het uitvoeren van handmatige controles. Nu zijn alle controles geautomatiseerd. Voorheen leerden we over problemen van gebruikers; het was vaak moeilijk om te begrijpen over welk probleem de gebruiker het had. Nu worden de meeste problemen gemeld door het monitoringsysteem; meldingen bevatten technische gegevens, waardoor altijd duidelijk wordt wat er mis is gegaan en waar.
Belangrijk!
U kunt het monitoringsysteem niet installeren op dezelfde server waarop uw applicaties draaien. Als de server uitvalt, werken applicaties niet meer en is er niemand die hiervan op de hoogte kan worden gesteld.
Het monitoringsysteem moet op een aparte server in een ander datacenter draaien.
Als u geen dedicated server in een nieuw datacenter wilt gebruiken, kunt u een cloudmonitoringsysteem gebruiken. Ons bedrijf maakt gebruik van het Zidium-cloudmonitoringsysteem, maar u kunt elk ander monitoringsysteem gebruiken. De kosten van een cloudmonitoringsysteem zijn lager dan het huren van een nieuwe server.
Aanbevelingen:
- Breek applicaties en systemen zo gedetailleerd mogelijk op in de vorm van een boom met componenten, zodat het handig is om te begrijpen waar en wat kapot is, en de controle vollediger zal zijn.
- Gebruik tests om de functionaliteit van een component te controleren. Het is beter om veel eenvoudige controles te gebruiken dan één complexe controle.
- Configureer metrische drempels aan de zijkant van het monitoringsysteem, in plaats van ze in code te schrijven. Hierdoor hoeft u de toepassing niet opnieuw te compileren, te configureren of opnieuw te starten.
- Gebruik voor aangepaste controles een marge van relevantietijd om te voorkomen dat u valse meldingen ontvangt, omdat het voltooien van sommige controles iets langer duurde dan normaal.
- Probeer de componenten in het monitoringsysteem alleen rood te laten branden als er absoluut een probleem is. Als ze voor niets rood worden, let je niet meer op de meldingen van het monitoringsysteem, de betekenis ervan gaat verloren.
Als u nog geen monitoringsysteem gebruikt, begin dan! Het is niet zo moeilijk als het lijkt. Krijg een kick van het kijken naar de groene ingrediëntenboom die je zelf hebt gekweekt.
Good luck.
Bron: www.habr.com