Como monitorizar a disponibilidade de um servidor: verificações, ferramentas e alertas

Para monitorizar a disponibilidade (uptime) de um servidor, execute verificações automáticas a partir do exterior do servidor (ping, porta TCP ou pedidos HTTP a partir de várias localizações), recolha os sinais de saúde do próprio servidor com um agente e só alerte quando várias localizações falharem seguidamente. Depois registe cada indisponibilidade para poder calcular, todos os meses, a disponibilidade face ao seu SLA.

Pontos principais

• As verificações sintéticas externas respondem a "os utilizadores conseguem aceder?"; os agentes internos respondem a "porque está em baixo?". Precisa de ambos.
• Verifique a partir de pelo menos três localizações e alerte em falhas consecutivas, para evitar falsos alarmes causados por um único caminho de rede deficiente. A Microsoft recomenda pelo menos cinco localizações de teste nos testes de disponibilidade do Azure.
• Teste o que os utilizadores usam: um pedido HTTPS que verifica o código de estado e o conteúdo da página vale mais do que um ping.
• Uma disponibilidade de 99,9% ainda permite cerca de 43,8 minutos de indisponibilidade por mês. Saiba o que o seu objetivo permite antes de definir os limiares de alerta.
• Exclua as janelas de manutenção acordadas de forma consistente e reporte a disponibilidade a partir dos mesmos dados todos os meses.

O que é a monitorização da disponibilidade de servidores?

A monitorização da disponibilidade de servidores é a verificação contínua de se um servidor e os serviços nele alojados estão acessíveis e a responder corretamente. Produz duas coisas: alertas quando algo falha e um histórico que pode converter numa percentagem de disponibilidade.

Tempo de atividade (uptime) e disponibilidade estão relacionados, mas não são idênticos. Um servidor pode estar ligado (uptime elevado) enquanto o seu serviço web devolve erros (disponibilidade baixa). Para a maioria das empresas, o número que importa é a disponibilidade do serviço, tal como os utilizadores a veem.

Quanta indisponibilidade permite cada objetivo de disponibilidade?

A disponibilidade é (tempo total − indisponibilidade) ÷ tempo total. A tabela converte objetivos comuns em indisponibilidade permitida, usando um mês médio de 730 horas.

Um objetivo exigente muda a forma de monitorizar. A 99,99%, um intervalo de verificação de cinco minutos nem sequer consegue detetar todas as violações, pelo que precisa de verificações a cada minuto ou mais depressa e de uma resposta de prevenção medida em minutos. O capítulo do livro de SRE da Google sobre embracing risk explica por que razão cada nove adicional custa mais e por que o objetivo deve seguir a necessidade do negócio.

Que verificações deve executar?

Verificações externas (sintéticas)

• Ping ICMP: mostra que o host responde na rede. É barato, mas muitas firewalls bloqueiam-no, e um host pode responder ao ping enquanto as suas aplicações estão em baixo.
• Verificações de porta TCP: confirmam que um serviço está à escuta, por exemplo a 443 para HTTPS, a 3389 para RDP ou a 5432 para PostgreSQL.
• Verificações HTTP(S): pedem um URL e verificam o código de estado, o tempo de resposta e um excerto de conteúdo esperado. Use um endpoint de estado dedicado que teste também a ligação à base de dados.
• Verificações de certificados TLS: avisam antes de um certificado expirar. Um certificado expirado é uma indisponibilidade para os utilizadores mesmo com o servidor saudável.
• Verificações de DNS: confirmam que o nome resolve para o endereço correto.

Sinais internos (baseados em agente)

• Heartbeat: o agente reporta a cada minuto; um heartbeat em falta significa que o host ou o agente está em baixo.
• Contador de uptime do sistema: mostra reinícios não planeados. No Linux use uptime ou last reboot; no Windows, o evento com ID 6008 no registo do Sistema regista um encerramento inesperado.
• Métricas de recursos: CPU, memória, espaço em disco e latência de disco. Discos cheios e esgotamento de memória são causas comuns de "ligado mas sem funcionar".
• Estado de serviços e processos: o servidor web, a base de dados ou a tarefa agendada estão em execução?

Para hosts Windows, o nosso guia sobre como monitorizar o desempenho do Windows Server enumera os contadores que vale a pena recolher.

Que ferramentas permitem monitorizar a disponibilidade de servidores?

A escolha importa menos do que a configuração. Uma ferramenta alojada por si também precisa de ser monitorizada: se o seu único servidor de monitorização estiver no mesmo bastidor que os servidores que vigia, uma falha de energia deita abaixo ambos. Execute pelo menos uma verificação externa a partir de uma rede diferente ou de um serviço cloud.

Como configurar alertas de disponibilidade sem falsos alarmes

