Como configurar monitoramento de API na HostTracker

Configurações Principais

Não existe captura de tela dessa seção para o tipo API, mas ela usa os mesmos controles compartilhados de todo outro tipo de verificação. Monitoramento ativado é a chave geral de ligar/desligar. Agenda por intervalo (1 minuto a 24 horas, controle deslizante ou menu suspenso) ou um construtor de Agenda cron (a cada N minutos/horas, diário, semanal, mensal, ou uma expressão personalizada, só em plano pago) controla com que frequência a verificação roda. Timeout é de 1 a 100 segundos; o tempo de resolução DNS não é contado. Tags são rótulos separados por vírgula para agrupar e filtrar. Log Completo salva todo resultado em vez de agrupar consecutivos idênticos, e Estatísticas Abertas publica as estatísticas e o log da tarefa em um link público. Diferente do HTTP, o formulário de API não tem a chave DNSBL (DNSBL só persiste para Http/Ping/Port); ele carrega os mesmos cartões de Vencimento de Domínio, Vencimento de Certificado e Web Risk, cada um rodando a cada 12 horas - lembretes de vencimento seguem as suas inscrições de No Ar abaixo, um resultado ruim segue Fora do Ar/Repetir.

Configuração da Requisição

• Método HTTP - GET, HEAD, POST, PUT, DELETE ou PATCH. GET (padrão) é necessário para ler e analisar um corpo de resposta; HEAD busca só os cabeçalhos.
• Corpo da requisição (só POST/PUT/PATCH) - Corpo bruto envia exatamente o que você digita (adicione o seu próprio cabeçalho Content-Type para descrever json/xml/texto puro); Parâmetros POST aceita um CHAVE=VALOR por linha e é enviado como um corpo form-urlencoded.
• Comportamento de redirecionamento - Resposta imediata julga a primeira resposta como está; Seguir redirecionamentos (padrão) segue a cadeia, com um controle deslizante de Máximo de redirecionamentos a seguir (1-20); Redirecionamento é erro falha em qualquer redirecionamento (indisponível sob o modo de asserções).
• Cabeçalhos HTTP - pares nome/valor personalizados, com sugestões de datalist para nomes e valores comuns de cabeçalho de API (Content-Type, Authorization, X-API-Key, prefixos Bearer/Basic e mais). Deixado vazio, a sondagem envia cabeçalhos padrão (User-Agent, Accept, Accept-Language, um Referer).
• Autenticação de requisição - revela usuário/senha para a própria autenticação por desafio HTTP do servidor (Basic, Digest, NTLM, Kerberos, Negotiate). Para um token bearer ou chave de API, adicione um cabeçalho Authorization acima em vez disso.
• Seleção de Servidor DNS - Servidores DNS padrão nas localidades; Servidores DNS públicos do país da localidade; ou Servidores DNS definidos manualmente (os seus próprios IPs de resolvedor). As duas últimas precisam de um plano pago.
• Desativar cache DNS - força uma consulta DNS nova a cada verificação em vez de reutilizar o cache do agente.

Validação de Resposta

Por padrão, uma verificação tem sucesso quando o DNS resolve, a conexão e o handshake TLS (para https) se completam, o servidor devolve um status HTTP Ok, e a resposta é interpretada no formato selecionado abaixo.

• Modo de asserções - a captura de tela mostra desligado, com um banner convidando você a ativá-lo para regras de código de status, tempo de resposta, cabeçalho ou conteúdo do corpo. API e HTTP são os únicos dois tipos de verificação com um editor de asserções funcional; veja o mergulho profundo no modo de asserções para a linguagem de regras completa. Enquanto está desligado, os campos clássicos abaixo conduzem o veredito.
• Ignorar Erros HTTP - códigos de status que NÃO deveriam falhar a verificação, por exemplo 401, 403, 500; vazio significa que todo código 400+ é um erro.
• Erro nestes status HTTP - o inverso: códigos que deveriam falhar a verificação mesmo que normalmente não falhassem.
• Formato de resposta - como o corpo é interpretado antes de o seletor rodar: análise JSON (seletor JSONPath ou de propriedade, mostrado selecionado na captura de tela), análise XML (consulta XPath), ou análise de String (regex com captura). GET é necessário para ler um corpo.
• Seletor - escolhe um valor da resposta interpretada; deixe vazio para usar a resposta inteira como o valor.
• O que verificar - por padrão a condição abaixo julga o próprio valor selecionado (Verificar o próprio valor obtido); mude para Verificar a mudança do valor entre verificações, ou uma taxa de mudança por segundo/minuto, para julgar quanto o valor se moveu em vez disso.
• Condição - compara o valor: qualquer (sem validação) (padrão, mostrado na captura de tela), igual a, diferente de, no conjunto de, fora do conjunto, menor que, menor ou igual, maior que, maior ou igual, dentro do intervalo, fora do intervalo, ausente no conteúdo, ou json nulo. Toda condição exceto as duas últimas precisa de um valor de comparação digitado abaixo dela.
• Políticas HTTP - as mesmas verificações opcionais de cabeçalho/cookie/conteúdo do tipo de verificação HTTP: Impor HTTPS, cabeçalho HSTS, sem rebaixamento de https para http, CSP, proteção contra clickjacking, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, sem divulgação de versão, asserções de Cache-Control, cabeçalhos de resposta CORS, segurança de cookie e conteúdo misto. Os predefinidos Básico, Estrito e API substituem a seleção inteira; uma violação conclui a verificação como Fora do Ar como qualquer outra falha.
• Handshake TLS - quatro chaves de rigor (plano pago): exigir uma cadeia de certificado SSL válida, exigir TLS 1.2 ou superior, bloquear cifras fracas (128 bits ou menos), e verificar revogação de certificado.
• Validação de IPs esperados - confirma que o DNS resolve o seu host para um dos IPs que você lista em toda verificação, pegando sequestro ou um registro desatualizado mesmo enquanto algum servidor ainda responde.
• Tamanho máximo de resposta - para de ler o corpo além desse tamanho, então o interpretador e o seletor só veem a parte baixada. Padrão 1 MB, máximo 10 MB; 0 não lê nenhum corpo.

