Monitoramento de links curtos com Sentry e Datadog: quem faz o quê

O monitoramento de link curto se divide claramente entre as duas ferramentas. O Sentry é para onde o Elido envia eventos de saúde de link: um destino que parou de responder, um link que expirou, um limite de clique que foi atingido, um domínio personalizado que falhou na verificação. O Datadog é para onde o Elido envia cliques, um log por visita e três métricas de contagem de clique por minuto. A latência de redirecionamento não vai para nenhum dos dois, porque o Elido não a exporta; você a mede de fora com uma sonda sintética.

Este post é a metade centrada no Sentry desse quadro, mais uma resposta direta para "qual ferramenta serve para o quê". Se você está aqui pelos painéis do Datadog, o guia de métricas de redirecionamento do Datadog cobre as métricas de clique, o formato do log e um painel de latência baseado em Synthetics em profundidade, então não vou repetir aqui.

Um pouco de contexto antes da conexão. Um redirecionamento pode estar perfeitamente saudável enquanto o link está morto: a URL curta responde em alguns milissegundos e manda as pessoas para uma página 404. É por isso que o monitoramento de URL para links curtos precisa de um sinal ciente do destino e de um sinal de velocidade, e por que nenhuma ferramenta única te dá os dois em um só feed. O detalhamento de p95 abaixo de 15ms explica como é o "saudável" do lado da velocidade.

O que o monitoramento de link curto precisa capturar

Eu separo as falhas em três grupos, porque cada um precisa de uma ferramenta diferente.

O link quebrou. O destino dele retorna um 4xx ou 5xx, dá timeout, ou o domínio parou de resolver. Seu redirecionamento ainda funciona, mas agora encaminha as pessoas para uma página de erro. O Elido encontra isso com uma checagem diária de destino e levanta link.broken.

O link parou por design. Ele atingiu a data de expiração ou o limite de clique, então o Elido parou de redirecioná-lo. Tecnicamente nada está errado, mas se uma campanha ainda aponta para ele, alguém precisa saber. Isso é link.expired e link.cap_reached. Um domínio personalizado que nunca se verificou levanta domain.ssl_failed, que pertence ao mesmo grupo.

O próprio redirecionamento ficou lento ou caiu. Esse é o sinal de velocidade, e é o que o Elido não emite como métrica. Você o observa de fora.

Tráfego é um quarto sinal, mas mais suave. Uma campanha que normalmente faz milhares de cliques por hora e de repente faz algumas dezenas geralmente significa que algo mudou a montante, como um anúncio pausado ou um adesivo de QR code que descolou. As contagens de clique vivem no Datadog, então é lá que fica o monitor de queda.

O que o Elido envia para o Sentry

O Sentry é um dos tipos de canal de saída no sistema de notificação do Elido, ao lado de Discord, Telegram e webhooks simples assinados. Ele viaja pelo mesmo pipeline de entrega que os webhooks, com uma diferença: em vez do evento bruto do Elido, ele posta um pequeno evento do Sentry.

Cada entrega é um evento JSON enviado ao endpoint de armazenamento do seu projeto, que o Elido deriva do DSN. Dado https://[email protected]/8, o alvo é https://o4711.ingest.sentry.io/api/8/store/ e a chave pública vai no header X-Sentry-Auth. Não há nenhum SDK do Sentry em nenhum ponto do caminho, e como o host do DSN é interpretado em vez de fixo no código, um servidor self-hosted compatível com o Sentry funciona da mesma forma. O payload segue o formato de payload de evento do Sentry:

{
  "event_id": "9f0c4e1b2a7d4c33b8e5d6a1f2c3b4a5",
  "timestamp": 1790000000,
  "level": "error",
  "logger": "elido",
  "platform": "other",
  "message": "<humanized event name, e.g. Link / Broken>",
  "environment": "production",
  "tags": { "event_type": "link.broken", "workspace_id": "42" }
}

O nível é escolhido a partir do nome do evento. Tudo que significa "esse link não está funcionando agora" chega como error: .broken, .expired, cap_reached, ssl_failed. Exclusões e rebaixamentos chegam como warning, todo o resto como info.

