Executando verificação de segurança...
Em resposta a Observabilidade
2

Meus 2 cents,

Um que esta na moda:

https://prometheus.io/

Um bem robusto:

https://www.zabbix.com/

O que eu uso no dia-a-dia (mas eh old-school)

https://icinga.com/

Alem disso, coloquei os alertas para serem enviados por: email, sms, whatsapp e telegram. E em um caso especifico (para casos de madrugada e urgentes) ele faz uma ligacao para meus telefones via Voip e toca um mp3 pre-definido.


FerramentaTipo / modelo principalFoco / ponto forte
PrometheusFoco em métricas de séries temporais, “pull” de métricas via HTTP, com exportadores; alertas e queries próprias; muito usado em ambientes dinâmicos / “cloud native”Excelente para monitoramento em tempo real, microserviços, contêineres, sistemas cujo número de instâncias varia; bom para consultas ad hoc e alertas dinâmicos (infobytes.guru)
ZabbixModelo híbrido: agente, SNMP, ICMP, etc.; monitoramento ativo e passivo; servidor + agentes/proxiesMuito bom para monitorar infraestrutura completa: servidores, rede, aplicações; templates, auto-descoberta, escalabilidade via proxies (Zabbix)
IcingaMonitoramento ativo/passivo baseado em checagens (check scripts), arquitetura modular, compatibilidade com NagiosForte controle de serviço + host, alertas, check periodicamente, bom para ambientes estáticos, redes tradicionais (Wikipedia)

Saude e Sucesso !

Carregando publicação patrocinada...
1

Como você define os critérios de alerta? Sempre acontece algo inesperado você já é notificado?

Tipo um user recebeu 500, você já vai lá e prontamente corrige.

5

Meus 2 cents,

Monitoro aspectos dos servidores e dos apps, tais como:

  • Consumo de CPU, disco, memoria
  • Se o APP esta "responsivo" (checo se a porta 80/443 conecta e retorna um conteudo pre-estabelecido)
  • Se o banco esta no ar ou capotou
  • O tempo de resposta de uma pagina especifica
  • Quantidade de instancias do app ativas (no caso de loadbalance e auto-scaling)

(mas tem outros itens tambem)

Se qualquer um destes eventos sair de limites (threshold) espeficicados, ja dispara um alerta "padrao": email (para fins de registro), whatsapp/telegram/sms (para grupos/times especificos).

Alguns alertas sao enviados apenas em horario comercial (seg/sex, 0900-1700), outros sao 24/7 (seg-dom, 0000-2359) - depende da criticidade do item monitorado.

Conforme a criticidade (que voce seta por item monitorado), alem de enviar o alerta ele pode ativar um "escalation list": se ninguem "tomou ciencia" (interagiu com o monitoramento avisando que ja esta avaliando a situacao), apos algum tempo (com tolerancia variavel, que pode ser de horas ou em alguns casos apenas minutos) - ele comeca a enviar alertas para outras pessoas do time (p.ex. leader, gerencia, diretoria) ate que alguem avise no sistema que uma acao esta sendo tomada (nao significa que ja tem uma solucao, mas que pelo menos o problema esta sendo avaliado).

Nao monitoramos "erro 500" especificamente (exceto em situacoes que exijam, como o deploy de uma change muito abrangente).

E existe um outro ponto que eh monitorado de forma mais proxima que eh o 'fail2ban' e o 'modsecurity', que sao WAF (web application firewall) - estes monitoram os LOGs de forma automatica e tomam acoes como bloquear um atacante ou semelhante.

Saude e Sucesso !

0
2

Meus 2 cents,

Espero que tenha ajudado !

Se implementar algo do genero - compartilhe a experiencia, contando os objetivos que gostaria de atingir, como foi colocar em funcionamento e se teve os resultados desejados.

Saude e Sucesso !

1