Uma nota sobre as capturas de tela acima: elas foram tiradas em uma conta cujo pacote não inclui o tipo de verificação API, então o campo de seleção de tipo ali lia "não está no seu pacote". Isso é um artefato da conta de teste, não algo que você vai ver - todo campo e padrão descrito aqui é, fora isso, exatamente o que o formulário mostra.

Inscrições de Alerta

Compartilhado por todo tipo de verificação. Fora do Ar = o endpoint falhou na verificação, No Ar = se recuperou, Repetir = lembretes enquanto continua fora do ar. Inscrever todos os contatos nos eventos No Ar/Fora do Ar é um atalho; a tabela dá controle por contato, individualmente ou por meio de predefinições de grupo de contato reutilizáveis. Uma tarefa sem nenhuma inscrição de alerta ainda roda e registra resultados - só nunca notifica ninguém.

Inscrições de Relatório

Relatórios periódicos de uptime, só por e-mail. Escolha Diário, Semanal ou Mensal por contato; Mensal também inclui resumos Trimestral e Anual. A chave de inscrever-todos funciona da mesma forma que em Inscrições de Alerta.

Localidades de Monitoramento

• Seletor de localidade - busque ou navegue pela árvore de região/país e marque localidades para verificar a partir delas; cada linha mostra agentes disponíveis versus agentes selecionados. "Copiar localidades de outra tarefa" reutiliza um conjunto existente.
• Estratégia de reverificação - em uma transição de estado (por exemplo, No Ar para Fora do Ar), várias localidades a reverificam antes de o novo estado ser aceito, protegendo contra um falso positivo de uma região. Opções: votação por maioria padrão; um número especificado de localidades confirmando Fora do Ar (adiciona um controle deslizante de 1 a 7); sem reverificação; concordância total de toda localidade de reverificação; ou concordância total para Fora do Ar, votação por maioria para No Ar.
• Se as localidades selecionadas estiverem indisponíveis - Somente localidades selecionadas (padrão) espera em vez de arriscar um alerta falso; Localidades mais próximas usa a localidade disponível mais próxima; Qualquer localidade recorre a qualquer lugar do mundo.

Exemplo prático

Monitorando um endpoint de status JSON: verificação de API, intervalo de 5 minutos, timeout de 40s, GET, Seguir redirecionamentos (máximo 20). Formato de resposta análise JSON, Seletor $.status, O que verificar "o próprio valor obtido", Condição "igual a" com valor de comparação ok. Ignorar Erros HTTP deixado vazio. Localidades de Monitoramento deixadas em Todo o mundo com a estratégia de reverificação padrão. O e-mail da equipe de plantão inscrito em Fora do Ar, No Ar e Repetir, e em relatórios Semanais.

Solução de problemas

• A verificação sempre passa mesmo com o endpoint claramente quebrado - a Condição vem por padrão como qualquer (sem validação), que só julga a interpretação e o transporte, não o valor em si. Escolha uma condição e um valor de comparação reais assim que você souber como é uma resposta saudável.
• O Seletor não devolve nada - confirme se o Formato de resposta bate com o que o endpoint devolve (JSON vs XML vs texto puro); um seletor JSONPath contra um corpo XML nunca combina. Deixe o Seletor vazio primeiro para confirmar que a resposta inteira chega, depois vá estreitando.
• Uma Condição numérica (maior que, dentro do intervalo, etc.) dá erro - ela precisa que o valor selecionado converta para um número. Um seletor apontando para uma string, ou um cálculo em modo de mudança sem uma verificação anterior ainda, não dá nada para comparar.
• Ficou Fora do Ar logo depois de ativar as Políticas HTTP (especialmente Estrito) - o Estrito espera cabeçalhos que muitas APIs não configuraram. Corrija os cabeçalhos, desça para Básico, ou rode as políticas como uma tarefa separada primeiro.
• O seletor para de encontrar um valor em uma resposta grande - o Tamanho máximo de resposta corta o corpo, então nada depois do corte chega ao interpretador ou ao seletor. Aumente-o.

Relacionados

• Monitoramento e validação de API - a página de produto para esse tipo de verificação.
• Verificação HTTP/API instantânea gratuita - rode uma verificação avulsa sem precisar de conta.
• Regras de validação de resposta do modo de asserções - a linguagem de regras completa por trás da Validação de Resposta.
• API da HostTracker - automatize a gestão de monitores a partir do seu próprio código.
• Documentação da API v2 - a referência completa da API usada para construir integrações.
• 429 Too Many Requests - o status que uma API devolve quando o chamador está com limite de taxa, e o que fazer sobre isso.
• Todos os guias de monitoramento - o guia de configuração para todo outro tipo de verificação.