Relatório e registro de incidentes

Question

Estou procurando uma ferramenta (ou conselho) que me permita rastrear e registrar todos os incidentes que acontecem na minha infraestrutura.

Temos alguns servidores (mais de 50) e esse número vai aumentar no futuro. Por isso, quero ter uma visão geral melhor das coisas que estão acontecendo ou podem dar errado em um mês ou mais e ajudar-me a melhorar aquelas partes do sistema ou serviço propenso a falhas.

Por exemplo - se um servidor da web falhou em alguma instância ou o backup não foi concluído porque não havia espaço disponível em um servidor de backup ou houve um ataque DDoS, gostaria de observar que (quando, por que, onde como consertamos e assim por diante).

Temos sistemas de monitoramento central (Check_MK, Logstash + Kibana, analisadores de fluxo de rede ...) e alertas no local, e posso gerar relatórios de disponibilidade diretamente do Check_MK, mas esse relatório não é exato e nós o compartilhamos com nossos clientes. Eu preciso que isso seja para nosso uso interno.

Eu pesquisei um pouco e não encontrei muito - não há um padrão real para isso ou para uma ferramenta, então eu preciso de um conselho de alguém que já está lidando com essa ferramenta para usar ou, se não houver ferramenta (somos muito capazes de desenvolver um por nós mesmos) qual é a melhor prática quando se trata de registrar coisas como esta? O que você registra?

    

Answer 1

A resposta antiga era Off Topic devido a mal-entendidos . Mantendo-o como referência:

There are in fact multiple tools which allow what you want.

For example:

• logstash (which you already know)
• graylog
• Prometheus

Every one of them requires you to define triggers in some way on which you would be notified. Diving into this matter for multiple tools is way to much for this platform though.

There are multiple major areas that one would need to consider while building a really helpful monitoring and alerting system.

Gathering/Monitoring/Aggregation of:

• Availability of systems (hardware, software, services)
• Errors during operation of those systems (logs, correct responses)
• Changes over time (metrics of system parameters i.e. disk space and load, response times of services, rollout of newer versions)

Then one would be needed to define levels for alerting:

• Host/Service Up/Down
• Process Running
• Load over x.xx,x.xx,x.xx
• Disk space under x.xx
• Data growing rate bigger than x.xx MB/day
• http 500 responses > x/second
• etc

    

Answer 2

Nós usamos nosso sistema de tickets (atlassian jira) para essas coisas:

• criamos um projeto "incidentes de operação" com destinatários (observadores) aplicados no nível do projeto
• e um novo tipo de tarefa "incidente", em que todos esses itens têm seus próprios campos de formulário.

Portanto, se algum incidente acontecer, abrimos um novo ticket, preenchemos o que sabemos e o mantemos atualizado e atualizado sobre a duração do incidente. Depois que o incidente for corrigido e o pós-processamento for concluído (a análise de causa raiz principalmente) for concluída, encerramos o problema.

Prós:

• todos os envolvidos estão envolvidos (ou pelo menos informados) desde o início
• o suporte ao cliente tem um ponto central para procurar informações quando os clientes reclamam
O
• sistema de tickets permite o registro e a discussão do trabalho
• temos um arquivo para referência futura
• podemos usar as funções de relatórios integrados do jira para ter relatórios sobre os KPIs como "tempo para restauração", por exemplo