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

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 que aumentam 99,5% com 5 segundos de navegação página a página). Consideramos o tempo de inatividade programado e não programado para determinar esse número de disponibilidade. No entanto, recentemente adicionamos uma CDN ao mix, o que meio 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 atingindo a CDN em cerca de 75% dos A Hora.

A gerência decidiu que adotamos o pior cenário possível para medir a disponibilidade. Portanto, se nossos servidores de origem estão tendo problemas, mas a CDN ainda está exibindo conteúdo, ainda temos problemas de disponibilidade. O mesmo vale para o contrário. Meu pensamento é que, enquanto a "experiência do usuário" for bem-sucedida, não devemos nos punir desnecessariamente. Afinal, existe uma CDN para melhorar o desempenho e a disponibilidade!

Só estou imaginando se alguém tem algum conhecimento de como outras empresas da Fortune 500 calculam seus números de disponibilidade. Olho para apple.com, por exemplo, uma loja que usa uma CDN que parece nunca estar inoperante (a menos que exista um grande anúncio de produto.) Seria ótimo ter alguns dados concretos, porque eu não acreditamos que precisamos nos machucar desnecessariamente nessas métricas. Nós estão tomando decisões de negócios com base nesses números.

No entanto, posso dizer que, como essas métricas são visíveis ao gerenciamento, os problemas são resolvidos e resolvidos rapidamente (leia-se: eliminamos a burocracia rapidamente). Infelizmente, como desenvolvedor, não quero que o gerente pense que o aplicativo está ativo ou inativo porque algum fator externo (isto é, CDN) está influenciando os números.

Pensamentos?

(Postei esta pergunta por engano no StackOverflow, desculpe-me antecipadamente pela postagem cruzada)

Em resumo, eu diria que você deve definir nitidamente o que constitui "disponível" vs. "indisponível" e medir-se contra ele. Por exemplo, você pode ter um SLA de desempenho do cliente para o site de 1 segundo para a "dobra" e 3 segundos para uma página totalmente renderizada. Quando você não cumprir o SLA de desempenho, deve considerar isso como uma falha de disponibilidade para esse período. Não importa se você está acessando a CDN ou não - a experiência do usuário é o que importa.

No entanto, como você está fazendo medições apenas a cada 5 minutos, parece razoável medir as ocorrências na CDN versus o site principal separadamente e calcular que 75% da disponibilidade é proveniente da 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 levar em consideração o que acontece quando um site mestre ou a CDN está inoperante. O cliente recebe um HTTP 500 ou apenas realiza failover transparente no site de trabalho? Depende muito da sua solução de balanceamento de carga. A métrica "pior caso" que você descreveu parece muito simplista. Pergunte a si mesmo "

Na medida em que você deve ser responsabilizado quando a CDN estiver em baixo: absolutamente. Se 75% dos seus hits forem para a CDN, então 75% da experiência do cliente depende deles. Você é responsável por fornecer uma boa experiência aos seus clientes; portanto, se a CDN estiver com problemas, você precisará usar seus recursos de engenharia para provar isso e acompanhar o fornecedor.

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

Concordo com o user44700, é melhor separar o teste de disponibilidade para seus servidores versus a CDN e acompanhar os dois independentemente de forma independente. Sua verdadeira disponibilidade será Server Avail * CDN Avail, pois se um deles ficar inativo - você está considerando que sua página / site está inoperante. Isso também custará menos com qualquer um dos fornecedores de monitoramento.

Eu não seguiria o caminho de criar um teste de navegador e veria quais itens falharam, enquanto ele poderia funcionar e algumas empresas como o Catchpoint têm o conceito "disponibilidade de conteúdo" - talvez não seja exatamente o que você deseja para este caso. Digamos, por exemplo, que sua página da Web tenha uma chamada para a CDN para um arquivo que fornece 404, a maioria das soluções de monitoramento dirá que isso é uma falha - mas foi realmente a CDN que falhou? Esse arquivo foi 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 obter mais algumas idéias: http://blog.catchpoint.com/2010/07/21/true-availability-of-a-webpage/

Os relatórios do SLA devem refletir com precisão a realidade. Se você estiver medindo a disponibilidade da perspectiva do usuário e apenas o servidor que estiver fazendo a medição estiver com problemas, reportar esse problema no seu SLA não refletiria a experiência do usuário.

Eu posso entender o desejo de manter as informações de origem em um alto padrão, talvez sempre as relatando, mesmo que imprecisas, mas com uma nota identificando o porquê.

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

Se as informações são relatadas como uma interrupção e não foram, que valor os relatórios fornecem?

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 é introduzido por humanos e considera vários fatores que refletem com mais precisão a situação.

Gomez e Keynote são soluções aceitas pela empresa para reunir os tipos de métricas que você mencionou. Gomez também tem um serviço que monitora seu usuário final UX, fornecendo um arquivo javascript no estilo google analytics.

Pingdom são bons: http://www.pingdom.com/

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ê deseja especificamente - números de disponibilidade para ajudá-lo a determinar quando um aplicativo está realmente inativo ou números que atrapalham o gerenciamento. De qualquer forma...

1. Monitoramento sintético externo - Keynote / Gomez / Webmetrics. Costumávamos usar o Keynote, agora usamos o Gomez. Obviamente, como você observa, isso também inclui a 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 tirar o "CDN dele", você pode pegar outro monitor Keynote / Gomez e apontá-lo para seus aplicativos, não através do CDN, usando um nome DNS alternativo ou outros enfeites. Mas, como ainda possui ativos estáticos, é mais útil para desempenho do que para disponibilidade. E mantém interrupções na Internet, interrupções do agente etc. no circuito, o que é apropriado para alguns propósitos e não para outros.

2. Monitoramento real do usuário. Há baseado em rede (Coradiant, Tealeaf) e baseado em tag (Jiffy, Gomez). Usamos o Coradiant como um sniffer de rede e determina o desempenho real dos usuários hospedados aqui em nosso data center - em outras palavras, os aplicativos reais e não todo o lixo estático da CDN. Em seguida, escrevemos relatórios para determinar as taxas de erro e o desempenho do aplicativo e usamos o Apdex (apdex.org) como uma métrica derivada. Em alguns casos, você não pode usar a rede (muito tráfego ou seus ativos não estão hospedados onde você pode acessar a rede) e a etiqueta não é tão confiável. Tem o imenso benefício de realmente ver o tempo de resposta e os erros do usuário final - é 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 / centenas de outros. Aponte um monitor para o seu aplicativo localmente (não passe pela CDN). Para o monitoramento de disponibilidade acionável (como enviar uma página para acordar alguém), esse é o padrão-ouro. Não leva em consideração as coisas da rede.

4. Monitoramento de log. Em certo sentido, esse é um monitoramento real do usuário do gueto. Mas se você realmente quer apenas ver o que cometeu um erro, é bastante útil. Tem o benefício "realmente não foi o que aconteceu" do monitoramento real do usuário. Freqüentemente, apenas a disponibilidade, a menos que você esteja registrando o tempo gasto na camada da Web; nesse caso, mostra quanto tempo o servidor terminou - não é útil para o usuário que enfrenta o SLA, mas é muito útil para "em que código precisamos trabalhar" . " Use splunk.

Não é um ou outro, usamos todos esses itens, porque você deseja a "história do usuário final" e também "em qual programador precisamos nos apoiar".

O BrowserMob é ótimo