Procurando por uma recomendação sobre como medir um aplicativo de alta disponibilidade que está usando um CDN

Question

Eu trabalho para uma empresa da Fortune 500 que se esforça para medir com precisão o desempenho e a disponibilidade de aplicativos de alta disponibilidade (ou seja, aplicativos com até 99,5% com navegação de 5 segundos de página para página). Consideramos o tempo de inatividade programado e não programado para determinar esse número de disponibilidade. No entanto, adicionamos recentemente um CDN à mistura, o que complica um pouco nossas métricas. A CDN agora lida com cerca de 75% do nosso tráfego, enquanto envia o restante para nossos próprios servidores.

Tentamos medir o que chamamos de "verdadeira experiência do usuário" (ou seja, nossos scripts de teste emulam um usuário típico clicando no aplicativo.) Esses scripts de monitoramento ficam fora da nossa rede, o que significa que estamos falando sobre o CDN 75% do tempo.

A gerência decidiu que tomamos o pior cenário para medir a disponibilidade. Portanto, se nossos servidores de origem estiverem tendo problemas, mas ainda assim o CDN estiver veiculando bem o conteúdo, ainda teremos sucesso na disponibilidade. O mesmo acontece ao contrário. Meu pensamento é que enquanto a "experiência do usuário" for bem-sucedida, não devemos nos punir desnecessariamente. Afinal, um CDN está lá para melhorar o desempenho e a disponibilidade!

Eu só estou querendo saber se alguém tem algum conhecimento de como outras empresas da Fortune 500 calculam seus números de disponibilidade? Eu olho para apple.com, por exemplo, de uma loja que usa um CDN que nunca parece estar em baixo (a menos que esteja prestes a ser um anúncio importante do produto). Seria ótimo ter alguns dados concretos, porque eu não faço Acreditamos que precisamos nos prejudicar desnecessariamente nessas métricas. Nós estamos tomando decisões de negócios com base nesses números.

Eu posso dizer, no entanto, dado que essas métricas são visíveis para o gerenciamento, os problemas são resolvidos e resolvidos rapidamente (leia-se: cortamos a burocracia rapidamente). Infelizmente, como desenvolvedor, eu não quero gestão para pensar que o aplicativo está ativo ou inativo porque algum fator externo (ou seja, CDN) está influenciando os números.

Pensamentos?

(por engano, eu postei essa pergunta no StackOverflow, desculpe antecipadamente pelo post)

    

Answer 1

No resumo, eu diria que você deve definir claramente o que constitui "disponível" versus "indisponível" e se comparar a ele. Por exemplo, você pode ter um SLA de desempenho do lado do cliente para o site de 1 segundo para a "dobra" e 3 segundos para uma página completamente renderizada. Quando você não atinge o SLA de desempenho, deve considerar isso como uma falha de disponibilidade para esse período de tempo. Não importa se você está atingindo o CDN ou não - a experiência do usuário é o que importa.

No entanto, como você só faz medições a cada 5 minutos, parece razoável medir as ocorrências no CDN em relação ao site mestre separadamente e calcular que 75% da disponibilidade é proveniente do CDN e 25% do mestre . A dificuldade aqui é que 75% é apenas uma média. Para distribuir a culpa com precisão por um determinado período, você precisa saber quando um ou outro site não está realmente voltado para o cliente, por exemplo, durante uma mudança planejada ou após uma ação manual quando um problema é detectado. Você também precisa considerar o que acontece quando um dos sites mestre ou CDN está inativo. O cliente obtém um HTTP 500 ou eles simplesmente fazem o failover para o site de trabalho? Depende muito da sua solução de balanceamento de carga. A métrica "pior caso" que você descreveu parece simplista demais. Pergunte a si mesmo: "O que nossos clientes estão experimentando?"

Quanto a saber se você deve tomar "culpa" quando o CDN está em baixo: absolutamente. Se 75% dos seus hits estiverem indo para o CDN, 75% da experiência do cliente dependerá deles. Você é responsável por fornecer uma boa experiência a seus clientes, portanto, se o CDN estiver com problemas, você precisará usar seus recursos de engenharia para comprovar e acompanhar o provedor.

Outra coisa a considerar é o que acontece quando o site principal fica indisponível por um longo período de tempo. Como você descreveu, parece que o CDN é uma cópia estática do conteúdo no site mestre. Se o site principal estiver inativo por um longo tempo, o CDN pode começar a ficar obsoleto. Então, talvez parte do seu SLA seja a atualização: 1 segundo para a "dobra" e 3 segundos para uma página totalmente renderizada, com conteúdo de no máximo 15 minutos.

    

Answer 2

Concordo com o user44700, é melhor separar o teste de disponibilidade para seus servidores versus o CDN e rastrear os dois independentes de forma independente. A sua verdadeira disponibilidade será Server Avail * CDN Avail, já que, se algum deles cair, você está considerando que sua página / site está inativa. Isso também lhe custará menos com qualquer um dos fornecedores de monitoramento.

