pnclENGINEObter acesso à API

MONITORAMENTO

Monitorando um pipeline de odds da Pinnacle.

Um pipeline que faz polling da API de odds da Pinnacle falha em silêncio com mais frequência do que com barulho: os preços param de se mover, um cursor trava, um worker entra em backoff e nunca volta. Cinco métricas pegam essas falhas, e cada limiar decorre do intervalo de polling e do plano em que você está.

As cinco métricas

Registre-as por quadro, ou seja, por esporte e fase, porque um quadro de tênis ao vivo e um quadro de futebol pré-jogo falham de forma independente. Um contador por polling basta para derivar as cinco.

MétricaComo medirAlertar quando
Idade do snapshotSegundos desde o último polling que devolveu um envelope válidoAcima de três intervalos de polling durante uma grade
Avanço do cursorO valor last de cada resposta, comparado com o anteriorInalterado por 30 minutos enquanto há eventos do quadro em andamento
Latência do pollingTempo da requisição até a resposta parseada, p50 e p95p95 acima de 2 segundos por 10 minutos
Taxa de erroRespostas por status por hora: 2xx, 429, 5xx, timeouts429 acima de 1% das requisições, ou qualquer 401 ou 403
Taxa de requisiçõesRequisições por segundo no pico, e por dia na chave gratuitaAcima de 70% do teto do plano, ou 90 das 100 gratuitas por dia

A idade do snapshot é a que importa

Toda outra falha acaba aparecendo aqui, e é por isso que a idade é a métrica para colocar na parede. Calcule-a a partir do último polling bem-sucedido e validado, não da última tentativa: um poller que recebe 5xx a cada dez segundos está tentando o tempo todo e nunca tendo sucesso. Exponha o mesmo número aos seus consumidores ao lado dos preços, para que um dashboard possa rotular um quadro desatualizado em vez de mostrar preços antigos como atuais. A mesa de partidas pública do pnclHUB faz exatamente isso, retendo os preços quando a atualidade da fonte não está confirmada em vez de mostrá-los com uma ressalva.

O limiar escala com o intervalo. Fazendo polling dos quadros ao vivo a cada 5 segundos, alerte em 15; pré-jogo a cada 30, alerte em 90. Fora de uma grade, um quadro sem eventos pode ficar quieto de forma legítima, então condicione o alerta a o quadro ter eventos cujo horário de início já passou.

Avanço do cursor e o delta vazio

O cursor since faz um polling devolver só o que mudou, e um quadro ao vivo saudável devolve algo na maioria dos ciclos. Um cursor que para de avançar enquanto há partidas em andamento significa uma de três coisas: o poller está enviando um cursor antigo, a resposta está sendo descartada antes de o cursor ser armazenado, ou o próprio feed travou. Registre o cursor a cada polling e as duas primeiras ficam visíveis em um minuto. A disciplina de polling em integração REST cobre onde o cursor deve morar para que um reinício retome a partir dele.

Métricas de orçamento

Requisições por segundo contra o teto é o número que prevê os 429 de amanhã. Mantenha o estado estável abaixo de 70% da taxa do plano, 7 por segundo no plano de 10 por segundo e 21 no de 30 por segundo, e trate o pico de um dia de jogos como o valor a comparar, já que as rejeições chegam quando os quadros estão mais movimentados. Na chave gratuita, a contagem diária é a que vale acompanhar: em 90 das 100 requisições diárias, pare as chamadas opcionais para que as agendadas terminem o dia. A aritmética por trás do pico está na página de planejamento de capacidade.

De onde vêm os números

Uma linha de log estruturada por polling carrega tudo: quadro, status, latência, cursor antes e depois, contagem de eventos. Uma camada de métricas pode derivar as cinco séries dessas linhas, e uma busca nos logs responde às perguntas que um dashboard não consegue, como qual quadro produziu o primeiro 429 no sábado. Nomeie as séries com clareza, odds_poll_age_seconds, odds_poll_latency_seconds, odds_poll_total com um rótulo de status, e um engenheiro novo lê o dashboard sem legenda.

{"board": "soccer/live", "status": 200,
 "latency_ms": 412, "since": 141, "last": 158,
 "events": 7, "at": "2026-09-29T14:03:10Z"}

Adicione uma verificação sintética que lê o seu próprio armazenamento, não a API: busque um evento conhecido no cache a cada minuto e confirme a idade dele. Isso pega a falha em que o poller roda mas os consumidores não enxergam o trabalho dele. Se o poller também usa o stream SSE, conte as reconexões por hora no mesmo dashboard; o guia de configuração do SSE no pnclPULSE descreve como é um ciclo de reconexão saudável.

Ver planos de capacidade

Perguntas que isso levanta

A idade do snapshot é o mesmo que a idade dos dados do fornecedor?

Não. A idade do snapshot mede o seu poller. A atualidade do próprio feed é outra questão, e a documentação descreve o pré-jogo atualizando a cada 30 segundos, mais ou menos, enquanto os preços ao vivo chegam em uma fração de segundo. Acompanhe as duas quando puder.

Quanto histórico as métricas devem guardar?

Duas semanas em resolução completa cobrem dois fins de semana, que é onde estão os picos. Uma retenção mais longa pode ser reduzida a máximos por hora.

Preciso das cinco na chave gratuita?

A idade e a contagem diária de requisições bastam para um protótipo. Adicione o resto quando o poller passar para um plano pago e um teto por segundo.

As cotas e os valores de atualização seguem a documentação publicada pelo fornecedor, conferida em 26 de setembro de 2026. Publicado em .