Ola a todos!
A nosa empresa dedícase ao desenvolvemento de software e ao soporte técnico posterior. O soporte técnico require non só corrixir erros, senón supervisar o rendemento das nosas aplicacións.
Por exemplo, se un dos servizos fallou, entón cómpre rexistrar automaticamente este problema e comezar a solucionalo, e non esperar a que os usuarios insatisfeitos se poñan en contacto co soporte técnico.
Temos unha empresa pequena, non temos os recursos para estudar e manter solucións complexas para o seguimento de aplicacións, necesitabamos atopar unha solución sinxela e eficaz.
Estratexia de seguimento
Non é doado comprobar a funcionalidade dunha aplicación; esta tarefa non é trivial, incluso pódese dicir creativa. É especialmente difícil verificar un sistema multi-link complexo.
Como podes comer un elefante? Só en partes! Usamos este enfoque para supervisar aplicacións.
A esencia da nosa estratexia de seguimento:
Dividir a súa aplicación en compoñentes.
Crea comprobacións de control para cada compoñente.
Un compoñente considérase operativo se todas as súas comprobacións de control se realizan sen erros. Unha aplicación considérase saudable se todos os seus compoñentes son funcionais.
Así, calquera sistema pode representarse como unha árbore de compoñentes. Os compoñentes complexos divídense en outros máis sinxelos. Os compoñentes sinxelos teñen comprobacións.
Os benchmarks non están destinados a realizar probas funcionais, non son probas unitarias. As comprobacións de control deben comprobar como se sente o compoñente no momento actual, se existen todos os recursos necesarios para o seu funcionamento e se hai algún problema.
Non hai milagres; a maioría dos controis terán que desenvolverse de forma independente. Pero non teñas medo, porque na maioría dos casos unha verificación leva 5-10 liñas de código, pero podes implementar calquera lóxica e entenderás claramente como funciona a comprobación.
Sistema de vixilancia
Digamos que dividimos a aplicación en compoñentes, creamos e implementamos comprobacións para cada compoñente, pero que facer cos resultados destas comprobacións? Como sabemos se fallou algunha comprobación?
Necesitaremos un sistema de vixilancia. Realizará as seguintes tarefas:
- Reciba os resultados das probas e utilízaos para determinar o estado dos compoñentes.
Visualmente, isto parece resaltar a árbore de compoñentes. Os compoñentes funcionais vólvense verdes, os problemáticos vólvense vermellos. - Realiza comprobacións xerais fóra da caixa.
O sistema de seguimento pode realizar algunhas comprobacións por si mesmo. Por que reinventar a roda, empregámolas. Por exemplo, pode comprobar que se está a abrir unha páxina do sitio web ou que o servidor está facendo ping. - Enviar notificacións de problemas aos interesados.
- Visualización de datos de seguimento, subministración de informes, gráficos e estatísticas.
Breve descrición do sistema ASMO
O mellor é explicalo cun exemplo. Vexamos como se organiza o seguimento do rendemento do sistema ASMO.
ASMO é un sistema automatizado de apoio meteorolóxico. O sistema axuda aos especialistas en servizos viarios a comprender onde e cando é necesario tratar a estrada con materiais de desxeo. O sistema recolle datos dos puntos de control de estradas. Un punto de control viario é un lugar da estrada onde se instalan equipos: estación meteorolóxica, cámara de vídeo, etc. Para prever situacións perigosas, o sistema recibe previsións meteorolóxicas de fontes externas.
Entón, a composición do sistema é bastante típica: sitio web, axente, equipo. Comecemos a vixilancia.
Descomposición do sistema en compoñentes
No sistema ASMO pódense distinguir os seguintes compoñentes:
1. Conta persoal
Esta é unha aplicación web. Como mínimo, cómpre comprobar que a aplicación está dispoñible en Internet.
2. Base de datos
A base de datos almacena datos que son importantes para os informes e debes asegurarte de que as copias de seguridade da base de datos se crean correctamente.
3. Servidor
Por servidor entendemos o hardware no que se executan as aplicacións. É necesario comprobar o estado do disco duro, da RAM, da CPU.
4. Axente
Este é un servizo de Windows que realiza moitas tarefas diferentes nunha programación. Como mínimo, cómpre comprobar que o servizo está funcionando.
5. Tarefa de axente
Só saber que un axente está a traballar non é suficiente. Un axente pode traballar, pero non realizar as súas tarefas asignadas. Dividamos o compoñente de axente en tarefas e comprobemos se cada tarefa de axente funciona correctamente.
6. Puntos de control de estradas (contedor de todos os MPC)
Hai moitos puntos de control da estrada, así que combinemos todos os MPC nun só compoñente. Isto fará máis cómodo ler os datos de seguimento. Ao ver o estado do compoñente do sistema ASMO, inmediatamente quedará claro onde están os problemas: nas aplicacións, no hardware ou no sistema de control máximo.
7. Punto de control da estrada (un límite máximo)
Consideraremos que este compoñente se pode reparar se todos os dispositivos deste MPC son reparables.
8. Dispositivo
Trátase dunha cámara de vídeo ou estación meteorolóxica que se instala no límite máximo de concentración. É necesario comprobar que o dispositivo funciona correctamente.
No sistema de monitorización, a árbore de compoñentes terá o seguinte aspecto:
Monitorización de aplicacións web
Entón, dividimos o sistema en compoñentes, agora temos que facer comprobacións para cada compoñente.
Para supervisar unha aplicación web utilizamos as seguintes comprobacións:
1. Comprobando a apertura da páxina principal
Esta comprobación realízaa o sistema de vixilancia. Para executalo, indicamos o enderezo da páxina, o fragmento de resposta esperado e o tempo máximo de execución da solicitude.
2. Comprobando o prazo de pago do dominio
Unha comprobación moi importante. Cando un dominio segue sen pagar, os usuarios non poden abrir o sitio. A resolución do problema pode levar varios días, porque... Os cambios de DNS non se aplican inmediatamente.
3. Comprobando o certificado SSL
Hoxe en día, case todos os sitios web utilizan o protocolo https para acceder. Para que o protocolo funcione correctamente, necesitas un certificado SSL válido.
Abaixo amósase o compoñente "Conta persoal" no sistema de seguimento:
Todas as comprobacións anteriores funcionarán para a maioría das aplicacións e non requiren codificación. Isto é moi xenial porque podes comezar a supervisar calquera aplicación web en 5 minutos. A continuación móstranse comprobacións adicionais que se poden realizar para unha aplicación web, pero a súa implementación é máis complexa e específica da aplicación, polo que non as trataremos neste artigo.
Que máis podes comprobar?
Para supervisar máis completamente a súa aplicación web, pode realizar as seguintes comprobacións:
- Número de erros de JavaScript por período
- Número de erros no lado da aplicación web (back-end) para o período
- Número de respostas de aplicacións web sen éxito (código de resposta 404, 500, etc.)
- Tempo medio de execución da consulta
Monitorización dun servizo de Windows (axente)
No sistema ASMO, o axente desempeña o papel dun planificador de tarefas, que executa as tarefas programadas en segundo plano.
Se todas as tarefas do axente se completan correctamente, o axente está a funcionar correctamente. Resulta que para supervisar un axente, cómpre supervisar as súas tarefas. Polo tanto, dividimos o compoñente "Axente" en tarefas. Para cada tarefa, crearemos un compoñente separado no sistema de seguimento, onde o compoñente "Axente" será o "pai".
Dividimos o compoñente do axente en compoñentes fillos (tarefas):
Entón, dividimos un compoñente complexo en varios sinxelos. Agora temos que facer comprobacións para cada compoñente sinxelo. Teña en conta que o compoñente principal "Axente" non terá ningunha comprobación, porque o sistema de seguimento calculará o seu estado de forma independente en función do estado dos seus compoñentes fillos. Noutras palabras, se todas as tarefas se completan con éxito, entón o axente está a funcionar correctamente.
Hai máis de cen tarefas no sistema ASMO, é realmente necesario crear comprobacións únicas para cada tarefa? Por suposto, o control será mellor se creamos e implementamos as nosas propias comprobacións especiais para cada tarefa do axente, pero na maioría dos casos é suficiente con usar comprobacións universais.
O sistema ASMO só utiliza comprobacións universais para as tarefas e isto é suficiente para supervisar o rendemento do sistema.
Comprobando o progreso
A comprobación máis sinxela e eficaz é a comprobación de execución. A comprobación verifica que a tarefa se complete sen erros. Todas as tarefas teñen esta comprobación.
Algoritmo de verificación
Despois de cada execución de tarefa, cómpre enviar o resultado da comprobación de ÉXITO ao sistema de seguimento se a execución da tarefa foi exitosa, ou ERRO se a execución completouse cun erro.
Esta comprobación pode detectar os seguintes problemas:
- A tarefa execútase pero falla cun erro.
- A tarefa deixou de executarse, por exemplo, conxelouse.
Vexamos como se solucionan estes problemas con máis detalle.
Problema 1: a tarefa execútase pero falla cun erro
A continuación móstrase un caso no que a tarefa se executa pero falla entre as 14:00 e as 16:00.
A figura mostra que cando falla unha tarefa, envíase inmediatamente un sinal ao sistema de monitorización e o estado da verificación correspondente no sistema de monitorización convértese en alarma.
Teña en conta que no sistema de seguimento, o estado do compoñente depende do estado de verificación. O estado de alarma da comprobación cambiará todos os compoñentes de nivel superior a alarma; consulte a figura a continuación.
Problema 2: a tarefa deixou de executarse (conxelada)
Como entenderá o sistema de seguimento que unha tarefa está atascada?
O resultado da comprobación ten un período de validez, por exemplo, 1 hora. Se pasa unha hora e non hai un novo resultado da proba, o sistema de monitorización establecerá o estado da proba en alarma.
Na imaxe superior, as luces foron apagadas ás 14:00 horas. Ás 15:00 horas, o sistema de vixilancia detectará que o resultado da proba (a partir das 14:00 horas) está podre, porque O tempo de relevancia caducou (unha hora), pero non hai ningún resultado novo e cambiará a comprobación ao estado de alarma.
Ás 16:00 acenderon de novo as luces, o programa completará a tarefa e enviará o resultado da execución ao sistema de seguimento, o estado da proba volverá ser exitoso.
Que tempo de relevancia de verificación debo usar?
O tempo de relevancia debe ser superior ao período de execución da tarefa. Recomendo establecer o tempo de relevancia 2-3 veces maior que o período de execución da tarefa. Isto é necesario para evitar recibir notificacións falsas cando, por exemplo, unha tarefa leva máis tempo do habitual ou alguén recarga o programa.
Comprobando o progreso
O sistema ASMO ten unha tarefa "Cargar previsión", que tenta descargar unha nova previsión dunha fonte externa unha vez por hora. Non se coñece a hora exacta na que aparece unha nova previsión no sistema externo, pero sábese que isto ocorre 2 veces ao día. Acontece que se non hai novas previsións durante varias horas, isto é normal, pero se non hai novas previsións durante máis dun día, algo rompeu nalgún lugar. Por exemplo, o formato de datos nun sistema de previsión externo pode cambiar, polo que ASMO non verá unha nova publicación de previsión.
Algoritmo de verificación
A tarefa envía o resultado da comprobación de ÉXITO ao sistema de vixilancia cando logra progresar (descargando unha nova previsión meteorolóxica). Se non hai progreso ou se produce un erro, non se envía nada ao sistema de seguimento.
A comprobación debe ter un intervalo de relevancia tal que durante este tempo se garanta a recepción de novos avances.
Teña en conta que coñeceremos o problema cun atraso, porque o sistema de seguimento espera ata que caduque o período de validez do último resultado da análise. Polo tanto, o período de validez do cheque non ten que ser demasiado longo.
Seguimento da base de datos
Para controlar a base de datos no sistema ASMO, realizamos as seguintes comprobacións:
- Verificando a creación da copia de seguranza
- Comprobando espazo libre no disco
Verificando a creación da copia de seguranza
Na maioría das aplicacións, é importante ter copias de seguridade actualizadas da base de datos para que, se o servidor falla, poida implantar o programa nun servidor novo.
ASMO crea unha copia de seguridade unha vez por semana e envíaa ao almacenamento. Cando este procedemento se completa con éxito, o resultado da comprobación de éxito envíase ao sistema de seguimento. O resultado da verificación é válido durante 9 días. Eses. Para controlar a creación de copias de seguridade, utilízase o mecanismo de "comprobación do progreso", que comentamos anteriormente.
Comprobando espazo libre no disco
Se non hai suficiente espazo libre no disco, a base de datos non poderá funcionar correctamente, polo que é importante controlar a cantidade de espazo libre.
É conveniente usar métricas para comprobar parámetros numéricos.
Métricas é unha variable numérica, cuxo valor se transmite ao sistema de vixilancia. O sistema de seguimento comproba os valores límite e calcula o estado da métrica.
A continuación móstrase unha imaxe do aspecto do compoñente "Base de datos" no sistema de seguimento:
Monitorización do servidor
Para supervisar o servidor usamos as seguintes verificacións e métricas:
1. Espazo libre no disco
Se se esgota o espazo no disco, a aplicación non poderá funcionar. Usamos 2 valores límite: o primeiro nivel é ADVERTENCIA, o segundo nivel é ALARMA.
2. Valor medio da RAM en porcentaxe por hora
Usamos a media horaria porque... non nos interesan as razas raras.
3. Porcentaxe media de CPU por hora
Usamos a media horaria porque... non nos interesan as razas raras.
4. Comprobación de ping
Comproba que o servidor está en liña. O sistema de monitorización pode realizar esta comprobación; non é necesario escribir código.
A continuación móstrase unha imaxe do aspecto do compoñente "Servidor" no sistema de monitorización:
Monitorización de equipos
Xa vos contarei como se obteñen os datos. Para cada punto de control de estrada (MPC) hai unha tarefa no planificador de tarefas, por exemplo, "Levantamento MPC M2 km 200". A tarefa recibe datos de todos os dispositivos MPC cada 30 minutos.
Problema da canle de comunicación
A maioría dos equipos están situados fóra da cidade; para a transmisión de datos utilízase unha rede GSM, que non funciona de forma estable (hai unha rede ou non a hai).
Debido a frecuentes fallos de rede, ao principio, a comprobación da enquisa MPC na supervisión quedou así:
Quedou claro que esta non era unha opción de traballo, porque había moitas notificacións falsas sobre problemas. Entón decidiuse utilizar unha "comprobación do progreso" para cada dispositivo, é dicir. Só se envía o sinal de éxito ao sistema de seguimento cando o dispositivo se enquisa sen erro. O tempo de relevancia estableceuse en 5 horas.
Agora a monitorización envía notificacións sobre problemas só cando o dispositivo non se pode consultar durante máis de 5 horas. Cun alto grao de probabilidade, non se trata de falsas alarmas, senón de problemas reais.
A continuación móstrase unha imaxe do aspecto do equipo no sistema de monitorización:
Importante!
Cando a rede GSM deixa de funcionar, non se sondean todos os dispositivos MDC. Para reducir o número de correos electrónicos do sistema de monitorización, os nosos enxeñeiros subscríbense a notificacións sobre problemas de compoñentes co tipo "MPC" en lugar de "Dispositivo". Isto permítelle recibir unha notificación por cada MPC, en lugar de recibir unha notificación separada para cada dispositivo.
Esquema final de vixilancia da OMAPE
Imos xuntar todo e ver que tipo de esquema de vixilancia temos.
Conclusión
Imos resumir.
Que nos deu o seguimento do rendemento de ASMO?
1. O tempo de eliminación de defectos diminuíu
Xa escoitamos falar de defectos por parte dos usuarios, pero non todos os usuarios informan de defectos. Ocorreu que nos enteramos dun mal funcionamento dun compoñente do sistema unha semana despois de que aparecese. Agora o sistema de vixilancia infórmanos dos problemas en canto se detecta un problema.
2. A estabilidade do sistema aumentou
Dado que os defectos comezaron a eliminarse antes, o sistema no seu conxunto comezou a funcionar moito máis estable.
3. Reducir o número de chamadas ao soporte técnico
Moitos problemas agora están solucionados antes de que os usuarios se enteren deles. Os usuarios comezaron a contactar co soporte técnico con menos frecuencia. Todo isto ten un bo efecto na nosa reputación.
4. Aumentar a fidelización de clientes e usuarios
O cliente notou cambios positivos na estabilidade do sistema. Os usuarios atopan menos problemas ao usar o sistema.
5. Reducir os custos de soporte técnico
Deixamos de realizar calquera comprobación manual. Agora todas as comprobacións están automatizadas. Anteriormente, aprendemos sobre os problemas dos usuarios; moitas veces era difícil entender de que problema falaba o usuario. Agora, a maioría dos problemas son informados polo sistema de seguimento; as notificacións conteñen datos técnicos, que sempre deixan claro que foi e onde.
Importante!
Non pode instalar o sistema de monitorización no mesmo servidor onde se executan as súas aplicacións. Se o servidor cae, as aplicacións deixarán de funcionar e non haberá quen o notifique.
O sistema de monitorización debe executarse nun servidor separado noutro centro de datos.
Se non queres utilizar un servidor dedicado nun novo centro de datos, podes usar un sistema de monitorización na nube. A nosa empresa usa o sistema de monitorización da nube Zidium, pero pode usar calquera outro sistema de monitorización. O custo dun sistema de vixilancia na nube é inferior ao de alugar un servidor novo.
Recomendacións:
- Desglosa aplicacións e sistemas en forma de árbore de compoñentes co maior detalle posible, polo que será conveniente entender onde e que se rompe, e o control será máis completo.
- Para comprobar a funcionalidade dun compoñente, use probas. É mellor usar moitas comprobacións sinxelas que unha complexa.
- Configure os limiares métricos ao lado do sistema de monitorización, en lugar de escribilos en código. Isto evitarache ter que recompilar, reconfigurar ou reiniciar a aplicación.
- Para verificacións personalizadas, utiliza unha marxe de tempo de relevancia para evitar recibir notificacións falsas porque algunhas comprobacións tardaron un pouco máis do habitual en completarse.
- Intente facer que os compoñentes do sistema de vixilancia se volvan vermellos só cando definitivamente hai un problema. Se se volven vermellos por nada, entón deixarás de prestar atención ás notificacións do sistema de seguimento, o seu significado perderase.
Se aínda non está a usar un sistema de monitorización, comeza! Non é tan difícil como parece. Disfruta de mirar a árbore de ingredientes verdes que cultivaches ti mesmo.
Boa sorte.
Fonte: www.habr.com