Eu não seguiria o caminho de criar um teste de navegador e ver quais itens falharam, enquanto ele poderia funcionar e algumas empresas como o Catchpoint têm o conceito "disponibilidade de conteúdo" - pode não ser exatamente o que você deseja para este caso. Digamos, por exemplo, que sua página da Web tenha uma chamada para o CDN para um arquivo que forneça 404, a maioria das soluções de monitoramento dirá que isso é uma falha - mas foi realmente o CDN que falhou? Esse arquivo era mesmo importante? talvez alguém tenha esquecido de remover alguma referência de relíquia que nenhum usuário percebe.

Você pode ler esta postagem do blog para mais algumas ideias: link

    

Answer 3

O relatório de SLA deve refletir com precisão a realidade. Se você estiver medindo a disponibilidade do ponto de vista do usuário e apenas o servidor que está fazendo a medição estiver com problemas, informar esse problema no seu SLA não refletirá a experiência do usuário.

Eu posso entender o desejo de manter as informações de origem com um alto padrão, talvez sempre denunciá-las, mesmo que imprecisas, mas com uma anotação identificando o motivo.

Se você não conseguir chegar a um acordo, talvez exista uma solução técnica para tornar o servidor de medição menos falível.

Se a informação for reportada como uma interrupção e não foi, que valor o relatório fornece?

No meu ambiente, relatamos de várias fontes. Uma metodologia de monitoramento externo para relatar a disponibilidade de uma perspectiva externa, bem como relatar nosso sistema interno de registro de interrupções, que é humano inserido, e considera vários fatores que refletem com mais precisão a situação.

    

Answer 4

O Gomez e o Keynote são soluções aceitas pela empresa para reunir os tipos de métricas que você mencionou. O Gomez também tem um serviço que monitora sua UX do usuário final ao obter um arquivo javascript google-analytics-esque.

    

Answer 5

Pingdom são bons: link

    

Answer 6

Somos uma Fortune 500 com um site habilitado para CDN e usamos várias coisas. Você determinou corretamente que precisa medir coisas diferentes se quiser detectar coisas diferentes. Não está claro para mim o que você quer especificamente - números de disponibilidade para ajudá-lo a determinar quando um aplicativo está realmente desativado, ou números que tiram o gerenciamento das suas costas. Enfim ...

1. Monitoramento sintético externo - Keynote / Gomez / Webmetrics. Nós costumávamos usar o Keynote, agora usamos o Gomez. É claro que, conforme você observa, isso também inclui o CDN e quaisquer outros componentes externos - o que é bom para medir seu SLA geral, mas não tão bom para determinar os SLAs de seus aplicativos.

Para obter o "CDN fora dele", você poderia usar outro monitor do Keynote / Gomez e apontá-lo para seus aplicativos não através do CDN usando um nome de DNS alternativo ou algo assim. Mas como ainda tem ativos estáticos, é mais útil para o desempenho do que a disponibilidade. E mantém interrupções na Internet, interrupções de agentes, etc. no loop, o que é apropriado para alguns propósitos e não para outros.

2. Monitoramento real de usuários. Há baseados em rede (Coradiant, Tealeaf) e baseados em tags (Jiffy, Gomez). Usamos o Coradiant como um farejador de rede e ele determina o desempenho real dos ativos hospedados aqui em nosso data center - em outras palavras, os aplicativos reais e não todo o lixo estático no CDN. Em seguida, escrevemos relatórios para determinar as taxas de erros e o desempenho do aplicativo e usamos o Apdex (apdex.org) como uma métrica derivada. Em alguns casos, você não pode usar rede com base (muito tráfego, ou seus ativos não estão hospedados onde você pode acessar a rede), e isso não é confiável. Tem o imenso benefício de realmente ver o tempo de resposta do usuário final e os erros - é fácil configurar um monitor sintético que não cometa erros em todos os casos que um usuário real faz.

3. Monitoramento sintético local. Nagios / zabbix / sitescope / cem outras. Aponte um monitor no seu aplicativo localmente (não passe pelo CDN). Para monitoramento de disponibilidade acionável (como em, enviar uma página para despertar alguém), esse é o padrão ouro. Não leva em conta as coisas da rede.

4. Monitoramento de log. De certa forma, isso é o monitoramento real do usuário do gueto. Mas se você realmente só quer ver o que está errado, é muito útil. Tem o benefício "não é isso mesmo que aconteceu" do monitoramento real do usuário. Muitas vezes, apenas a disponibilidade, a menos que você esteja registrando o tempo gasto na camada da Web. Nesse caso, ele mostra quanto tempo o servidor levou - não é útil para o usuário enfrentar SLA, mas muito útil para "qual código precisamos trabalhar " Use splunk.

Não é um dos dois, ou usamos todos eles, porque você quer a "história do usuário final" e "em que programador precisamos nos apoiar".

    

Answer 7

BrowserMob é ótimo