Hallo almal!
Ons maatskappy is besig met sagteware-ontwikkeling en daaropvolgende tegniese ondersteuning. Tegniese ondersteuning vereis nie net die regstelling van foute nie, maar die monitering van die werkverrigting van ons toepassings.
Byvoorbeeld, as een van die dienste ineengestort het, moet u hierdie probleem outomaties opneem en begin om dit op te los, en nie wag vir ontevrede gebruikers om tegniese ondersteuning te kontak nie.
Ons het 'n klein maatskappy, ons het nie die hulpbronne om enige komplekse oplossings vir die monitering van toepassings te bestudeer en in stand te hou nie, ons moes 'n eenvoudige en effektiewe oplossing vind.
Moniteringstrategie
Dit is nie maklik om die funksionaliteit van 'n toepassing na te gaan nie; hierdie taak is nie-triviaal, mens kan selfs sê kreatief. Dit is veral moeilik om 'n komplekse multiskakelstelsel te verifieer.
Hoe kan jy 'n olifant eet? Slegs in dele! Ons gebruik hierdie benadering om toepassings te monitor.
Die kern van ons moniteringstrategie:
Breek jou aansoek af in komponente.
Skep beheerkontroles vir elke komponent.
'n Komponent word as operasioneel beskou as al sy beheerkontroles sonder foute uitgevoer word. 'n Toediening word as gesond beskou as al sy komponente funksioneel is.
Dus kan enige stelsel as 'n boom van komponente voorgestel word. Komplekse komponente word in eenvoudiger afgebreek. Eenvoudige komponente het tjeks.
Maatstawwe is nie bedoel om funksionele toetse uit te voer nie, dit is nie eenheidstoetse nie. Kontrolekontroles moet kyk hoe die komponent op die huidige oomblik in tyd voel, of daar al die hulpbronne is wat nodig is vir sy funksionering, en of daar enige probleme is.
Daar is geen wonderwerke nie; die meeste tjeks sal onafhanklik ontwikkel moet word. Maar moenie bang wees nie, want in die meeste gevalle neem een tjek 5-10 reëls kode, maar jy kan enige logika implementeer en jy sal duidelik verstaan hoe die tjek werk.
Moniteringstelsel
Kom ons sê ons verdeel die toepassing in komponente, het vorendag gekom en tjeks vir elke komponent geïmplementeer, maar wat om te doen met die resultate van hierdie tjeks? Hoe weet ons of een of ander tjek misluk het?
Ons sal 'n moniteringstelsel nodig hê. Sy sal die volgende take verrig:
- Ontvang toetsresultate en gebruik dit om die status van komponente te bepaal.
Visueel lyk dit soos om die komponentboom uit te lig. Funksionele komponente word groen, problematiese word rooi. - Voer algemene kontroles uit die boks uit.
Die moniteringstelsel kan self sekere kontroles uitvoer. Waarom die wiel herontdek, kom ons gebruik dit. Byvoorbeeld, jy kan seker maak dat 'n webwerf-bladsy oopmaak of die bediener ping. - Stuur kennisgewings van probleme aan belangstellendes.
- Visualisering van moniteringsdata, verskaffing van verslae, grafieke en statistieke.
Kort beskrywing van die ASMO-stelsel
Dit is die beste om met 'n voorbeeld te verduidelik. Kom ons kyk hoe monitering van die werkverrigting van die ASMO-stelsel georganiseer word.
ASMO is 'n outomatiese meteorologiese ondersteuningstelsel. Die stelsel help paddiensspesialiste om te verstaan waar en wanneer dit nodig is om die pad met ontdooiingsmateriaal te behandel. Die stelsel samel data van padbeheerpunte in. 'n Padbeheerpunt is 'n plek op die pad waar toerusting geïnstalleer is: 'n weerstasie, 'n videokamera, ens. Om gevaarlike situasies te voorspel, ontvang die stelsel weervoorspellings van eksterne bronne.
Dus, die samestelling van die stelsel is nogal tipies: webwerf, agent, toerusting. Kom ons begin monitering.
Die opbreek van die stelsel in komponente
Die volgende komponente kan in die ASMO-stelsel onderskei word:
1. Persoonlike rekening
Dit is 'n webtoepassing. U moet ten minste seker maak dat die toepassing op die internet beskikbaar is.
2. Databasis
Die databasis stoor data wat belangrik is vir verslagdoening, en jy moet verseker dat databasisrugsteun suksesvol geskep word.
3. Bediener
Met bediener bedoel ons die hardeware waarop toepassings loop. Dit is nodig om die status van HDD, RAM, CPU na te gaan.
4. Agent
Dit is 'n Windows-diens wat baie verskillende take op 'n skedule verrig. U moet ten minste seker maak dat die diens aan die gang is.
5. Agenttaak
Om net te weet dat 'n agent werk, is nie genoeg nie. 'n Agent kan werk, maar nie sy opgedra take verrig nie. Kom ons verdeel die agentkomponent in take en kyk of elke agenttaak suksesvol werk.
6. Padbeheerpunte (houer van alle MBK'e)
Daar is baie padbeheerpunte, so kom ons kombineer alle MBK's in een komponent. Dit sal dit geriefliker maak om moniteringsdata te lees. Wanneer die status van die “ASMO-stelsel”-komponent bekyk word, sal dit onmiddellik duidelik wees waar die probleme is: in toepassings, hardeware of in die maksimum beheerstelsel.
7. Padbeheerpunt (een maksimum limiet)
Ons sal hierdie komponent as diensbaar beskou as alle toestelle op hierdie MBK diensbaar is.
8. Toestel
Dit is 'n videokamera of weerstasie wat by die maksimum konsentrasielimiet geïnstalleer is. Dit is nodig om seker te maak dat die toestel behoorlik werk.
In die moniteringstelsel sal die komponentboom soos volg lyk:
Webtoepassingsmonitering
So, ons het die stelsel in komponente verdeel, nou moet ons met tjeks vir elke komponent vorendag kom.
Om 'n webtoepassing te monitor, gebruik ons die volgende kontroles:
1. Kontroleer die opening van die hoofblad
Hierdie kontrole word deur die moniteringstelsel uitgevoer. Om dit uit te voer, dui ons die bladsyadres, die verwagte reaksiefragment en die maksimum versoekuitvoeringstyd aan.
2. Kontroleer die sperdatum vir domeinbetaling
'n Baie belangrike tjek. Wanneer 'n domein onbetaald bly, kan gebruikers nie die webwerf oopmaak nie. Die oplossing van die probleem kan 'n paar dae neem, want... DNS-veranderinge word nie onmiddellik toegepas nie.
3. Kontroleer die SSL-sertifikaat
Deesdae gebruik byna alle webwerwe die https-protokol vir toegang. Vir die protokol om korrek te werk, benodig jy 'n geldige SSL-sertifikaat.
Hieronder is die "Persoonlike Rekening"-komponent in die moniteringstelsel:
Al die kontroles hierbo sal vir die meeste toepassings werk en vereis geen kodering nie. Dit is baie gaaf, want jy kan enige webtoepassing binne 5 minute begin monitor. Hieronder is bykomende kontrole wat vir 'n webtoepassing uitgevoer kan word, maar die implementering daarvan is meer kompleks en toepassingspesifiek, so ons sal dit nie in hierdie artikel dek nie.
Wat anders kan jy nagaan?
Om u webtoepassing meer volledig te monitor, kan u die volgende kontrole uitvoer:
- Aantal JavaScript-foute per periode
- Aantal foute aan die webtoepassingskant (agterkant) vir die tydperk
- Aantal onsuksesvolle webtoepassing-antwoorde (antwoordkode 404, 500, ens.)
- Gemiddelde navraaguitvoeringstyd
Monitering van 'n Windows-diens (agent)
In die ASMO-stelsel speel die agent die rol van 'n taakskeduleerder, wat geskeduleerde take op die agtergrond uitvoer.
As alle agenttake suksesvol voltooi word, werk die agent behoorlik. Dit blyk dat jy sy take moet monitor om 'n agent te monitor. Daarom verdeel ons die "Agent"-komponent in take. Vir elke taak sal ons 'n aparte komponent in die moniteringstelsel skep, waar die "Agent"-komponent die "ouer" sal wees.
Ons verdeel die Agent-komponent in kinderkomponente (take):
Dus, ons het 'n komplekse komponent in verskeie eenvoudiges opgebreek. Nou moet ons met tjeks vir elke eenvoudige komponent vorendag kom. Neem asseblief kennis dat die ouerkomponent "Agent" geen kontrole sal hê nie, want die moniteringstelsel sal sy status onafhanklik bereken op grond van die status van sy kinderkomponente. Met ander woorde, as alle take suksesvol afgehandel is, dan loop die agent suksesvol.
Daar is meer as honderd take in die ASMO-stelsel, is dit regtig nodig om met unieke tjeks vir elke taak vorendag te kom? Beheer sal natuurlik beter wees as ons ons eie spesiale tjeks vir elke agenttaak uitdink en implementeer, maar in die meeste gevalle is dit genoeg om universele tjeks te gebruik.
Die ASMO-stelsel gebruik slegs universele kontroles vir take en dit is genoeg om die werkverrigting van die stelsel te monitor.
Gaan vordering na
Die eenvoudigste en doeltreffendste tjek is die uitvoering tjek. Die kontrole verifieer dat die taak sonder foute voltooi is. Alle take het hierdie tjek.
Kontroleer algoritme
Na elke taakuitvoering moet jy die resultaat van die SUKSES-tjek na die moniteringstelsel stuur as die taakuitvoering suksesvol was, of FOUT as die uitvoering met 'n fout voltooi is.
Hierdie kontrole kan die volgende probleme opspoor:
- Die taak loop maar misluk met 'n fout.
- Die taak het opgehou loop, byvoorbeeld, dit het gevries.
Kom ons kyk hoe hierdie probleme in meer besonderhede opgelos word.
Uitgawe 1 – Die taak loop maar misluk met 'n fout
Hieronder is 'n geval waar die taak loop maar misluk tussen 14:00 en 16:00.
Die figuur wys dat wanneer 'n taak misluk, 'n sein onmiddellik na die moniteringstelsel gestuur word en die status van die ooreenstemmende tjek in die moniteringstelsel word alarm.
Neem asseblief kennis dat die status van die komponent in die moniteringstelsel afhang van die verifikasiestatus. Die alarmstatus van die tjek sal alle hoërvlakkomponente na alarm verander, sien die figuur hieronder.
Probleem 2 - Die taak het opgehou om uit te voer (gevries)
Hoe sal die moniteringstelsel verstaan dat 'n taak vas is?
Die tjekresultaat het 'n geldigheidstydperk, byvoorbeeld 1 uur. As 'n uur verbygaan en daar is geen nuwe toetsresultaat nie, sal die moniteringstelsel die toetsstatus op alarm stel.
Op die foto hierbo is die ligte om 14:00 afgeskakel. Om 15:00 sal die moniteringstelsel opspoor dat die toetsuitslag (vanaf 14:00) vrot is, want Die relevansietyd het verstryk (een uur), maar daar is geen nuwe resultaat nie, en sal die kontrole oorskakel na alarmstatus.
Om 16:00 is die ligte weer aangeskakel, die program sal die taak voltooi en die uitvoeringsresultaat na die moniteringstelsel stuur, die toetsstatus sal weer sukses word.
Watter kontrole-relevansietyd moet ek gebruik?
Die relevansietyd moet langer wees as die taakuitvoeringstydperk. Ek beveel aan om die relevansietyd 2-3 keer langer te stel as die taakuitvoeringstydperk. Dit is nodig om te verhoed dat vals kennisgewings ontvang word wanneer, byvoorbeeld, 'n taak langer as gewoonlik geneem het of iemand die program herlaai het.
Gaan vordering na
Die ASMO-stelsel het 'n "Load Forecast"-taak, wat een keer per uur 'n nuwe voorspelling van 'n eksterne bron probeer aflaai. Die presiese tyd wanneer 'n nuwe voorspelling in die eksterne stelsel verskyn, is nie bekend nie, maar dit is bekend dat dit 2 keer per dag gebeur. Dit blyk dat as daar vir 'n paar uur geen nuwe voorspelling is nie, dit normaal is, maar as daar vir meer as 'n dag geen nuwe voorspelling is nie, dan het iets iewers gebreek. Byvoorbeeld, die dataformaat in 'n eksterne voorspellingstelsel kan verander, en daarom sal ASMO nie 'n nuwe voorspellingsvrystelling sien nie.
Kontroleer algoritme
Die taak stuur die resultaat van die SUKSES-tjek na die moniteringstelsel wanneer dit daarin slaag om vordering te kry (aflaai van 'n nuwe weervoorspelling). As daar geen vordering is nie of 'n fout kom voor, word niks na die moniteringstelsel gestuur nie.
Die tjek moet so 'n relevansie-interval hê dat dit gedurende hierdie tyd gewaarborg is om nuwe vordering te ontvang.
Neem asseblief kennis dat ons met 'n vertraging van die probleem sal leer, want die moniteringstelsel wag totdat die geldigheidstydperk van die laaste skanderingresultaat verstryk. Daarom hoef die geldigheidstydperk van die tjek nie te lank gemaak te word nie.
Databasis monitering
Om die databasis in die ASMO-stelsel te beheer, voer ons die volgende kontroles uit:
- Verifieer tans rugsteunskepping
- Kontroleer tans vrye skyfspasie
Verifieer tans rugsteunskepping
In die meeste toepassings is dit belangrik om bygewerkte databasisrugsteun te hê sodat as die bediener misluk, jy die program na 'n nuwe bediener kan ontplooi.
ASMO skep een keer per week 'n rugsteunkopie en stuur dit stoor toe. Wanneer hierdie prosedure suksesvol voltooi is, word die resultaat van die sukseskontrole na die moniteringstelsel gestuur. Die verifikasieresultaat is vir 9 dae geldig. Dié. Om die skep van rugsteune te beheer, word die "vorderingskontrole"-meganisme, wat ons hierbo bespreek het, gebruik.
Kontroleer tans vrye skyfspasie
As daar nie genoeg vrye spasie op die skyf is nie, sal die databasis nie behoorlik kan funksioneer nie, daarom is dit belangrik om die hoeveelheid vrye spasie te beheer.
Dit is gerieflik om metrieke te gebruik om numeriese parameters na te gaan.
Metriks is 'n numeriese veranderlike, waarvan die waarde na die moniteringstelsel oorgedra word. Die moniteringstelsel kontroleer die drempelwaardes en bereken die metrieke status.
Hieronder is 'n prentjie van hoe die "Databasis"-komponent in die moniteringstelsel lyk:
Bediener monitering
Om die bediener te monitor, gebruik ons die volgende kontroles en maatstawwe:
1. Vrye skyfspasie
As die skyfspasie opraak, sal die toepassing nie kan werk nie. Ons gebruik 2 drempelwaardes: die eerste vlak is WAARSKUWING, die tweede vlak is ALARM.
2. Gemiddelde RAM-waarde in persentasie per uur
Ons gebruik die uurlikse gemiddelde omdat... ons stel nie belang in skaars rasse nie.
3. Gemiddelde SVE persentasie per uur
Ons gebruik die uurlikse gemiddelde omdat... ons stel nie belang in skaars rasse nie.
4. Ping tjek
Kontroleer dat die bediener aanlyn is. Die moniteringstelsel kan hierdie kontrole uitvoer; dit is nie nodig om kode te skryf nie.
Hieronder is 'n prentjie van hoe die "Server"-komponent in die moniteringstelsel lyk:
Toerusting monitering
Ek sal jou vertel hoe die data verkry word. Vir elke padbeheerpunt (MBK) is daar 'n taak in die taakbeplanner, byvoorbeeld, "Opname MBK M2 km 200". Die taak ontvang data van alle MPC-toestelle elke 30 minute.
Kommunikasiekanaalprobleem
Die meeste van die toerusting is buite die stad geleë; 'n GSM-netwerk word gebruik vir data-oordrag, wat nie stabiel werk nie (daar is 'n netwerk, of daar is nie een nie).
As gevolg van gereelde netwerkfoute, het die nagaan van die MBK-opname in monitering aanvanklik soos volg gelyk:
Dit het duidelik geword dat dit nie 'n werkende opsie was nie, want daar was baie vals kennisgewings oor probleme. Toe is besluit om 'n "vorderingskontrole" vir elke toestel te gebruik, m.a.w. Slegs die suksessein word na die moniteringstelsel gestuur wanneer die toestel sonder 'n fout gepeil word. Die relevansietyd is op 5 uur gestel.
Nou stuur monitering kennisgewings oor probleme slegs wanneer die toestel nie langer as 5 uur gepols kan word nie. Met 'n hoë mate van waarskynlikheid is dit nie vals alarms nie, maar werklike probleme.
Hieronder is 'n prentjie van hoe die toerusting in die moniteringstelsel lyk:
Belangrik!
Wanneer die GSM-netwerk ophou werk, word alle MDC-toestelle nie gepols nie. Om die aantal e-posse van die moniteringstelsel te verminder, teken ons ingenieurs in op kennisgewings oor komponentprobleme met die tipe "MPC" eerder as "Toestel". Dit laat jou toe om een kennisgewing vir elke MBK te ontvang, eerder as om 'n aparte kennisgewing vir elke toestel te ontvang.
Finale ASMO moniteringskema
Kom ons sit alles bymekaar en kyk watter soort moniteringskema ons het.
Gevolgtrekking
Kom ons som op.
Wat het die monitering van die prestasie van ASMO ons gegee?
1. Defek eliminasie tyd het afgeneem
Ons het voorheen gehoor van defekte van gebruikers, maar nie alle gebruikers rapporteer gebreke nie. Dit het gebeur dat ons 'n week nadat dit verskyn het van 'n wanfunksie van 'n stelselkomponent verneem het. Nou stel die moniteringstelsel ons in kennis van probleme sodra 'n probleem opgespoor word.
2. Stelselstabiliteit het toegeneem
Aangesien gebreke vroeër uitgeskakel is, het die stelsel as geheel baie meer stabiel begin werk.
3. Vermindering van die aantal oproepe na tegniese ondersteuning
Baie probleme is nou reggestel voordat gebruikers eers daarvan weet. Gebruikers het minder gereeld tegniese ondersteuning begin kontak. Dit alles het 'n goeie uitwerking op ons reputasie.
4. Verhoging van klante- en gebruikerslojaliteit
Die kliënt het positiewe veranderinge in die stabiliteit van die stelsel opgemerk. Gebruikers ondervind minder probleme met die gebruik van die stelsel.
5. Verminder tegniese ondersteuningskoste
Ons het opgehou om enige handkontroles uit te voer. Nou is alle tjeks outomaties. Voorheen het ons van gebruikers van probleme geleer; dit was dikwels moeilik om te verstaan van watter probleem die gebruiker praat. Nou word die meeste probleme deur die moniteringstelsel aangemeld; kennisgewings bevat tegniese data, wat dit altyd duidelik maak wat verkeerd geloop het en waar.
Belangrik!
Jy kan nie die moniteringstelsel installeer op dieselfde bediener waar jou toepassings loop nie. As die bediener afgaan, sal toepassings ophou werk en daar sal niemand wees om daaroor in kennis te stel nie.
Die moniteringstelsel moet op 'n aparte bediener in 'n ander datasentrum loop.
As jy nie 'n toegewyde bediener in 'n nuwe datasentrum wil gebruik nie, kan jy 'n wolkmoniteringstelsel gebruik. Ons maatskappy gebruik die Zidium-wolkmoniteringstelsel, maar jy kan enige ander moniteringstelsel gebruik. Die koste van 'n wolkmoniteringstelsel is laer as om 'n nuwe bediener te huur.
Aanbevelings:
- Breek toepassings en stelsels in die vorm van 'n boom van komponente in soveel detail as moontlik af, sodat dit gerieflik sal wees om te verstaan waar en wat gebreek is, en beheer sal meer volledig wees.
- Om die funksionaliteit van 'n komponent na te gaan, gebruik toetse. Dit is beter om baie eenvoudige tjeks te gebruik as een komplekse een.
- Stel metrieke drempels aan die kant van die moniteringstelsel op, eerder as om dit in kode te skryf. Dit sal jou verhoed om die toepassing te hersaamstel, herkonfigureer of herbegin.
- Vir gepasmaakte tjeks, gebruik 'n tydsmarge van relevansie om te verhoed dat vals kennisgewings ontvang word, want sommige tjeks het 'n bietjie langer geneem om te voltooi as gewoonlik.
- Probeer om die komponente in die moniteringstelsel net rooi te maak wanneer daar beslis 'n probleem is. As hulle vir niks rooi word nie, sal jy ophou om aandag te gee aan die kennisgewings van die moniteringstelsel, die betekenis daarvan sal verlore gaan.
As jy nog nie 'n moniteringstelsel gebruik nie, begin! Dit is nie so moeilik soos dit lyk nie. Kry 'n skop uit om na die groenbestanddele-boom te kyk wat jy self gekweek het.
Sterkte.
Bron: will.com