Tempo de atividade
Monitorização

Xitoring suporta HTTP, HTTPS, Ping (ICMP), DNS, TCP, UDP, FTP, SMTP, IMAP e POP3. É possível monitorizar praticamente qualquer serviço ligado à Internet a partir de um único painel de controlo.

Com intervalos de verificação de 1 minuto, é possível receber um alerta rapidamente após a deteção de uma falha. As verificações de confirmação a partir de vários nós eliminam os falsos positivos antes do envio do alerta.

Xitoring opera mais de 15 nós de monitorização na América do Norte, Europa, Ásia-Pacífico, América do Sul e Médio Oriente. Cada verificação é executada simultaneamente a partir de vários locais.

A monitorização do tempo de atividade destina-se a serviços acessíveis ao público. Para serviços internos, utilize o nosso agente de monitorização de servidores ou a monitorização Heartbeat para serviços protegidos por firewalls.

Pode configurar janelas de manutenção para suprimir alertas durante os períodos de inatividade planeados. A sua percentagem de tempo de atividade é ajustada para excluir esses períodos dos cálculos do SLA.

Sim. O Xitoring oferece migração com um clique a partir do Pingdom, do Uptime.com e do BetterStack. Todas as suas configurações de verificação, definições de alertas e contactos são importadas automaticamente.

A monitorização do tempo de atividade, de acordo com os padrões do setor, é realizada em intervalos de um minuto a partir de, pelo menos, três regiões geográficas, para distinguir interrupções reais de falhas pontuais na rede local. Alcançar um tempo de atividade anual de 99,99% permite menos de 53 minutos de inatividade por ano; 99,999% permite pouco mais de cinco minutos. Um monitoramento eficaz do tempo de atividade vai além de simples verificações de ping para validar se as respostas contêm o conteúdo esperado, são concluídas dentro de uma latência aceitável e apresentam certificados TLS válidos — detectando as interrupções parciais e os estados de degradação que as verificações simples de disponibilidade não conseguem identificar.

A combinação de protocolos é tão importante quanto o intervalo de verificação. As verificações HTTP e HTTPS são fundamentais para qualquer ponto de extremidade voltado para a Web, com verificações de correspondência de conteúdo para detetar o modo de falha em que «a página devolve um código 200, mas na verdade está inoperacional». As verificações de portas TCP abrangem serviços não HTTP, como SSH, MySQL ou portas de aplicações personalizadas. As verificações de DNS confirmam que os registos são resolvidos corretamente a partir dos resolvers que os seus utilizadores realmente utilizam, detetando os casos de falha gradual em que um único resolver devolve NXDOMAIN enquanto tudo o resto parece estar bem. As verificações de protocolos de e-mail (SMTP, IMAP, POP3) mantêm o fluxo de e-mails transacionais. Uma configuração séria de monitorização de tempo de atividade utiliza o tipo de verificação adequado para cada camada de serviço, e não HTTP para tudo.

A verificação multirregional é a opção de configuração mais importante. Um monitor a funcionar a partir de um único local confunde uma falha momentânea na rede local com uma interrupção real, e os alertas tornam-se indistinguíveis — em menos de uma semana, a equipa de plantão aprende a ignorar as notificações. A realização de verificações de confirmação a partir de, pelo menos, duas regiões adicionais antes do envio do alerta elimina a grande maioria dos falsos positivos sem comprometer a rapidez da deteção. Xitoring executa todas as verificações a partir de mais de 15 nós de sondagem na América do Norte, Europa, Ásia-Pacífico, América do Sul e Médio Oriente, e um alerta só é disparado quando várias regiões concordam que o serviço está em baixo.

O encaminhamento de chamadas de plantão é o que distingue uma ferramenta de monitorização de uma ferramenta de alertas. O sinal gerado por uma verificação só é útil na medida em que chega ao engenheiro capaz de resolver o problema. Um monitoramento eficaz do tempo de atividade encaminha os alertas por níveis de gravidade (informação → aviso → crítico → notificar todos), respeita a rotação de plantão para que a pessoa certa seja acordada às 3 da manhã, suporta o reconhecimento e a escalonamento quando o responsável principal não responde e silencia de forma clara quando o incidente é resolvido. As notificações multicanal via SMS, push, Slack, Microsoft Teams, PagerDuty, OpsGenie e webhooks garantem que nenhum caminho de alerta seja um ponto único de falha.

As páginas de estado públicas transformam os dados de monitorização do tempo de atividade num elemento de confiança voltado para o cliente. Obter a página de estado diretamente a partir dos mesmos dados de monitorização que alimentam os alertas internos garante que nunca haja discrepâncias entre ambos — os seus clientes veem o que a equipa de plantão vê. Alojamento da página de estado num domínio ou subdomínio separado mantém-na acessível mesmo quando o serviço principal está em baixo, e as equipas de compras das empresas esperam cada vez mais um histórico contínuo de 12 meses do tempo de atividade. Xitoring publica tanto páginas de estado públicas com a marca da empresa para comunicação com os clientes como páginas de estado privadas protegidas por palavra-passe para acompanhamento interno do SLA a partir dos mesmos dados de tempo de atividade, sem necessidade de configuração adicional.

A monitorização do tempo de atividade é uma camada de uma pilha completa de observabilidade, não um substituto das outras. A monitorização do tempo de atividade observa a partir do exterior do perímetro — verifica se o ponto de extremidade público responde. A monitorização do servidor observa a partir do interior do sistema operativo — qual é o estado da CPU, da memória, do disco e dos processos do anfitrião que serve esse ponto de extremidade. A maioria das equipas de produção precisa que ambas as camadas funcionem em conjunto: o tempo de atividade indica quando um serviço está em falha; o servidor indica o motivo, antes que os utilizadores se apercebam. O Xitoring executa ambas as camadas no mesmo produto com um motor de alertas unificado, pelo que uma falha na base de dados e uma verificação HTTP falhada seguem as mesmas regras de notificação e acabam na mesma cronologia de incidentes.