Fazendo o monitoramento do DNS direito: a paralisação do DNS AT&T

Paralisação de DNS AT&TFazendo o monitoramento do DNS direito: a paralisação do DNS AT&T

A paralisação do servidor de nomes de domínio (DNS) da AT&T de 15 de agosto de 2012 exemplifica por que um método “não baseado em cache” para monitorar sites é importante para sites de missão crítica. Em primeiro lugar, um pouco de uma revisão. A forma básica mais comum de monitoramento de sites é conduzida usando um navegador sintético (não um navegador real), que se conecta ao servidor de destino através de um processo de solicitação HTTP. Uma série de processos focados no servidor, como a disponibilidade do servidor de destino, o tempo necessário para carregar o arquivo HTML para o site do servidor e o capacidade de detectar palavras-chave dentro do arquivo HTML são verificados através do uso de um navegador sintético usando um processo de solicitação HTTP.

Para cache ou não para cache – essa é a questão

No entanto, o que não se sabe geralmente sobre a metodologia básica de monitoramento http sintético é que as empresas de monitoramento de sites têm a opção de usar uma metodologia de “cache” ou “não-cache”. A escolha da metodologia por um serviço de monitoramento impacta diretamente em sua capacidade de detectar problemas em servidores DNS secundários, como a paralisação do DNS AT&T que ocorreu em 15 de agosto de 2012. Por um lado, um método baseado em cache é muito mais simples para o negócio de monitoramento implementar e custar menos para configurar e administrar. Na verdade, a maioria dos serviços de monitoramento de tempo de atividade “básico” de baixo custo usam um “método de cache”.

Eu fico com o não-cache, obrigado.

No entanto, o pequeno segredo sujo é que o método de cache de monitoramento não é tão preciso, (nem a longo prazo como econômico) como uma solução não-cache. por que? A razão simples é que os métodos baseados em cache nem detectam o problema secundário do DNS.

A razão um pouco mais complexa é mais longa, mas realmente fica com a carne do que é um bom monitoramento – evitando o tempo de inatividade.

Especificamente, a razão pela qual o não-cache é mais econômico é que quando um problema como a paralisação do DNS AT&T ocorre invariavelmente – como quando ocorre qualquer condição de erro do site – é o TTR (Time-to-Repair) total que determina a perda devido ao tempo de inatividade. Em outras palavras, o TEMPO total (1) necessário para detectar, diagnosticare reparar um erro, pior o impacto do erro. Por outro lado, quanto mais rápido uma solução de monitoramento acelerar o TTR, mais a perda é reduzida (ou completamente evitada).

Como monitorar efetivamente a próxima situação de paralisação do DNS AT&T

No caso do problema de paralisação do DNS AT&T, existem vários fatores-chave que determinam o tempo de reparo:

– Método de detecção de erros: Use uma solução de monitoramento que usa um método não-cache para propagar consultas DNS até servidores de nome raiz a cada instância de monitoramento. Um serviço de método de cache armazena DNS e, portanto, não detectará um problema secundário de DNS, ou pode levar dias ou semanas para detectar o problema.

-Frequência de monitoramento: Use uma frequência mais rápida de monitoramento não-cache, como a cada 1 minuto versus uma vez por hora. Quanto mais rápido a solução de monitoramento não-cache detectar e alertar um administrador impactado de um site usando um serviço DNS falhando, mais rápido um switch pode ser feito para um provedor de failover DNS.

– Frequência de configuração de TTL (Time-to-Live): Quanto menor o valor da configuração de frequência time-to-live (TTL) usada pelos administradores de DNS para definir o cache DNS para um servidor DNS secundário do nome de um domínio do servidor de nome autoral principal. Normalmente definido como 86.400 segundos (1 dia) ou mais, no planejamento de recuperação de desastres o TTL pode ser definido tão baixo quanto uma vez a cada 300 segundos, no entanto, quanto menor a configuração, maior a carga no servidor de nome de domínio autoritário.

-O diagnóstico – como uma via de rastreamento automática no momento do problema de DNS detectado – é fornecido pela solução de monitoramento (os serviços de monitoramento mais básicos não fornecem nenhuma informação de diagnóstico)

-Reparo: Continue monitorando a solução durante a condição de erro para identificar melhor o problema. Envie os resultados monitorados para o seu provedor de DNS. Você também pode executar vias de rastreamento DNS manuais gratuitas aqui (selecione “DNS” estilo de rastreamento) para verificar o problema conforme necessário.

-Prevenir: Use uma solução de monitoramento que permita visualizar os detalhes de uma busca de DNS (como uma monitoramento real do navegador) a fim de ver “erros suaves”, como tendências de desaceleração e problemas intermitentes, para que você possa agir antes que o “erro suave” se torne um “erro difícil”, como um cliente enfrentando o tempo de inatividade.

(1) De acordo com as organizações que participaram de um estudo da TRAC Research, setembro de 2011, as organizações identificaram a quantidade de tempo gasto para solucionar problemas de desempenho como seu principal desafio com “em média, durante uma semana de trabalho completa de horas-homem (46,2 horas) gastas em situações de sala de guerra todos os meses”.

 

 

 

Artigos mais recentes sobre desempenho na Web

Comece o Dotcom-Monitor gratuitamente hoje

Não é necessário cartão de crédito