O novo ShakeAlert de Edgio fornece maior visibilidade sobre eventos de rede
Ao operar redes grandes e distribuídas globalmente, falhas de hardware, interrupções de provedores e outras mudanças de comportamento são ocorrências regulares. Portanto, os sistemas que podem levantar alarmes nos primeiros sinais de problemas podem alertar operadores humanos ou sistemas automatizados e permitir uma ação corretiva mais rápida. Para isso, desenvolvemos o ShakeAlert ,um sistema de alerta baseado em dados externos disponíveis publicamente para alertar sobre mudanças repentinas na Internet.
O ShakeAlert monitora fluxos de atualizações do BGP (Border Gateway Protocol ) observadas por coletores públicos para caminhos originados da CDN. Quando o volume de atualizações aumenta drasticamente, o ShakeAlert emite um alarme, chamado de tremor , sinalizando uma possível mudança no comportamento de roteamento da Internet e, em particular, como as redes externas encaminham seu tráfego para a CDN. Usando o conteúdo dessas atualizações, o ShakeAlert fornece ainda uma estimativa dos possíveis Pops impactados (pontos de presença), fornecedores e prefixos.
O sistema foi nomeado para o sistema de alerta precoce do terremoto da Pesquisa Geológica dos Estados Unidos. Esse sistema funciona detetando movimentos mais rápidos, mas menos destrutivos, ondas P e alertando os residentes antes que as ondas S mais destrutivas cheguem. Aqui, consideramos os sinais do plano de controlo do BGP como o sinal de alerta precoce para alterações potencialmente preocupantes no plano de dados e no tráfego do utilizador final.
Fundo
Para facilitar o roteamento entre Sistemas Autônomos (Ases) na Internet, as redes comunicam quais os prefixos para os quais têm rotas via BGP. Como parte desta comunicação, quando a acessibilidade de um prefixo muda, uma rede envia uma série de anúncios chamados anúncios que indicam os prefixos impactados e o caminho que a rede usaria para alcançá-los.
No funcionamento regular da Internet, milhares de mensagens são trocadas entre redes à medida que atualizam as tabelas de roteamento. Cada vez que estas rotas mudam, por exemplo, como resultado de falhas de rede, nova conetividade entre redes ou manutenção planeada, um novo conjunto de mensagens pode ser trocado. Estas podem incluir alterações geradas pela rede de origem (por exemplo, anunciar um novo bloco IP) ou alterações que ocorrem a jusante da origem (por exemplo, alterações na conetividade de um fornecedor de trânsito).
Estas mensagens oferecem necessariamente uma grande visão do estado atual da Internet, revelando os ganhos e perdas da conetividade entre as redes. Para aproveitar esta informação, muitas organizações1 executam serviços chamados de coletores de rotas, que fazem a ligação com muitas redes e disponibilizam publicamente as mensagens de atualização recolhidas.
Quando a conetividade muda, as redes upstream enviam atualizações BGP, que eventualmente se encaminham para os coletores BGP.
Para desenvolver um sentido destes comportamentos, consideramos algumas observações iniciais. Consideramos os feeds de atualização resultantes para um punhado de redes diferentes. Consideramos duas grandes redes de CDN (Cdn A, CDN B), uma rede de conteúdo (conteúdo), dois grandes ISPs (ISP A, ISP B) e uma Carta Raiz de DNS. Cada tipo de rede é arquitetada para diferentes fins e potencialmente apresenta diferentes políticas de peering. Para cada rede, agrupamos as atualizações em intervalos de 1 minutos e consideramos o número de mensagens em cada intervalo durante uma hora em janeiro de 2021.
A figura acima representa o tamanho de cada compartimento de atualização durante esse período. Aqui, vemos os CDNs, que apresentam grandes implantações e muitos pares e fornecedores geram o maior número de atualizações para quase todo o período, com a rede de conteúdo relativamente próxima. Os ISPs e as Root Letters geram significativamente menos atualizações. Estas diferenças dramáticas de magnitude indicam que a estrutura, os pares e a arquitetura de uma rede provavelmente têm impactos significativos nos volumes de mensagens correspondentes. Temos, portanto, de garantir que o nosso sistema seja flexível para alterar parâmetros, tal como discutimos na próxima secção.
O sistema de alerta de trepidação
O ShakeAlert ouve transmissões em tempo real de 21 coletores de rotas que fazem parte do projeto2 do Sistema de Informações de Roteamento (RIS) DA RIPE NCC . Os dados chegam desses feeds e são agrupados em compartimentos de tempo de minutos. Em seguida, contamos o número de atualizações em cada compartimento e usamos um algoritmo de deteção de mais tempo para determinar se um compartimento tem um número anormalmente grande de atualizações em comparação com outros minutos recentes. No caso de tal escaninho ser observado, geramos um tremor.
Para este fim, o ShakeAlert mantém uma janela de correr da contagem de atualizações vistas nos últimos w bins, permitindo-lhe evitar armazenar informações sobre atualizações mais do que w bins antigos. Uma vez que o ShakeAlert construiu um histórico de caixas w, e o 1.o bin está completo, ele considera a contagem deste novo bin, b w-1, em relação aos da janela anterior. Embora alguns mecanismos de deteção de anomalias potenciais possam ser usados (por exemplo, pontuação z modificada e estimativas do desvio padrão, limiares estáticos e várias técnicas de deteção de alterações), empregamos um mecanismo de deteção baseado em densidade 34.
Para realizar a deteção de anomalias com base na densidade, consideramos um raio R e uma contagem de vizinhos k . Dizemos que o nosso novo depósito de tempo b w-1 é mais caro se houver menos de k outros compartimentos nos últimos w minutos com contagens dentro do raio R centradas em torno da contagem do novo depósito. Formalmente, qualquer outlier tem menos de k bins b i nos últimos w minutos de tal forma que | b w-1| – |b i| <R . Referimo-nos a qualquer outliers como alertas de tremores ou simplesmente batidos e a atualização conta estes tremores como otamanho .
O processo de deteção geral do ShakeAlert
A base subjacente da nossa hipótese é que grandes e disruptivas mudanças de roteamento da Internet geram o maior desses eventos: Rotas que transportam tráfego significativo provavelmente serão ouvidas por muitas redes e coletores a jusante. Fundamentalmente, no entanto, muitas mudanças envolvem grandes contagens de atualizações que não se enquadram nesta categoria. Por exemplo, manutenção programada regularmente para a qual retiramos anúncios da Anycast.
O conteúdo das atualizações no compartimento pode ser observado para revelar detalhes sobre a natureza do evento de rede. Os prefixos nas atualizações podem ser usados para determinar quais regiões POPs e Anycast são potencialmente impactadas pelas alterações de rede correspondentes. Podemos examinar ainda mais os caminhos observados nas atualizações e estimar as redes upstream com maior probabilidade de serem impactadas. Finalmente, podemos determinar a importância dos alertas com base na sua importância para o tráfego de entrada da CDN.
Na nossa implementação de CDN, usamos uma janela com 360 minutos e k de 5, permitindo-nos evitar alertas sobre comportamentos horários comumente observados. Também tomamos R para ser a distância entre os percentis 5 e 95 dos tamanhos de caixote observados na janela. Para aumentar o contexto operacional, subdividimos ainda mais os compartimentos em séries temporais específicas de pop com base nos prefixos e caminhos observados nas atualizações, alertando cada um individualmente. Finalmente, consideramos uma série de afinações específicas, por exemplo, definir tamanhos mínimos de alerta com base nas nossas observações de rede.
ShakeAlert em ação
Em seguida, consideramos um exemplo simples que demonstra como os batidos aparecem na natureza. No exemplo acima tirado de setembro de 2022, focamo-nos num pop CDN específico, observando a contagem de atualizações muito menor ao longo do eixo y e da escala linear do que a nossa figura anterior. Durante este período de tempo, as contagens de atualizações são quase inteiramente de 0 até que, de repente, aumentam, gerando uma contagem de atualizações muito maior em 12:14 e um segundo pico pouco depois em 12:20, ambos os quais geraram batidos. Essas atualizações foram causadas por uma interrupção inesperada na conetividade com um provedor.
Avaliação
Para medir se os shake representam ou não eventos interessantes, consideramos a seguinte análise. Para cada tremor gerado ao longo de 30 dias no verão de 2022, examinamos as nossas métricas internas no local correspondente para determinar se observamos um comportamento anómalo dentro de 10 minutos após o tremor. Para as nossas anomalias, consideramos o seguinte: Redefinições do router (por exemplo, um router reinicializado ou de outra forma offline), alterações no estado do BGP num link de fornecedor (ou seja, uma sessão do BGP de um fornecedor saiu do estado ESTABELECIDO), alterações nos anúncios anunciados a partir de um local e perda de pacotes detetada entre o local correspondente e pelo menos cinco outros locais.
A figura acima mostra a repartição destes eventos ao longo de 30 dias. Aqui, vemos que todos os baldes tiveram eventos correspondentes para pelo menos 60% dos batidos, e em média, 80% dos batidos tiveram eventos correspondentes. Estes resultados confirmam que os maiores abalos correspondem a eventos importantes e, frequentemente, com impactos no tráfego. No entanto, eles enfatizam ainda mais a amplitude dos eventos, que vão desde a manutenção de rotina a falhas agudas, que podem gerar tais abalos.
Conclusão
O ShakeAlert oferece um novo ângulo de visibilidade ao nosso já rico monitoramento de CDN . Ao extrair os seus dados de uma fonte externa, sabemos que oferece perspetivas fundamentalmente diferentes sobre o comportamento da Internet. No nosso trabalho contínuo no sistema, estamos a explorar como os dados podem ser combinados com a monitorização interna para melhorar a precisão dos alertas e permitir ações corretivas automatizadas.
Um agradecimento especial à equipa de investigação, à equipa de engenharia de fiabilidade de rede e a todas as equipas de engenharia internas que tornaram este trabalho possível. Ainda mais graças a muitos especialistas externos em dados de roteamento, incluindo Emile Aben, Stephen Strokes e Mingwei Zhang, que forneceram feedback e discussões úteis.
1 por exemplo, Routeviews , Ris
2 O sistema pode usar fundamentalmente quaisquer coletores. Aqui nós simplesmente nos concentramos no RIS devido à flexibilidade de sua interface WebSocket
3 M. Gupta, J. Gao, C. C. Aggarwal, e J. Han. Detecção de outlier para dados temporais: Uma pesquisa. Transações do IEEE em Conhecimento e Engenharia de Dados, 2014.
4 T. Kitabatake, R. Fontugne, e H. Esaki. BLT: Uma ferramenta de taxonomia e classificação para a mineração de mensagens de atualização do bgp. Em Proc. Da INFOCOM ’18, 2018.