Serviço de monitoramento de indisponibilidade para o DownDetector

• Serviço web que verifica em tempo real o status de funcionamento do site DownDetector em várias regiões
• Mede o código de resposta HTTP e a latência em 3 servidores regionais, incluindo Londres, Auckland e Nova York
• O código HTTP 200 (resposta normal) é retornado em todas as regiões, indicando que o site está operando normalmente
• A latência média por região é exibida na faixa de 478~586ms
• Pode ser usado como ferramenta de verificação de confiabilidade para as principais plataformas de monitoramento de falhas

---

Resultados da verificação por região

• Na região de London, UK, o status é Up, código HTTP 200, latência de 547ms
• Na região de Auckland, NZ, o status é Up, código HTTP 200, latência de 478ms
• Na região de New York, US, o status é Up, código HTTP 200, latência de 586ms
• Como o mesmo resultado se repete em todas as regiões, confirma-se que o serviço DownDetector está operando normalmente

Visão geral do serviço

• Este site é uma página de monitoramento dedicada a acompanhar o status do DownDetector
• Exibe medições periódicas do código de resposta HTTP e da latência para cada região
• Fornece indicadores de referência para verificar a disponibilidade da própria plataforma de monitoramento de falhas
• Não há informações adicionais no texto original

[GN⁺]

Comentários do Hacker News

• Como desenvolvedor solo baseado na Europa, desde o começo deste ano migrei toda a minha infraestrutura para serviços europeus
  Troquei Cloudflare por Bunny.net, AWS por Hetzner e o e-mail corporativo por Infomaniak
  Até agora não tive um único minuto de indisponibilidade, e a sensação de estar completamente separado dos serviços dos EUA é realmente ótima

  • Esses serviços são menores, mas justamente por isso levam a confiabilidade muito mais a sério
    Em ambientes de grandes empresas, é comum ouvir “isso não teria acontecido se tivéssemos usado AWS”. Algo como acontecia com a IBM antigamente
    A Hetzner oferece um conjunto de serviços muito mais simples que a AWS, então há menos complexidade
    Ainda assim, fatores culturais como reconhecimento de marca ou parecer “profissional” continuam pesando bastante
  • Não é que AWS ou Cloudflare realmente caiam com mais frequência. É só que, como têm muito mais usuários, os incidentes ganham mais cobertura
    Cada um escolhe a infraestrutura que quiser, mas a percepção sobre disponibilidade pode ser diferente da realidade
  • No começo deste ano, um servidor Hetzner que eu administrava reiniciou sem motivo aparente
    Houve um aviso de manutenção, mas aquele servidor não estava na lista dos afetados
    Não quer dizer que a Hetzner seja ruim; esses pequenos incidentes também acontecem na Europa
  • Sou fã da Bunny.net, mas a Cloudflare é forte em recursos de ‘defesa inteligente’, como filtragem de scrapers de IA e tráfego malicioso
    Fico em dúvida se a Bunny.net consegue substituir isso também
  • Gostaria de comparar Infomaniak e Proton. A Infomaniak parece ter mais ferramentas de produtividade de escritório, mas queria saber como são a qualidade do e-mail e do drive

• Ontem, durante a falha da Cloudflare, até o Downdetector caiu junto, e todo mundo achou graça. O timing foi perfeito

  • Numa empresa de CDN onde trabalhei antes, o fornecedor da nossa página de status virou nosso cliente, e tivemos de trocar de página de status

• Houve a piada: “Três Down Detector entraram num bar”
  O primeiro respondeu “não sei”, o segundo também “não sei”, e o terceiro respondeu “sim”

  • Alguém respondeu que provavelmente eram ‘down detectors cegos’
  • Foi tão engraçado que eu com certeza vou roubar essa piada

• Disseram que “isso é ouro puro”, e a piada meta continuou: “então quem monitora o down detector que monitora o down detector que monitora o down detector?”

  • Na prática, compartilharam a página de monitoramento do Downdetector no isitdownrightnow.com
  • Também teve a resposta: “quem está acessando esse site agora é você!”
  • Falando sério, se down detectors com zonas de disponibilidade e bases de código diferentes monitorassem uns aos outros, isso seria uma abordagem bem prática
  • Também sugeriram evoluir isso para a ideia de um down detector distribuído e talvez publicar como projeto no HN
  • Surgiu ainda a proposta de criar um meta down detector para monitorar qual dos três caiu

• Na verdade, o próprio Downdetector não ficou totalmente fora do ar; o problema era o módulo de verificação humana da Cloudflare
  Então, tecnicamente, estava “normal”, mas na prática era inutilizável

• Teve a piada de que “você precisa de outro down detector para monitorar se o seu down detector está vivo”
  Também falaram de uma estrutura de Downdetectorsdown que segue infinitamente

  • Compartilharam o link downdetectorsdowndetectorsdowndetector.com
  • Também surgiu a ideia de que, se houver vários, alguns sempre estarão fora do ar, então seria interessante ter um site que acompanhe essa proporção
  • No fim, isso vira uma questão de centralização vs descentralização vs sistemas distribuídos
    Se os down detectors se monitorarem mutuamente trocando heartbeats, dá para ter uma estrutura em que, mesmo que alguns morram, o conjunto sobreviva
    Com uma arquitetura de autocura, a rede se torna muito mais resiliente
  • Também repetiram a ideia de que “o down detector continua para sempre”
  • E brincaram com a proposta de montar isso como uma lista ligada, expressa como o “N-ésimo down detector”

• Também houve um comentário em tom de meme: “Sup dawg, I heard you like down detectors”

• A própria página de status do Downdetector foi compartilhada diretamente

• Disseram que, com a falha da Cloudflare derrubando o Downdetector e isso ainda gerando carga até para a CloudFront, o desafio seria criar um novo CDN que aguentasse até essa carga

  • Mas também houve a reação pragmática: “se for um HTML estático sem imagens, será que precisa mesmo de CDN?”

• Houve a pergunta: como o Downdetector detecta o ‘estado normal’?
  Durante a falha da Cloudflare, a página de índice talvez ainda retornasse 200
  Se alguém tentasse verificar tirando screenshots com um navegador headless, provavelmente seria bloqueado pela Cloudflare

  • Na prática, ele gera dados falsos
    O fetchStatus() de script.js chama generateMockStatus() para criar tempos de resposta aleatórios
    Ou seja, em vez de checar o estado real, ele mostra dados simulados de status