Saltar para o conteúdo

Monitorização de API que apanha a resposta errada.

O seu endpoint de verificação de estado não deteta um fluxo de início de sessão avariado. A Uptimia inicia sessão, chama a API e verifica as respostas — para que receba o passo que falhou, não um pedido de assistência.

Teste gratuito de 30 dias · até 50 monitores de API Sem cartão de crédito Pronto para o RGPD
Intervalo mais rápido
60s
Localizações para confirmar
3
Sondas
171+
Países com sondas
70+

O pedido que voltou errado

Um fluxo de encomenda de cinco passos, executado por agendamento. O início de sessão, a consulta da encomenda e o total passam todos — o pedido seguinte não.

passo 1 Iniciar sessão — obter o tokenO início de sessão é bem-sucedido; o token devolvido fica guardado em {{token}} equipa: tranquila
passos 2–3 Chamar a API com eleGET /orders obtém {{order_id}}; a encomenda tem de mostrar o total correto equipa: tranquila
passo 4 A adição da nota à encomenda falhaA asserção identifica a falha: a nota nunca chegou a ser criada equipa: tranquila
14:32 Confirmado noutro local — e só então soa o alertaOutras localizações voltam a executar e confirmam; o alerta já indica o passo 4 alerta: com a causa
passo 4indicado no alerta
"O passo 4 falhou na verificação."14:32
É toda a investigação feita antes de abrir o portátil: o passo, a asserção e a confirmação de que não é uma sonda a ter uma má noite. A correção começa no pedido que falhou — não em "a API está em baixo".
passo com falha identificadoasserção exata citadaconfirmado a partir de outras localizaçõesestado · tempos · cabeçalhos · valores — por passo
E com apenas um ping? O /health continua a responder bem o tempo todo — um passo avariado no meio do fluxo nunca chega a tocar-lhe. O primeiro sinal é um cliente que não conseguiu concluir, seguido de uma caça aos registos para descobrir onde partiu. descoberto por um cliente

O que um ping nunca vê

Um pedido que é bem-sucedido mas devolve dados errados continua a ser uma falha, e um passo avariado três pedidos dentro do fluxo nunca chega a tocar no seu endpoint de verificação de estado. Aponte um monitor à sua própria API — ou às APIs de fornecedores de que depende, e saiba se a culpa é deles, não sua.

Códigos de estado e cabeçalhosA resposta esperada, em cada passo
Valores na respostaQualquer campo, verificado passo a passo
Falhas a meio do fluxoO passo 3 falha — um ping nunca o vê
Deriva na respostaFormato errado, campos em falta
15 passos por cadeia o fluxo completo, executado de verdade
A autenticação falhaTokens expirados, inícios de sessão rejeitados
Erros de TLS e de ligaçãoHandshakes e sockets recusados
Orçamento de tempo de respostaCada passo dentro do seu limite
Os alertas identificam o passo e a asserção que falhou: um pedido falhado, um valor errado na resposta, um campo em falta, um passo lento, um erro de ligação ou um início de sessão que deixou de funcionar. passo + asserção

Cadeias, asserções e tempos

O fluxo

Encadeie até 15 pedidos

Cada passo pode extrair um valor da resposta — um token, um id de encomenda — para uma variável que os passos seguintes reutilizam como {{name}}. Um único monitor cobre o percurso desde o início de sessão até à limpeza final.

  • 6 métodos HTTP — GET, POST, PUT, PATCH, DELETE ou HEAD, em qualquer ordem
  • Extraia para variáveis — referencie-as em qualquer passo seguinte como {{name}}
  • Cabeçalhos, corpo e tempo limite personalizados por passo — duplique um passo para construir depressa
Percorra o mesmo fluxo com um browser real
POST/auth/login1 asserção
GET/orders2 asserções
GET/orders/{{order_id}}3 asserções
POST/orders/{{order_id}}/notes1 asserção
DEL/sessions/{{token}}limpeza
Cadeia bem-sucedida1.94 s
Um único monitor executa todo o percurso — do início de sessão à limpeza — com uma frequência até de um minuto.
5 passos7 asserções2 variáveis
Um passo sem asserções passa na mesma quando o pedido é bem-sucedido — adicione verificações só onde importam. qualquer sucesso
Asserções

