Quanto mais complexo o sistema, mais ele fica repleto de todos os tipos de alertas. E há necessidade de reagir a esses mesmos alertas, agregá-los e visualizá-los. Acho que esta é uma situação familiar para muitos ao ponto do nervosismo.
A solução que será discutida não é das mais inesperadas, mas a busca não retorna um artigo completo sobre o tema.
Por isso, resolvi compartilhar a experiência da FunCorp e falar sobre como é estruturado o processo de plantão, quem liga, por que e como você pode olhar tudo isso.
O que é PagerDuty?
Então, para resolver todos esses problemas, começamos a procurar uma ferramenta conveniente. Depois de alguma pesquisa, escolhemos o PagerDuty. PD nos pareceu uma solução bastante completa e concisa, com um grande número de integrações e configurações. Como ela é?
Resumindo, o PagerDuty é uma plataforma de processamento de incidentes que pode processar incidentes recebidos por meio de várias integrações, configurar ordens de serviço e, em seguida, alertar o engenheiro de plantão dependendo do nível do incidente (em alto nível - uma chamada, em baixo nível - um push do aplicativo / SMS).
Quem é o oficial de plantão?
Este é provavelmente o primeiro lugar para começar a configurar o PD.
Na FunCorp, assim como em outras empresas, existe um cargo honorário de diretor de plantão. É transmitido de engenheiro para engenheiro uma vez por dia. Existe uma chamada primeira e segunda linha de resposta a um alerta do PagerDuty. Suponha que chegue um alerta de alta prioridade e se 10 minutos após a chamada para o oficial de plantão da primeira linha não houver reação a ele (ou seja, não for transferido para o status de reconhecimento ou resolvido), a chamada vai para a segunda engenheiro de plantão. Isso é configurado no próprio PagerDuty por meio de políticas de escalonamento.
Se o segundo oficial de serviço não responder, a notificação retorna para o principal ao oficial de serviço.
Assim, qualquer alerta de alta prioridade recebido não pode permanecer sem processamento.
Agora vamos ver de onde podem vir os incidentes.
Quais integrações usamos?
A PD recebe muitos incidentes diferentes de vários serviços. Atualmente temos cerca de 25 desses serviços e para processá-los utilizamos algumas integrações prontas.
- Prometeu
O principal sistema de coleta de métricas é o Prometheus. Muito já foi escrito sobre isso no Habré, direi apenas que temos vários deles para diferentes ambientes: um coleta métricas de máquinas virtuais e dockers, outro de serviços Amazon, o terceiro de máquinas de hardware. O Telegraf é usado principalmente como exportador de métricas.
Também aqui, creio, tudo fica claro pelo título. Esta integração é utilizada para enviar notificações de alguns scripts executados pelo cron. PD fornece um endereço específico para o qual você envia cartas. Ao criar um serviço com essa integração, você pode definir prioridades, em que ordem os incidentes recebidos serão processados, como exatamente criar um alerta (para cada carta recebida, para uma carta recebida + uma determinada regra, etc.).
- Slack
Na minha opinião, uma integração muito interessante. Há momentos em que algo acontece, mas não é coberto por incidentes. Portanto, adicionamos integração do Slack para criar um incidente. Ou seja, você pode escrever para o Slack corporativo /callofduty tudo está lento e irá quebrar em breve e o PD irá processá-lo e enviar o incidente ao engenheiro de plantão.
Nós fazemos:
Vemos:
- API
Integração HTTP. Na verdade, não há nada de particularmente interessante aqui, apenas uma solicitação POST com corpo em formato JSON. Por exemplo, algo interessante: usamos para monitoramento externo usando . Este serviço verifica a acessibilidade dos nossos sites em diferentes partes do mundo. Caso recebamos um código de resposta inaceitável (por exemplo, 502), é criado um incidente e então tudo segue a cadeia descrita acima. O próprio StatusCake tem a capacidade de monitorar URLs internos, certificados SSL ou expiração de domínio.
- FreeNMS
Este é outro sistema de monitoramento, você pode ler mais sobre ele no site deles . Com sua ajuda, monitoramos interfaces de rede e iDRAC de servidores.
Também houve integrações como Datadog, CloudWatch. Você pode ver mais sobre o que aconteceu com eles .
Visualização
O principal sistema de relatório de incidentes é o Slack. Todos os incidentes que chegam ao PD são gravados em um chat especial e, se seu status mudar, isso também será exibido no chat.
Quando surgiu a oportunidade de exibir dados úteis nas telas dos monitores pendurados no teto, de repente percebemos que nós (no departamento de devops) não tínhamos nada para exibir neles. Existe um Grafana maravilhoso, mas não cobre tudo, e os funcionários reagem aos alertas, não aos gráficos.
Depois de uma busca minuciosa, mas sem sucesso, no GitHub por um “quadro” conciso e informativo para PD, decidimos escrever o nosso próprio - apenas com o que precisávamos. Embora no início houvesse a ideia de exibir a própria interface PD, parecia ainda mais inconveniente.
Para escrevê-lo, tudo que você precisa fazer é obter uma chave de um PD com direitos somente leitura.
E foi isso que obtivemos:
A tela exibe os incidentes abertos atuais, o nome do engenheiro de plantão atual da programação selecionada e o tempo sem incidente de alta prioridade (o painel com incidente de alta prioridade será destacado em vermelho).
.
Como resultado, recebemos um painel conveniente para visualizar todos os nossos incidentes. Ficarei feliz se alguns de vocês acharem nossa experiência útil.
Fonte: habr.com