Hola a tots!
La nostra empresa es dedica al desenvolupament de programari i al suport tècnic posterior. El suport tècnic requereix no només corregir errors, sinó supervisar el rendiment de les nostres aplicacions.
Per exemple, si un dels serveis s'ha bloquejat, haureu de registrar automàticament aquest problema i començar a resoldre'l, i no esperar que els usuaris insatisfets contactin amb l'assistència tècnica.
Tenim una empresa petita, no tenim els recursos per estudiar i mantenir solucions complexes de monitorització d'aplicacions, calia trobar una solució senzilla i eficaç.
Estratègia de seguiment
No és fàcil comprovar la funcionalitat d'una aplicació; aquesta tasca no és trivial, fins i tot es podria dir creativa. És especialment difícil verificar un sistema multienllaç complex.
Com es pot menjar un elefant? Només en parts! Utilitzem aquest enfocament per supervisar les aplicacions.
L'essència de la nostra estratègia de seguiment:
Desglosseu la vostra aplicació en components.
Creeu comprovacions de control per a cada component.
Un component es considera operatiu si totes les seves comprovacions de control es realitzen sense errors. Una aplicació es considera saludable si tots els seus components són funcionals.
Així, qualsevol sistema es pot representar com un arbre de components. Els components complexos es divideixen en altres més simples. Els components simples tenen comprovacions.
Els benchmarks no estan destinats a realitzar proves funcionals, no són proves unitàries. Les comprovacions de control haurien de comprovar com se sent el component en el moment actual, si hi ha tots els recursos necessaris per al seu funcionament i si hi ha problemes.
No hi ha miracles; la majoria de controls s'hauran de desenvolupar de manera independent. Però no us espanteu, perquè en la majoria dels casos una comprovació pren entre 5 i 10 línies de codi, però podeu implementar qualsevol lògica i entendreu clarament com funciona la comprovació.
Sistema de seguiment
Suposem que dividim l'aplicació en components, hem creat i implementat comprovacions per a cada component, però què fer amb els resultats d'aquestes comprovacions? Com sabem si algun control ha fallat?
Necessitarem un sistema de seguiment. Ella durà a terme les següents tasques:
- Rebre els resultats de les proves i utilitzar-los per determinar l'estat dels components.
Visualment, sembla ressaltar l'arbre de components. Els components funcionals es tornen verds, els problemàtics es tornen vermells. - Realitzeu comprovacions generals fora de la caixa.
El sistema de control pot realitzar algunes comprovacions per si mateix. Per què reinventar la roda, utilitzem-les. Per exemple, podeu comprovar que s'està obrint una pàgina web o que el servidor fa ping. - Enviar notificacions de problemes als interessats.
- Visualització de dades de seguiment, subministrament d'informes, gràfics i estadístiques.
Breu descripció del sistema ASMO
El millor és explicar-ho amb un exemple. Vegem com s'organitza el seguiment del rendiment del sistema ASMO.
ASMO és un sistema de suport meteorològic automatitzat. El sistema ajuda els especialistes del servei de carreteres a entendre on i quan és necessari tractar la carretera amb materials de desglaç. El sistema recull dades dels punts de control de carreteres. Un punt de control de carretera és un lloc de la carretera on hi ha instal·lats equips: una estació meteorològica, una càmera de vídeo, etc. Per predir situacions perilloses, el sistema rep les previsions meteorològiques de fonts externes.
Per tant, la composició del sistema és força típica: lloc web, agent, equip. Comencem el seguiment.
Descomposició del sistema en components
En el sistema ASMO es poden distingir els següents components:
1. Compte personal
Aquesta és una aplicació web. Com a mínim, heu de comprovar que l'aplicació està disponible a Internet.
2. Base de dades
La base de dades emmagatzema dades que són importants per als informes i heu d'assegurar-vos que les còpies de seguretat de la base de dades es creen correctament.
3. Servidor
Per servidor ens referim al maquinari on s'executen les aplicacions. Cal comprovar l'estat de HDD, RAM, CPU.
4. Agent
Aquest és un servei de Windows que realitza moltes tasques diferents de forma programada. Com a mínim, heu de comprovar que el servei s'està executant.
5. Tasca d'agent
No n'hi ha prou amb saber que un agent està treballant. Un agent pot treballar, però no realitzar les seves tasques assignades. Dividim el component de l'agent en tasques i comprovem si cada tasca d'agent funciona correctament.
6. Punts de control de carreteres (contenidor de tots els MPC)
Hi ha molts punts de control de carreteres, així que combinem tots els MPC en un component. Això farà que sigui més convenient llegir les dades de monitoratge. Quan es visualitzi l'estat del component "Sistema ASMO", immediatament quedarà clar on es troben els problemes: en aplicacions, maquinari o en el sistema de control màxim.
7. Punt de control de carretera (un límit màxim)
Considerarem que aquest component és útil si tots els dispositius d'aquest MPC són útils.
8. Dispositiu
Es tracta d'una càmera de vídeo o estació meteorològica que s'instal·la al límit màxim de concentració. Cal comprovar que el dispositiu funciona correctament.
Al sistema de monitorització, l'arbre de components tindrà aquest aspecte:
Monitorització d'aplicacions web
Per tant, hem dividit el sistema en components, ara hem de fer comprovacions per a cada component.
Per supervisar una aplicació web fem servir les comprovacions següents:
1. Comprovació de l'obertura de la pàgina principal
Aquesta comprovació la realitza el sistema de seguiment. Per executar-lo, indiquem l'adreça de la pàgina, el fragment de resposta esperat i el temps màxim d'execució de la sol·licitud.
2. Comprovació del termini de pagament del domini
Un control molt important. Quan un domini no es paga, els usuaris no poden obrir el lloc. La resolució del problema pot trigar diversos dies, perquè... Els canvis de DNS no s'apliquen immediatament.
3. Comprovació del certificat SSL
Actualment, gairebé tots els llocs web utilitzen el protocol https per accedir-hi. Perquè el protocol funcioni correctament, necessiteu un certificat SSL vàlid.
A continuació es mostra el component "Compte personal" del sistema de seguiment:
Totes les comprovacions anteriors funcionaran per a la majoria d'aplicacions i no requereixen codificació. Això és molt interessant perquè podeu començar a supervisar qualsevol aplicació web en 5 minuts. A continuació es mostren comprovacions addicionals que es poden realitzar per a una aplicació web, però la seva implementació és més complexa i específica de l'aplicació, per la qual cosa no les tractarem en aquest article.
Què més pots comprovar?
Per supervisar més completament la vostra aplicació web, podeu realitzar les comprovacions següents:
- Nombre d'errors de JavaScript per període
- Nombre d'errors al costat de l'aplicació web (back-end) durant el període
- Nombre de respostes d'aplicacions web sense èxit (codi de resposta 404, 500, etc.)
- Temps mitjà d'execució de la consulta
Supervisió d'un servei de Windows (agent)
Al sistema ASMO, l'agent fa el paper d'un planificador de tasques, que executa les tasques programades en segon pla.
Si totes les tasques de l'agent es completen correctament, l'agent funciona correctament. Resulta que per supervisar un agent, cal supervisar les seves tasques. Per tant, dividim el component "Agent" en tasques. Per a cada tasca, crearem un component independent al sistema de seguiment, on el component "Agent" serà el "pare".
Dividim el component Agent en components secundaris (tasques):
Per tant, hem desglossat un component complex en diversos de simples. Ara hem de fer comprovacions per a cada component simple. Tingueu en compte que el component principal "Agent" no tindrà cap comprovació, perquè el sistema de supervisió calcularà el seu estat de manera independent en funció de l'estat dels seus components secundaris. En altres paraules, si totes les tasques es completen correctament, l'agent s'està executant correctament.
Hi ha més d'un centenar de tasques al sistema ASMO, és realment necessari crear comprovacions úniques per a cada tasca? Per descomptat, el control serà millor si inventem i implementem les nostres pròpies comprovacions especials per a cada tasca d'agent, però en la majoria dels casos n'hi ha prou amb utilitzar comprovacions universals.
El sistema ASMO només utilitza comprovacions universals per a les tasques i això és suficient per controlar el rendiment del sistema.
Comprovant el progrés
La comprovació més senzilla i eficaç és la comprovació d'execució. La comprovació verifica que la tasca s'ha completat sense errors. Totes les tasques tenen aquest control.
Algorisme de verificació
Després de cada execució de la tasca, heu d'enviar el resultat de la comprovació d'ÈXIT al sistema de supervisió si l'execució de la tasca ha tingut èxit, o ERROR si l'execució s'ha completat amb un error.
Aquesta comprovació pot detectar els problemes següents:
- La tasca s'executa però falla amb un error.
- La tasca ha deixat de funcionar, per exemple, s'ha congelat.
Vegem com es resolen aquests problemes amb més detall.
Problema 1: la tasca s'executa però falla amb un error
A continuació es mostra un cas en què la tasca s'executa però falla entre les 14:00 i les 16:00.
La figura mostra que quan una tasca falla, immediatament s'envia un senyal al sistema de monitorització i l'estat de la comprovació corresponent al sistema de monitoratge es converteix en alarma.
Tingueu en compte que al sistema de monitorització, l'estat del component depèn de l'estat de verificació. L'estat d'alarma de la comprovació canviarà tots els components de nivell superior a alarma, vegeu la figura següent.
Problema 2: la tasca es va deixar d'executar (congelada)
Com entendrà el sistema de seguiment que una tasca està encallada?
El resultat del control té un període de validesa, per exemple, 1 hora. Si passa una hora i no hi ha cap resultat de la prova nou, el sistema de monitorització establirà l'estat de la prova en alarma.
A la imatge de dalt, els llums es van apagar a les 14:00 p.m. A les 15:00, el sistema de control detectarà que el resultat de la prova (a partir de les 14:00) està podrit, perquè El temps de rellevància ha expirat (una hora), però no hi ha cap resultat nou i canviarà la comprovació a l'estat d'alarma.
A les 16:00 es van tornar a encendre els llums, el programa completarà la tasca i enviarà el resultat de l'execució al sistema de monitorització, l'estat de la prova tornarà a ser un èxit.
Quin temps de rellevància de comprovació he d'utilitzar?
El temps de rellevància ha de ser superior al període d'execució de la tasca. Recomano establir el temps de rellevància 2-3 vegades més llarg que el període d'execució de la tasca. Això és necessari per evitar rebre notificacions falses quan, per exemple, una tasca triga més de l'habitual o algú torna a carregar el programa.
Comprovant el progrés
El sistema ASMO té una tasca "Càrrega de previsió", que intenta descarregar una nova previsió d'una font externa una vegada per hora. No es coneix l'hora exacta en què apareix una nova previsió al sistema extern, però se sap que això passa 2 vegades al dia. Resulta que si no hi ha cap nova previsió durant diverses hores, això és normal, però si no hi ha cap nova previsió durant més d'un dia, alguna cosa s'ha trencat en algun lloc. Per exemple, el format de les dades en un sistema de previsió extern pot canviar, per la qual cosa ASMO no veurà una nova publicació de previsió.
Algorisme de verificació
La tasca envia el resultat de la comprovació d'ÈXIT al sistema de seguiment quan aconsegueix progressar (descàrrega d'una nova previsió meteorològica). Si no hi ha cap progrés o es produeix un error, no s'envia res al sistema de monitorització.
La comprovació ha de tenir un interval de rellevància tal que durant aquest temps es garanteixi rebre nous progrés.
Tingueu en compte que coneixerem el problema amb un retard, perquè el sistema de monitorització espera fins que caduqui el període de validesa del darrer resultat de l'anàlisi. Per tant, no cal que el període de validesa del xec sigui massa llarg.
Seguiment de bases de dades
Per controlar la base de dades al sistema ASMO, realitzem les comprovacions següents:
- S'està verificant la creació de la còpia de seguretat
- Comprovant l'espai lliure al disc
S'està verificant la creació de la còpia de seguretat
A la majoria d'aplicacions, és important tenir còpies de seguretat de la base de dades actualitzades perquè, si el servidor falla, pugueu implementar el programa en un nou servidor.
ASMO crea una còpia de seguretat un cop per setmana i l'envia a l'emmagatzematge. Quan aquest procediment es completa amb èxit, el resultat de la comprovació d'èxit s'envia al sistema de monitorització. El resultat de la verificació és vàlid durant 9 dies. Aquells. Per controlar la creació de còpies de seguretat, s'utilitza el mecanisme de "verificació del progrés", que hem comentat anteriorment.
Comprovant l'espai lliure al disc
Si no hi ha prou espai lliure al disc, la base de dades no podrà funcionar correctament, per la qual cosa és important controlar la quantitat d'espai lliure.
És convenient utilitzar mètriques per comprovar paràmetres numèrics.
Mètriques és una variable numèrica, el valor de la qual es transmet al sistema de seguiment. El sistema de monitorització verifica els valors llindars i calcula l'estat de la mètrica.
A continuació es mostra una imatge de com és el component "Base de dades" al sistema de monitorització:
Monitorització del servidor
Per supervisar el servidor fem servir les següents comprovacions i mètriques:
1. Espai lliure al disc
Si s'esgota l'espai al disc, l'aplicació no podrà funcionar. Utilitzem 2 valors de llindar: el primer nivell és ADVERTIMENT, el segon nivell és ALARMA.
2. Valor mitjà de RAM en percentatge per hora
Utilitzem la mitjana horària perquè... no ens interessen les races rares.
3. Percentatge mitjà de CPU per hora
Utilitzem la mitjana horària perquè... no ens interessen les races rares.
4. Comprovació de ping
Comprova que el servidor estigui en línia. El sistema de monitorització pot realitzar aquesta comprovació; no cal escriure codi.
A continuació es mostra una imatge de com és el component "Servidor" al sistema de monitorització:
Monitorització d'equips
Us explicaré com s'obtenen les dades. Per a cada punt de control de carretera (MPC) hi ha una tasca al planificador de tasques, per exemple, "Enquesta MPC M2 km 200". La tasca rep dades de tots els dispositius MPC cada 30 minuts.
Problema del canal de comunicació
La majoria dels equips es troben fora de la ciutat; s'utilitza una xarxa GSM per a la transmissió de dades, que no funciona de manera estable (hi ha una xarxa o no n'hi ha).
A causa dels freqüents errors de la xarxa, al principi, la comprovació de l'enquesta MPC a la supervisió semblava així:
Va quedar clar que aquesta no era una opció de treball, perquè hi havia moltes notificacions falses sobre problemes. Aleshores es va decidir utilitzar una "verificació del progrés" per a cada dispositiu, és a dir. Només el senyal d'èxit s'envia al sistema de monitorització quan el dispositiu es consulta sense error. El temps de rellevància es va establir en 5 hores.
Ara el monitoratge envia notificacions sobre problemes només quan el dispositiu no es pot enquestar durant més de 5 hores. Amb un alt grau de probabilitat, no es tracta de falses alarmes, sinó de problemes reals.
A continuació es mostra una imatge de com es veu l'equip al sistema de monitorització:
¡Important!
Quan la xarxa GSM deixa de funcionar, no es sondegen tots els dispositius MDC. Per reduir el nombre de correus electrònics del sistema de monitorització, els nostres enginyers es subscriuen a notificacions sobre problemes de components amb el tipus "MPC" en lloc de "Dispositiu". Això us permet rebre una notificació per a cada MPC, en lloc de rebre una notificació independent per a cada dispositiu.
Esquema final de seguiment de l'ASMO
Posem-ho tot i veiem quin tipus d'esquema de seguiment tenim.
Conclusió
Resumim.
Què ens va aportar el seguiment del rendiment d'ASMO?
1. El temps d'eliminació de defectes ha disminuït
Abans hem sentit parlar de defectes per part dels usuaris, però no tots els usuaris informen de defectes. Va passar que ens vam assabentar d'un mal funcionament d'un component del sistema una setmana després que aparegués. Ara el sistema de monitorització ens avisa dels problemes tan bon punt es detecta un problema.
2. L'estabilitat del sistema ha augmentat
Com que els defectes van començar a eliminar-se abans, el sistema en conjunt va començar a funcionar molt més estable.
3. Reducció del nombre de trucades al suport tècnic
Ara s'han solucionat molts problemes abans que els usuaris se'n coneguin. Els usuaris van començar a contactar amb l'assistència tècnica amb menys freqüència. Tot això té un bon efecte en la nostra reputació.
4. Augmentar la fidelització de clients i usuaris
El client va notar canvis positius en l'estabilitat del sistema. Els usuaris troben menys problemes amb el sistema.
5. Reduir els costos de suport tècnic
Hem deixat de fer qualsevol comprovació manual. Ara tots els controls estan automatitzats. Anteriorment, vam conèixer els problemes dels usuaris; sovint era difícil entendre de quin problema parlava l'usuari. Ara, la majoria dels problemes els informa el sistema de monitorització; les notificacions contenen dades tècniques, que sempre deixen clar què va fallar i on.
¡Important!
No podeu instal·lar el sistema de supervisió al mateix servidor on s'executen les vostres aplicacions. Si el servidor falla, les aplicacions deixaran de funcionar i no hi haurà ningú per notificar-ho.
El sistema de monitorització s'ha d'executar en un servidor independent d'un altre centre de dades.
Si no voleu utilitzar un servidor dedicat en un centre de dades nou, podeu utilitzar un sistema de monitorització al núvol. La nostra empresa utilitza el sistema de monitorització del núvol Zidium, però podeu utilitzar qualsevol altre sistema de monitorització. El cost d'un sistema de monitorització al núvol és inferior al de llogar un servidor nou.
Recomanacions:
- Desglosseu les aplicacions i els sistemes en forma d'arbre de components amb el màxim de detall possible, de manera que serà convenient entendre on i què està trencat, i el control serà més complet.
- Per comprovar la funcionalitat d'un component, utilitzeu proves. És millor utilitzar moltes comprovacions senzilles que una de complexa.
- Configureu els llindars mètrics al costat del sistema de supervisió, en lloc d'escriure'ls en codi. Això us estalviarà d'haver de recompilar, reconfigurar o reiniciar l'aplicació.
- Per a les comprovacions personalitzades, utilitzeu un marge de temps de rellevància per evitar rebre notificacions falses perquè algunes comprovacions han trigat una mica més de l'habitual a completar-se.
- Intenteu que els components del sistema de monitorització es tornin vermells només quan hi hagi algun problema. Si es tornen vermells per res, deixaràs de prestar atenció a les notificacions del sistema de monitorització, el seu significat es perdrà.
Si encara no utilitzeu un sistema de monitorització, comença! No és tan difícil com sembla. Gaudeix de mirar l'arbre d'ingredients verds que has cultivat tu mateix.
Bona sort.
Font: www.habr.com