Agora a parte honesta sobre as tags. Todo evento carrega as tags event_type e workspace_id, e os campos environment e release são preenchidos quando você os define no canal. Um evento de limite atingido também carrega uma tag clicks. O evento de link quebrado, porém, não carrega o slug nem o destino como tags hoje, então a issue no Sentry te diz que um link no workspace 42 quebrou, e você abre a lista de links no Elido, onde o link quebrado carrega uma sinalização. Prefiro te dizer isso agora do que te deixar caçando uma tag slug às 2 da manhã.

Configurando um canal Sentry para alertas de link quebrado

A configuração leva alguns minutos e o DSN é a única credencial. O canal Sentry está marcado como Beta porque você cria o projeto no Sentry você mesmo; uma instalação em um clique pela plataforma de integração do Sentry está no roadmap, mas não foi construída, então hoje é colar um DSN.

1. No Sentry, crie um projeto, escolha a plataforma Other, e copie o DSN da tela seguinte. O explicador de DSN mostra qual parte é a chave e qual é o ID do projeto.
2. No painel do Elido, abra Notificações, adicione um canal, escolha Sentry, cole o DSN e, opcionalmente, um nome de ambiente como production.
3. Mantenha os eventos padrão ou escolha os seus. Os padrões são link.broken, link.expired, link.cap_reached e domain.ssl_failed.

O Elido verifica o DSN quando você salva: ele precisa ser http ou https, incluir uma chave pública, e terminar em um ID de projeto. Um DSN malformado é rejeitado ali mesmo em vez de falhar silenciosamente depois.

Se você gerencia configuração como código, o mesmo canal é uma única chamada de API. Canais são endpoints de webhook com um kind:

curl -X POST https://api.elido.app/v1/workspaces/42/webhooks \
  -H "Authorization: Bearer elido_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "sentry",
    "url": "https://[email protected]/8",
    "events": ["link.broken", "link.expired", "link.cap_reached", "domain.ssl_failed"],
    "description": "Link health to Sentry",
    "config": { "environment": "production", "release": "spring-campaign" }
  }'

As entregas para o Sentry não são assinadas com HMAC, já que o Sentry autentica a requisição pela própria chave. Elas recebem a política de retry normal: três tentativas no total, com as repetições cinco e quinze minutos depois de uma falha, e então a entrega é marcada como falhada. Você pode listá-las em /v1/workspaces/{workspace_id}/webhooks/{id}/deliveries e repetir uma manualmente.

Não há botão de teste para esse canal. O teste mais limpo que conheço: crie um link descartável com uma expiração de um ou dois minutos à frente e espere. O Elido escaneia por links recém-expirados a cada cinco minutos, então uma issue de nível error deve cair no Sentry logo depois.

Assim que os eventos de saúde de link chegam ao Sentry, a próxima pergunta é o que você vai fazer com eles, e isso depende de como o Sentry os agrupa. Se você ainda está escolhendo um plano, compare o que cada nível inclui antes de conectar o canal.

Como o Sentry agrupa os eventos de saúde de link do Elido

Esses eventos não têm stack trace nem exceção, então o agrupamento de fallback do Sentry os agrupa pela mensagem. Na prática isso significa uma issue por tipo de evento: todos os eventos de link quebrado viram uma issue cuja contagem de eventos sobe, todas as expirações outra.

Isso é útil para paginação e menos útil para triagem. Dois ajustes ajudam:

• Defina o ambiente no canal. Com canais separados por workspace ou por ambiente (production, campaigns), cada um ganha seu próprio filtro no fluxo de issues, e você pode delimitar regras de alerta para um deles.
• Adicione uma regra de fingerprint nas configurações do projeto Sentry em tags.workspace_id se você roteia vários workspaces para um único projeto e quer uma issue por workspace.

