Se um link curto devolve 5xx durante 30 segundos no meio de uma campanha no Instagram, perde aproximadamente 4-7% da coorte. A maioria das equipas de engenharia fica a saber na manhã seguinte quando alguém cola um screenshot do Slack. Este guia é o playbook que usamos na Elido para detetar falhas de redirecionamento em menos de 60 segundos com duas ferramentas que provavelmente já paga: Sentry para issues e Datadog para métricas. É a mesma configuração que usamos nos nossos próprios edge POPs, que servem cerca de 240 milhões de redirecionamentos por mês a um p99 de 13 ms.
Em resumo: o Sentry faz uma coisa muito bem no contexto dos redirecionamentos, e essa coisa é "um issue por destino quebrado, com a lista dos slugs que o atingiram." O Datadog faz a coisa ortogonal: séries temporais. Quer ambas, e o Elido emite para ambas de forma nativa. O Sentry está atualmente em Beta (cole um DSN e está feito); o Datadog está Live com um coletor de métricas dedicado. A seguir: quais os sinais que importam, como funciona internamente a integração com o Sentry e o que deve conter realmente um dashboard do Datadog para a saúde dos redirecionamentos.
Que sinais importam na monitorização de redirecionamentos
Antes de configurar seja o que for, decida o que realmente lhe interessa. A monitorização de redirecionamentos é um problema mais estreito do que APM completo, e o conjunto de sinais é pequeno. Quatro sinais cobrem cerca de 95% dos incidentes reais:
Eventos de redirecionamento 4xx. Um 404 num link curto é quase sempre uma de três coisas: um slug foi eliminado, um slug expirou, ou alguém está a fazer fuzzing do seu domínio. Um 410 é intencional e ruidoso, por isso suprimimo-lo dos alertas. Um 451 (bloqueio geográfico) só é interessante em agregado. O volume de 4xx por evento é demasiado ruidoso para gerar pages; trate-o como uma métrica, não como um issue.
Eventos de redirecionamento 5xx. Estes justificam uma chamada ao engenheiro de plantão. Um 5xx significa que o edge não conseguiu alcançar o Redis (cache L2), não conseguiu alcançar o api-core (gRPC de origem), ou que o URL de destino teve uma falha de DNS durante um HEAD-check. Cada caso tem um runbook diferente. O transformer do Sentry em api-core etiqueta a causa raiz para que o título do issue seja algo como 5xx: redis-timeout (12 slugs afetados, última ocorrência há 14s) em vez de um genérico Internal Server Error.
Latência edge p99. Um redirecionamento com cache HIT deve ser servido em menos de 15 ms no p99 a partir de qualquer um dos nossos três POPs. Alertamos se o p99 se mantiver acima de 50 ms durante 5 minutos. O motivo é que uma única consulta lenta não eleva o p99 durante 5 minutos, mas uma réplica Redis a perder sincronização já sim. Consulte redirect p95 abaixo de 15 ms para o detalhamento do orçamento de latência.
Anomalia na taxa de cliques e falha de scan. As anomalias na taxa de cliques são o sistema de alerta tardio. Se uma campanha faz normalmente 4000 cliques/hora e subitamente faz 200, algo a montante quebrou (o seu anúncio foi reprovado, o seu autocolante QR descou, alguém removeu o link errado). As falhas de scan vêm do serviço url-scanner, que analisa os destinos à procura de malware. Um pico de falhas de scan normalmente significa que uma conta foi comprometida e está a criar links de phishing.
Encaminhar os sinais para a ferramenta certa
Nem todos os sinais pertencem a todas as ferramentas. Enviar volume de 4xx para o Sentry como issues vai enterrar o issue real de "destino quebrado" sob o ruído. Enviar latência p99 para o Sentry como alertas é inconveniente porque o sistema de alertas do Sentry está construído em torno da frequência de issues, não de séries temporais. O modelo mental: Sentry = exceções, Datadog = métricas, Slack = humanos, Linear = tickets de seguimento.
O Elido emite onde está o X. Não enviamos eventos 4xx para o Sentry porque não são exceções. Também não enviamos cada evento de clique para o Datadog porque o volume não justifica o custo (as métricas personalizadas do Datadog são faturadas por combinação única de etiquetas, e a cardinalidade de slug x região x tier custaria $4000/mês para um workspace de média dimensão). A divisão acima é a que adoptámos após 9 meses a operar o sistema internamente.
Integração com Sentry: colar o DSN e o envelope transformer
A integração Sentry no Elido está em Beta mas funcionalmente completa. A configuração são três cliques. Vai a /integrations, encontra o Sentry, cola um DSN e escolhe que tipos de eventos reencaminhar. O DSN é o único segredo. Armazenamo-lo no Postgres com cifra de envelope (KMS-wrapped segundo ADR-0036) para que mesmo os nossos administradores de DB não o possam ler em bruto.
O que acontece por baixo é que o api-core tem um webhook transformer que escuta o bus de eventos interno (tópico Redpanda redirect.errors) e empacota os eventos correspondentes em envelopes Sentry. O formato de envelope está documentado na especificação de envelope do Sentry - é simplesmente um HTTP POST com uma linha de cabeçalho JSON, um cabeçalho de item JSON e um payload de item JSON, separados por newlines. Não existe SDK do Sentry no caminho dos pedidos. Isto mantém o código edge (services/edge-redirect) pequeno e evita uma dependência no hot path.
O transformer faz três coisas úteis:
Fingerprinting. O Sentry agrupa eventos por fingerprint. Um fingerprint ingénuo agruparia todos os 5xx num único issue gigante, o que é inútil. O nosso transformer cria fingerprints por error_class:destination_host, de modo que um timeout Redis em links apontando para acme.com é um issue separado de um timeout Redis em links apontando para globex.com. Isso torna o princípio "um destino quebrado = um issue" realmente verdadeiro.
Agregação de slugs. Cada evento Sentry carrega um bloco tags com a lista dos primeiros 50 slugs afetados, o ID do workspace e o domínio de redirecionamento. Quando 800 slugs partilham um destino e esse destino começa a devolver DNS NXDOMAIN, vê um issue com slugs_affected: 800 e uma amostra de 50, não 800 alertas separados.
Rate limiting por workspace. Um workspace a executar uma campanha deficiente pode gerar 10.000 erros 5xx em 60 segundos. O Sentry vai aceitar todos e faturá-los. O transformer limita a 50 envelopes por minuto por workspace e agrupa o resto num único evento "suppressed" com uma contagem. Aprendemos isso da forma difícil quando um cliente apontou 4 milhões de links curtos para um domínio que começou a devolver 503.
Se preferir tratar a ingestão por conta própria em vez de usar o transformer da Elido, o guia de observabilidade cobre o caminho alternativo: subscreva o nosso bus de eventos webhook e converta os eventos em envelopes Sentry na sua própria infraestrutura. A maioria das equipas não se dá a esse trabalho. O transformer é mais rápido de adotar do que de construir.
Uma nota sobre o que aparece como "issue": a UI do Sentry trata cada evento agrupado como um cartão de issue com uma sparkline, um evento de exemplo e uma lista de etiquetas. Para erros de redirecionamento, a etiqueta mais útil é cache_result (HIT, MISS, BYPASS). Se vir uma vaga de 5xx com cache_result: BYPASS, provavelmente alguém na sua equipa fez deploy de uma alteração que forçava o bypass da cache para testes e se esqueceu de reverter. História verdadeira, aconteceu duas vezes no último ano.
Integração com Datadog: coletor de métricas e dashboards
O Datadog está Live. A configuração também são três cliques, mas a arquitetura é diferente. Em vez de um transformer por evento, corremos um coletor de métricas no lado do api-core que agrega a telemetria de redirecionamento no formato de métricas do Datadog e submete lotes de 10 em 10 segundos através da API de métricas personalizadas do Datadog. O coletor pré-agrega para nunca submeter eventos em bruto. Isto mantém baixa a cardinalidade das métricas personalizadas e a fatura do Datadog sob controlo.
As métricas que emitimos por omissão:
elido.redirect.count- contador, etiquetado por domain, tier, region, cache_result, status_class (2xx/3xx/4xx/5xx)elido.redirect.latency.ms- distribuição, etiquetada por domain, tier, region, cache_resultelido.click.count- contador, etiquetado por domain, tier (deduplicado na fronteira do click-ingester)elido.scanner.failure.count- contador, etiquetado por reason (malware, phishing, expired_cert, dns_nxdomain)
As etiquetas são a alavanca. Pode consultar "latência p99 para link.acme.com em FRA nas últimas 4 horas" com uma query de uma linha. Não precisa de pré-construir dashboards para cada domínio. Consulte /integrations/datadog para a referência de métricas e taxonomia de etiquetas.
Os quatro painéis acima são os que colocamos no nosso próprio ecrã de NOC. Cobrem a vista diária de plantão. Latência p99 do edge por região deteta regressões ao nível do POP (um problema no Hetzner FRA tem um aspeto diferente de um problema no OVH SGP, e quer vê-los lado a lado). Taxa de erro por domínio top-10 expõe os clientes ruidosos - se acme.com está a 8% de 5xx e todos os outros a 0,02%, não tem um problema da Elido, tem um problema da acme. Volume de cliques por tier (f / s / b para free, starter, business via isolamento por tier) indica se um pico de tráfego vem de um tenant pagante ou de uma campanha de tier gratuito que deveria ser limitada. Contagem de redirecionamentos quebrados nas últimas 24h é a métrica de encerramento - um redirecionamento que devolveu 4xx deve ter sido corrigido ou expirado e removido em 24 horas; consulte prevenção de deterioração de links para o caminho de reparação automática.
Limiares de alerta recomendados (estes são os nossos valores por omissão; pode substituí-los por workspace):
elido.redirect.latency.msp99 > 50 ms sustentado 5 min - chamar plantãoelido.redirect.count{status_class:5xx}taxa > 0,5% sustentada 2 min - chamar plantãoelido.redirect.count{status_class:4xx}taxa > 5% sustentada 10 min - apenas Slackelido.scanner.failure.counttaxa > 10/min para um workspace - revisão de segurança, sem page
O limiar de 0,5% para 5xx é conservador. A nossa linha de base é ~0,01% (principalmente falhas de DNS nos destinos dos clientes), por isso 0,5% é um desvio de 50x, o que é real.
Quando usar cada um
Para uma equipa pequena a operar um produto orientado para programadores em /solutions/developers, o Sentry por si só provavelmente chega. Será alertado para 5xx reais, verá os issues e vai corrigi-los. Não terá a cultura de dashboards que faça o Datadog valer $1,50/host/mês de overhead.
Para uma empresa maior em /solutions/enterprise com uma rotação de plantão SRE, quer ambos. Sentry para o fluxo de issues, Datadog para os dashboards, alertas de Slack ligados ao PagerDuty para o page. O guia de observabilidade explica o mapeamento de serviços do PagerDuty se seguir esse caminho.
Para todos os que estão no meio, a nossa recomendação é: Sentry no primeiro dia (o tier gratuito do Sentry serve para menos de 5000 eventos/mês), Datadog quando começar a ter mais de um domínio de redirecionamento ou mais de uma região de tráfego. A fatura do coletor de métricas do Datadog num workspace Elido Business típico é de cerca de $35/mês, que é o preço de um engenheiro não ter de fazer grep nos logs nginx num domingo.
O que isto dá que os monitores de uptime genéricos não oferecem
Um check do Pingdom ou UptimeRobot em f.elido.me diz-lhe se o edge está ativo. Não lhe diz que o destino do slug summer24 começou a devolver DNS NXDOMAIN há 12 minutos, ou que o p99 em SGP está 4x acima do p99 em FRA porque um líder de partição do Redpanda reiniciou. A monitorização de redirecionamentos é um problema consciente do destino. O próprio redirecionamento pode estar saudável enquanto o link está morto.
A combinação Sentry + Datadog acima dá-lhe visibilidade consciente do destino sem escrever sondas personalizadas. O Sentry diz-lhe o que está quebrado ao nível do destino. O Datadog diz-lhe o que está a degradar ao nível do edge. O Slack informa as pessoas, o Linear guarda o seguimento. A configuração é colar-um-DSN para o Sentry e um único fluxo OAuth para o Datadog. Comece com o Sentry hoje; adicione o Datadog quando a contagem dos seus domínios de redirecionamento ultrapassar um.
Para preços e o que cada tier inclui em termos de integração, consulte /pricing. Para a superfície de API em torno das subscrições de eventos se quiser construir a sua própria, /features/analytics e o detalhamento do Sentry em 12 serviços Go cobrem a taxonomia de eventos.
Perguntas frequentes
O que é a monitorização de links curtos e por que é importante?
A monitorização de links curtos é a prática de vigiar a camada de redirecionamento à procura de respostas 4xx/5xx, regressões de latência e padrões de clique anómalos. Um link curto quebrado é invisível para a sua monitorização de aplicação porque a falha acontece no edge antes de o tráfego chegar à sua origem. Se executar campanhas pagas em domínios de redirecionamento, mesmo 30 segundos de 5xx queimam orçamento publicitário que não consegue recuperar.
Devo enviar erros de redirecionamento para o Sentry ou para o Datadog?
Envie para ambos, mas com propósitos diferentes. O Sentry é excelente a deduplicar um destino quebrado num único issue com a lista dos slugs afetados, que é exatamente o que um engenheiro de plantão precisa às 3 da manhã. O Datadog é a casa certa para séries temporais como latência p99 do edge por região ou volume de cliques por tier, que é o que um SRE analisa num ecrã no escritório.
Qual é um p99 saudável para redirecionamentos de links curtos?
Nos edge POPs da Elido em FRA, ASH e SGP, um redirecionamento com cache HIT é servido em menos de 15 ms no p99. Um cache MISS que cai até ao api-core demora tipicamente 25-40 ms. Alertamos para qualquer valor sustentado acima de 50 ms durante 5 minutos, porque isso normalmente indica um problema regional e não uma única consulta lenta.
Como é que o Elido envia eventos para o Sentry sem instalar o SDK completo?
O Elido emite envelopes diretamente para o endpoint de ingestão HTTP do Sentry usando o formato de envelope público. Cole um DSN na página de integrações e o webhook transformer do Elido em api-core empacota os eventos 4xx/5xx em JSON compatível com o Sentry. Sem SDK para incorporar, sem agente para correr - o DSN é o único segredo que gere.
Posso monitorizar um domínio personalizado separadamente do domínio partilhado f.elido.me?
Sim. O coletor de métricas do Datadog etiqueta cada redirecionamento com o domínio, o tier (f/s/b), a região e o resultado da cache. Pode assim representar graficamente a taxa de erro por domínio ou comparar o p99 entre o seu domínio personalizado e o tier gratuito partilhado sem escrever qualquer código próprio.
Experimente Elido
Cole uma URL, obtenha um link curto
Sem cadastro. O link vive 30 dias. Cadastre-se para mantê-lo para sempre.
Grátis, sem necessidade de registo · 2 por dia