Verifique estado, valores e tempos

Adicione as verificações que um passo tem de cumprir: um estado exato, um orçamento de tempo de resposta, um valor no corpo da resposta, um cabeçalho ou texto na resposta. Quando uma falha, a execução mostra o que obteve — e Testar chama o endpoint real antes de guardar.

  • Estado e tempo de resposta — o passo falha se o código estiver errado ou a resposta demorar demasiado
  • Valores dentro da resposta — aponte a um campo e exija que esteja presente e correto
  • Cabeçalhos e texto do corpo da resposta — exija um valor de cabeçalho, ou texto que tem de estar presente ou ausente
Vigie o texto de uma página, não só o estado
Testar200 · 191 ms
GET /orders/8842 · passo 3 — a resposta em direto, obtida de verdade antes de guardar.
{
  "id": 8842,
  "status": "paid",
  "total": 4210
}
o estado é 200obteve 200
$.status é igual a "paid"obteve "paid"
tempo de resposta abaixo de 500 msobteve 191 ms
Extraído {{order_id}} = 8842 alimenta o passo seguinte — destacado na resposta em direto acima. = 8842
Tempos

DNS, TLS ou o seu próprio backend

"A API está lenta" nunca é a história toda. O tempo de cada passo é dividido em cinco fases — DNS, ligação, TLS, espera, receção — para que veja qual o passo que está a atrasar tudo e se a causa é a rede ou o seu backend.

  • Tempos em cinco fases por passo — DNS, ligação, TLS, espera, receção
  • Gráfico de tempo de resposta por passo — empilhado, com marcadores de incidentes
  • Passo mais lento e execuções mais lentas em destaque na página de detalhe do monitor
Tempos fase a fase para páginas web
Passo 4 — lento14:32:16
POST /orders/8842/notes · 1 389 ms no total, dividido em cinco fases.
dns18 ms
ligação31 ms
tls44 ms
espera1,284 ms
receção12 ms
Rede — sem problemas
dns 18 · connect 31 · tls 44
93 ms
Backend — o atraso
tempo de reflexão antes do primeiro byte
1,284 ms
Passo mais lento e execuções mais lentas ficam na página do monitor — um gráfico empilhado por passo mostra quando começou o atraso. mais lento
Segredos

Chaves de API reais, sempre ocultas

Guarde palavras-passe, chaves de API e tokens como variáveis secretas: só de escrita, ocultas na leitura e removidas de URLs, cabeçalhos e excertos de resposta reproduzidos. Nada sensível fica no histórico de execuções.

  • Variáveis secretas só de escrita — ocultas sempre que são lidas
  • Removidas onde quer que sejam reproduzidas — URLs, cabeçalhos e excertos do corpo
  • Valores extraídos que correspondam a um segredo também nunca são reproduzidos
Monitorize páginas atrás de um início de sessão
API_KEYsegredo
••••••••••••••••só de escrita
Guardado uma vez, nunca mais mostrado — uma leitura devolve value:'' · has_value:true.
Cabeçalho do passo 1 — o que configura
Authorization: Bearer {{API_KEY}}
Histórico de execuções — o que fica guardado
Authorization: Bearer [redacted]
Valores extraídos que correspondam a um segredo também nunca são reproduzidos — nada sensível chega ao histórico de execuções. ocultos

Encadeie os pedidos uma vez.Saiba sempre qual foi o passo que falhou.

Todos os passos, todas as asserções, todos os canais de alerta — grátis durante 30 dias, sem nenhum extra pago.

Comece o seu teste gratuito de 30 dias
30 dias grátis sem cartão de crédito cancele quando quiser

Como funciona a monitorização de API

Construa a cadeia, teste-a com a API em produção e a Uptimia executa-a por agendamento a partir da nossa rede — nada para instalar.

Passo 1construir

Encadeie os seus pedidos

Adicione cada pedido pela ordem certa, defina cabeçalhos e corpo, e extraia para variáveis os valores de que os passos seguintes precisam.