1. Use várias localizações. A Microsoft recomenda pelo menos cinco localizações de teste nos testes de disponibilidade do Azure e um limiar de alerta igual ao número de localizações menos dois, por exemplo três a falhar em cinco.
2. Exija falhas consecutivas. A opção de repetição do Azure só reporta uma falha depois de três tentativas sucessivas falharem; a Microsoft refere que cerca de 80% das falhas desaparecem numa nova tentativa.
3. Defina a gravidade pelo impacto. Um portal de clientes em produção chama o engenheiro de prevenção; um servidor de testes envia um ticket.
4. Encaminhe os alertas para quem pode agir, com escalamento se ninguém os reconhecer dentro de um prazo definido.
5. Silencie a manutenção planeada na ferramenta de monitorização em vez de ignorar alertas por hábito.
6. Alerte também na recuperação, para que a equipa saiba quando o incidente terminou.

A orientação de SRE da Google sobre monitoring distributed systems acrescenta uma regra útil: cada chamada de alerta (page) deve ser urgente, acionável e exigir uma pessoa. Tudo o resto pertence a um ticket ou a um dashboard.

Como reportar a disponibilidade face a um SLA

• Defina o que conta como indisponível, por exemplo "o endpoint de estado falha em três de cinco localizações em duas verificações consecutivas".
• Acorde quais as janelas de manutenção excluídas e registe-as na ferramenta.
• Calcule a disponibilidade mensal a partir dos resultados das verificações, e não de memória ou de notas de tickets.
• Mantenha um registo de indisponibilidades com início, fim, causa e correção. Padrões, como falhas após cada noite de patches, mostram onde investir.
• Compare o seu valor com o que o seu fornecedor de cloud garante. Por exemplo, o SLA de computação da Amazon garante 99,99% de disponibilidade mensal para o EC2 implementado em várias zonas de disponibilidade de uma região, mas apenas 99,5% para uma única instância EC2. A disponibilidade da sua aplicação nunca pode exceder o que a sua dependência mais fraca entrega.

A monitorização informa-o sobre as indisponibilidades; a redundância evita-as. Execute as cargas de trabalho críticas em mais do que um servidor ou zona de disponibilidade, atrás de um balanceador de carga, para que uma única falha não deite abaixo o serviço. A WorkBuster, uma plataforma SaaS de recrutamento, corre em EC2 atrás de um Application Load Balancer, com MySQL RDS multi-AZ, um grupo de auto-scaling e dashboards e alarmes CloudWatch; o caso WorkBuster mostra a configuração completa.

Como a Opsio ajuda

A Opsio assegura monitorização e resposta a incidentes 24/7 para servidores e cargas de trabalho na cloud na AWS, no Azure e no Google Cloud. Configuramos as verificações, o encaminhamento de alertas e os relatórios mensais de disponibilidade, e os nossos engenheiros atuam sobre os alertas. Consulte as nossas páginas de serviços de monitorização e suporte cloud, monitorização remota de infraestrutura e observabilidade com Prometheus e Grafana.

Perguntas frequentes

Como verifico há quanto tempo um servidor está em funcionamento?

No Linux, execute uptime ou last reboot. No Windows, abra o separador Desempenho do Gestor de Tarefas, execute systeminfo e leia "Hora de arranque do sistema" ("System Boot Time"), ou consulte o registo de eventos do Sistema. Estes mostram o tempo desde o último arranque, e não se os serviços estiveram disponíveis.

Com que frequência devem correr as verificações de disponibilidade?

A cada um a cinco minutos na maioria dos serviços de produção. Ajuste o intervalo ao seu objetivo: a 99,99% só tem cerca de 4,4 minutos de indisponibilidade por mês, pelo que um intervalo de cinco minutos é demasiado lento para a medir.

O ping basta para monitorizar a disponibilidade de um servidor?

Não. O ping apenas prova que a pilha de rede responde. Acrescente uma verificação TCP ou HTTPS ao serviço de que os utilizadores dependem, idealmente com correspondência de conteúdo, mais verificações baseadas em agente no próprio servidor.

Qual é uma boa percentagem de disponibilidade para um servidor?

Para aplicações de negócio, 99,9% é um objetivo comum; os serviços voltados para clientes visam muitas vezes 99,95% ou mais. Objetivos mais altos exigem redundância: a AWS, por exemplo, garante apenas 99,5% para uma única instância EC2, mas 99,99% para EC2 distribuído por zonas de disponibilidade.

Posso monitorizar a disponibilidade gratuitamente?

Sim. Ferramentas open source como o Prometheus com blackbox_exporter, o Zabbix ou o Nagios não custam nada em licenças, embora pague em alojamento e tempo de manutenção. As verificações nativas dos fornecedores de cloud têm custo baixo para um número reduzido de endpoints.

Leitura relacionada

• O que é a monitorização cloud
• O que é a monitorização em tempo real de servidores e aplicações?
• Como monitorizar o desempenho do Windows Server? Ferramentas e métricas