Para alertas, construa sobre as próprias regras de alerta de issue do Sentry: "uma nova issue é criada" captura o primeiro link quebrado, e "a issue é vista mais de N vezes em uma hora" captura um lote, digamos, uma campanha inteira cujo domínio de destino caiu. Tenha em mente o ritmo de detecção por trás disso. A checagem de destino roda uma vez por dia, a primeira falha dispara imediatamente, e um link que continua quebrado dispara de novo depois de 24 horas. O Sentry é a caixa de entrada certa para isso. Não é um detector de indisponibilidade de cinco minutos, e eu não fingiria o contrário.

Onde o Datadog entra no monitoramento de redirecionamento

O Datadog recebe cliques, não saúde de link. Cada clique vira um log enviado para a ingestão de Logs do seu site Datadog, com origem elido, tags workspace_id, vendor:elido e link_id, e os campos do clique sob attributes. Uma vez por minuto, o Elido também envia três gauges por workspace: elido.clicks, elido.clicks_by_country e elido.clicks_by_device.

O que não está lá importa tanto quanto. Nenhuma métrica de latência, nenhum código de status, nenhuma tag de domínio, nível ou região. Um POST de log que falha recebe uma nova tentativa e depois é descartado. As configurações ficam em cache por até cinco minutos, então uma chave recém-salva leva um momento para entrar em ação, e o botão Testar conexão do painel envia um log de teste e mostra a resposta do Datadog, o que detecta uma chave ou site errado, mas não um pipeline que descarta os logs, então um clique real ainda é a prova de que funciona.

Então o trabalho do Datadog aqui é tráfego: volume de clique por minuto, principais países, e um monitor para "cliques caíram para quase zero". O guia de monitoramento de URL do Datadog tem as queries, os passos de configuração e a página de integração lista os campos. Reconcilie os totais contra os analytics de clique do Elido, que continua sendo o registro da verdade.

Observando a latência de redirecionamento de fora

Para o sinal de velocidade, aponte uma checagem sintética para um link curto canário: um link que você cria apenas para monitoramento, para que as sondas nunca se misturem com os números de campanha. Os testes HTTP do Datadog fazem isso bem, e qualquer serviço de uptime que consiga pular redirecionamentos também funciona.

Três configurações decidem se o número significa alguma coisa:

• Desligue o seguimento de redirecionamento. Você quer o tempo até o 301 ou 302 voltar, não o tempo que sua página de destino leva para renderizar.
• Faça uma asserção sobre o código de status e o header Location, para que um redirecionamento para o lugar errado falhe a checagem.
• Envie um User-Agent contendo bot. O Elido pula eventos de clique para agentes de bot conhecidos, então sua sonda não vai inflar as contagens de clique.

Rode a sonda a partir de locais próximos ao seu público. Um redirecionamento com cache-hit na região deveria ficar bem abaixo do orçamento de p95 de 15ms, e um salto sustentado vale um alerta. Uma checagem contra o seu domínio personalizado também te diz se o certificado TLS dele ainda funciona, algo que um encaminhador de clique jamais poderia dizer.

Qual ferramenta para o quê

Aqui está a divisão que eu configuraria para uma equipe rodando campanhas pagas em links curtos:

Uma equipe pequena pode começar só com o canal Sentry; ele cobre as falhas que silenciosamente desperdiçam gasto com anúncios. Adicione o Datadog quando alguém realmente olhar painéis de tráfego, e adicione a sonda no dia em que um redirecionamento lento custaria dinheiro. Se o Sentry não é a caixa de entrada da sua equipe, os mesmos eventos de saúde de link vão para Discord ou Telegram, e um link quebrado também pode abrir um ticket no Linear.

Leia o conteúdo principal → Atingindo p95 abaixo de 15ms para redirecionamentos

Relacionados no blog

• Monitoramento de URL do Datadog para links curtos - métricas de clique, logs e um painel de latência com Synthetics.
• Estratégia de prevenção de link rot - o que fazer depois que uma issue de link quebrado cai.
• Alertas de Discord e Telegram para links curtos - os mesmos eventos de saúde de link em um canal de chat.
• Tickets do Linear a partir de alertas de link - transformando um link quebrado em uma tarefa rastreada.