Passo 1 · pedido
POST /auth/login
extrair $.token → {{token}}
Passo 2 · pedido
GET /orders
Passo 2testar

Defina asserções e teste

Adicione as verificações que cada passo tem de cumprir e depois Teste contra o endpoint real — resultados completos por passo, antes de guardar.

Asserções · passo 3
o estado é 200$.status = "paid"
abaixo de 500 ms
Testar · 5/5 passos bem-sucedidos em 1,9 s
Passo 3a cada minuto

Executamos por agendamento

Uma sonda executa a cadeia toda numa única ida e volta, verifica cada asserção e guarda os resultados por passo — as falhas são confirmadas a partir de outras localizações antes de alertar.

Execução OK — 5/5 passos
14:31 · 1,8 s · todas as asserções passaram
a tempo
Execução falhada — passo 4
14:32 · esperava 201, obteve 500
a alertar

Também incluído

Slack, PagerDuty, SMS e mais 9

Um alerta de API indica o passo que falhou e a causa, entregue nos mesmos contactos que qualquer monitor da Uptimia usa — e-mail, SMS, Slack, Teams, Discord, PagerDuty, webhooks e mais.

passo 3 · $.status: esperava "paid", obteve "pending" → Slack · E-mail · PagerDuty

Confirmado a partir de outras localizações antes de alertar

Uma execução falhada é repetida primeiro a partir de outras localizações capazes.

repetido noutro local · confirmado antes de abrir

Duplique um passo

Construa uma cadeia longa rapidamente — copie um pedido e ajuste-o.

passo 3 → duplicar → passo 4

Exportação de RCA do incidente

Um incidente encerrado mantém o detalhe ao nível de cada passo — exporte-o.

RCAPDFHTML

Tempo limite, cabeçalhos e corpo por pedido

Dê a cada pedido o seu próprio tempo limite, cabeçalhos e corpo.

tempo limite 10 s · 20 cabeçalhos · corpo de 64 KB

Todos os tipos de monitor numa só conta

Os seus monitores de API ficam ao lado dos monitores de disponibilidade, SSL, heartbeat e DNS — os mesmos contactos, grupos e funções.

Checkout order flowAPI www.caldmont.comUPTIME db-backup · nightlyHEARTBEAT

O que é a monitorização de API?

A monitorização de API é um serviço automatizado que executa por agendamento uma sequência real de pedidos HTTP contra a sua API REST ou endpoint JSON e alerta quando um passo devolve o estado errado, os dados errados ou demora demasiado tempo. Vigia o fluxo por detrás de um endpoint, não apenas se o servidor respondeu.

Enquanto tudo funciona

Como funciona a monitorização de API?

Uptimia
executa a cadeia
5 passos · por agendamento
A sua API
todas as verificações passam

Uma sonda executa cada passo numa única ida e volta, avalia cada asserção e guarda os resultados por passo como histórico de execuções.

Quando uma verificação falha

Primeiro confirma, depois alerta

A sua API
passo 4 · falhou
nova execução · outras localizações
Uptimia
abre o incidente

o passo 4 falhou na verificação → o incidente é aberto, o alerta indica o passo

As verificações

O que verifica um monitor de API?

Por predefinição, um passo passa com uma resposta bem-sucedida. Adicione asserções e a execução tem de as comprovar — um estado exato, um orçamento de tempo de resposta, um valor na resposta, um cabeçalho ou texto no corpo.

Ferramenta gratuita: verifique o estado e os cabeçalhos de qualquer endpoint
VerificaçãoO que comprovaExemplo
Código de estadoo endpoint respondeu como esperadoé 201 · é um de 200/204 · qualquer 2xx
Tempo de respostao passo é suficientemente rápidoabaixo de 500 ms
Corpo JSONa resposta contém os dados certos$.status é igual a "paid"
Cabeçalhoo content type ou a regra de cache corretosContent-Type contém json
Texto do corpoum marcador está presente ou ausentecontém "order created"

Perguntas frequentes sobre monitorização de API

