Canto máis complexo sexa o sistema, máis se ve cuberto de todo tipo de alertas. E hai que reaccionar a estas mesmas alertas, agregalas e visualizalas. Creo que esta é unha situación que a moitos lles resulta familiar ata o punto de nerviosismo.
A solución que se comentará non é a máis inesperada, pero a busca non devolve un artigo completo sobre este tema.
Por iso, decidín compartir a experiencia de FunCorp e falar sobre como se estrutura o proceso de obrigas, quen chama, por que e como podes miralo todo.
Que é PagerDuty?
Entón, para resolver todos estes problemas, comezamos a buscar unha ferramenta conveniente. Despois de buscar, escollemos PagerDuty. PD pareceunos unha solución bastante completa e concisa cunha gran cantidade de integracións e configuracións. Cómo é ela?
En resumo, PagerDuty é unha plataforma de procesamento de incidentes que pode procesar incidentes entrantes a través de varias integracións, configurar ordes de servizo e despois alertar ao enxeñeiro de servizo dependendo do nivel do incidente (a un nivel alto - unha chamada, a un nivel baixo -). un push desde a aplicación/SMS).
Quen é o oficial de servizo?
Este é probablemente o primeiro lugar para comezar a configurar PD.
En FunCorp, como outras empresas, hai un posto honorífico de oficial de servizo. Transmítese de enxeñeiro a enxeñeiro unha vez ao día. Hai unha chamada primeira e segunda liña de resposta a unha alerta de PagerDuty. Supoñamos que chega unha alerta de alta prioridade e se 10 minutos despois da chamada ao oficial de servizo desde a primeira liña non hai reacción a ela (é dicir, non se transfire ao estado de confirmación ou resolución), a chamada pasa á segunda. enxeñeiro de servizo. Isto configúrase no propio PagerDuty mediante políticas de escalada.
Se o oficial de segundo servizo non responde, a notificación volve a principal ao oficial de servizo.
Así, calquera alerta de alta prioridade entrante non pode permanecer sen procesar.
Agora vexamos de onde poden vir os incidentes.
Que integracións utilizamos?
PD recibe moitas incidencias diferentes de varios servizos. Actualmente temos uns 25 servizos deste tipo e para procesalos empregamos algunhas integracións xa preparadas.
- Prometeu
O principal sistema de recollida de métricas é Prometheus. Xa se escribiu moito sobre iso en Habré, só direi que temos varios deles para diferentes contornas: un recolle métricas de máquinas virtuais e dockers, outro dos servizos de Amazon, o terceiro de máquinas de hardware. Telegraf úsase principalmente como exportador de métricas.
Tamén aquí, creo, todo está claro polo título. Esta integración úsase para enviar notificacións desde algúns scripts executados por cron. PD dáche un determinado enderezo ao que envías cartas. Ao crear un servizo con tal integración, pode establecer prioridades, en que orde se procesarán as incidencias entrantes, como crear exactamente unha alerta (para cada carta entrante, para unha carta entrante + unha determinada regra, etc.).
- Neglixente
Na miña opinión, unha integración moi interesante. Hai momentos nos que algo pasa pero non está cuberto por incidentes. Por iso, engadimos a integración de Slack para crear un incidente. É dicir, podes escribir a Slack corporativo /callofduty todo é lento e romperase pronto e o PD tramitarao e remitirá a incidencia ao enxeñeiro de servizo.
Facemos:
Vemos:
- API
Integración HTTP. De feito, non hai nada especialmente interesante aquí, só unha solicitude POST cun corpo en formato JSON. Por exemplo, algo interesante: usámolo para monitorización externa usando . Este servizo comproba a accesibilidade dos nosos sitios desde diferentes partes do mundo. No caso de recibir un código de resposta inaceptable (por exemplo, 502), créase un incidente e, a continuación, todo segue a cadea descrita anteriormente. O propio StatusCake ten a capacidade de supervisar os URL internos, o certificado SSL ou a caducidade do dominio.
- LibreNMS
Este é outro sistema de seguimento, podes ler máis sobre el na súa páxina web . Coa súa axuda, monitorizamos interfaces de rede e iDRAC desde servidores.
Tamén houbo integracións como Datadog, CloudWatch. Podes ver máis sobre o que lles pasou .
Visualización
O principal sistema de notificación de incidentes é Slack. Todas as incidencias que chegan a PD son escritas nun chat especial e, se o seu estado cambia, isto tamén se mostra no chat.
Cando xurdiu a oportunidade de mostrar datos útiles nas pantallas dos monitores colgados do teito, de súpeto decatámonos de que nós (no departamento de devops) non tiñamos nada que mostrar neles. Hai unha Grafana marabillosa, pero non o cobre todo, e os empregados reaccionan ás alertas, non aos gráficos.
Despois dunha busca exhaustiva pero infructuosa en GitHub para buscar un "taboleiro" conciso e informativo para PD, decidimos escribir o noso, só co que necesitabamos. Aínda que ao principio houbo unha idea para mostrar a propia interface PD, parecía aínda máis incómodo.
Para escribilo, só tes que obter unha clave dun PD con dereitos de só lectura.
E isto é o que temos:
A pantalla mostra as incidencias abertas actuais, o nome do enxeñeiro de servizo actual do horario seleccionado e a hora sen incidencia de prioridade elevada (o panel cun incidente de prioridade alta resaltarase en vermello).
.
Como resultado, recibimos un cómodo panel para ver todas as nosas incidencias. Estarei feliz se algúns de vós considerades útil a nosa experiencia.
Fonte: www.habr.com