01O que é a monitorização de API?+
Um serviço automatizado que executa por agendamento uma sequência real de pedidos HTTP contra a sua API e verifica as respostas. Um único monitor da Uptimia encadeia até 15 pedidos e alerta quando um passo devolve o estado errado, os dados errados ou demora demasiado tempo. Também é conhecida como monitorização sintética de API ou verificação de estado automatizada da API.
02Em que é que isto é diferente de um simples ping de disponibilidade?+
Um ping diz-lhe que o servidor respondeu. A monitorização de API executa o fluxo completo e verifica a própria resposta — código de estado, tempo de resposta, cabeçalhos e os valores no JSON. Um 200 que devolve dados errados é apanhado aqui, mas é invisível para um simples ping.
03Com que frequência é que a Uptimia executa a minha verificação de API?+
Por predefinição a cada 5 minutos, e com uma frequência até de um minuto — a verificação de agendamento corre a cada minuto, por isso um minuto é o limite mínimo. Também pode reduzir a frequência de qualquer monitor para endpoints de menor prioridade.
04Quantos passos pode ter um monitor?+
Até 15 pedidos HTTP numa única cadeia, cada um com até 20 cabeçalhos, 15 asserções e 10 extrações de valores. O tempo limite por passo vai de 1 a 60 segundos, e a cadeia completa tem um orçamento de execução de 90 segundos.
05Executa JavaScript ou renderiza a página como um browser?+
Não. A monitorização de API envia pedidos HTTP simples — sem browser headless, sem JavaScript, sem capturas de ecrã. Para percorrer um fluxo renderizado com um browser real, use a monitorização de transações da Uptimia; a monitorização de API é a ferramenta mais leve e rápida para a própria API.
06Posso verificar um valor dentro da resposta JSON?+
Sim. Aponte um seletor JSONPath ao campo e afirme que existe, é igual a, contém ou é um de um conjunto de valores. Também pode extrair um valor para uma variável e reutilizá-lo nos passos seguintes como {{name}}. O suporte a JSONPath é um subconjunto focado nas respostas de API típicas.
07Suportam GraphQL ou WebSockets?+
O GraphQL funciona como um simples POST HTTP — envie a query no corpo e verifique o JSON devolvido — mas não existe um construtor específico para GraphQL. WebSockets não são suportados; a monitorização de API cobre pedido/resposta sobre HTTP (GET, POST, PUT, PATCH, DELETE, HEAD).
08Posso importar um comando cURL ou partir de uma receita?+
Não nesta versão. Cada passo é construído no editor — método, URL, cabeçalhos, corpo, asserções, extrações — e pode duplicar um passo para avançar mais depressa. A importação de cURL e uma biblioteca de receitas ainda não fazem parte da monitorização de API.
09Como evitam falsos alarmes?+
Uma execução falhada é repetida a partir de outras localizações antes de o incidente ser aberto — por predefinição, três localizações têm de concordar (a original mais duas repetições) antes de o alerta ser acionado. A recuperação é rápida no sentido inverso: uma única execução bem-sucedida encerra o incidente e envia o aviso de recuperação.
10As minhas chaves de API estão seguras dentro de uma verificação?+
Sim. Guarde as credenciais como variáveis secretas: só de escrita, ocultas na leitura e removidas de URLs, cabeçalhos e excertos de resposta reproduzidos — nada sensível chega ao histórico de execuções.
11A monitorização de API é um extra pago?+
Não. Todos os planos incluem monitorização de API a par da monitorização de disponibilidade, SSL, transações, DNS e heartbeat — nunca como um extra pago. Até o plano gratuito inclui um monitor de API; os planos diferem apenas na quantidade incluída, e o teste gratuito de 30 dias inclui até 50, sem necessidade de cartão de crédito.

Comece hoje a monitorizar a sua API.

Construa a cadeia, teste-a com o endpoint em produção — e da próxima vez que um passo avariar, o alerta já lhe diz qual foi.

Teste gratuito de 30 dias Até 50 monitores de API Sem cartão de crédito Pronto para o RGPD
A monitorização de API junta-se à monitorização de disponibilidade, SSL, velocidade, transações, DNS e heartbeat, tudo numa única conta Uptimia.