Medição de Latência corretamente requer que você tenha qualidade de dados. Há uma razão pela qual o “Global CEO Outlook 2016” da KPMG descobriu que 84% dos CEOs estão preocupados com a qualidade dos dados em que estão baseando as decisões e é porque muitas vezes os dados podem enganar.
a diferença entre as empresas que se preocupam com seus dados e não é enorme. Os pesquisadores do MIT descobriram que as empresas que adotaram um design orientado a dados têm uma produção 5-6% maior do que o esperado, dados seus outros investimentos e uso de tecnologia da informação. Essa razão por si só torna a compreensão da latência crítica para o sucesso dos negócios.
Em apenas 7 minutos, você vai aprender tudo o que você precisa saber sobre a medição de latência
como medir a latência
por que medir de forma adequada é importante
armadilhas comuns ao observar os seus dados de latência
a importância do feedback instantâneo
por que sem amostragem de dados é necessário
Então, o Que é Latência?
Dictionary.com define latência como”o período de atraso quando um componente de um sistema de hardware está aguardando a execução de uma ação por outro componente”. Em termos mais simples, isso significa a quantidade de tempo entre chamar uma função e sua execução real. A latência é inerente a todos os sistemas; mesmo se tivéssemos um sistema perfeito(que não existe), é latente a quantidade de tempo que leva para os elétrons no computador para trocar os transistores de on para off, ou vice-versa.A latência em pequenas operações não é grande coisa, mas ao lidar com milhões de operações, existem milhões de latências que se somam rapidamente. A latência não é definida por uma unidade de trabalho/tempo, mas sim como ela se comporta. As ferramentas de monitoramento relatam quanto tempo leva desde o início de uma função até o final da função.
a latência pode ter um grande impacto no seu negócio, por exemplo “quando se trata de velocidade móvel, cada segundo importa — para cada segundo adicional, é necessária uma página móvel para carregar, as conversões podem cair até 20%”(Fonte). Portanto, é extremamente importante entender sua latência da melhor maneira possível.
armadilhas comuns ao olhar para seus dados de latência:
a latência quase nunca segue uma distribuição normal, Gaussiana ou Poisson. Mesmo que sua latência siga uma dessas distribuições devido à maneira como observamos a latência, torna inúteis médias, medianas e até desvios padrão! Se, por exemplo, você estiver medindo cargas de página, 99,999999999% dessas cargas podem ser piores do que sua mediana. (Clique para twittar esta estatística) isso faz parte do motivo pelo qual a amostragem aleatória de sua latência causa dados imprecisos, mas mais sobre isso mais tarde.
neste ponto, você provavelmente está se perguntando se não estamos usando nenhum desvio padrão, como podemos descrever significativamente as latências? A resposta é que devemos olhar para percentis e máximos. A maioria das pessoas pensa consigo mesma, OK, então eu olho para o P95 e entendo o “caso comum”. O problema com isso é que o P95 vai esconder todas as coisas ruins. Como Gil Tene, CTO da Azul Systems, diz “é um” sistema de marketing”, alguém está sendo enganado.”
Tome por exemplo Este gráfico:
Nota do Editor: o produto BeeInstant que produziu esta captura de tela não está mais disponível, mas seus recursos fazem parte da plataforma APM e observabilidade da Instana.
quando você vê este gráfico, você pode ver claramente por que é a mediana e média não têm significado real, eles não mostram a área do problema. Quando você vê o percentil 95 atirar para a esquerda você acha que está vendo o coração do problema.
isso, é claro, não é verdade, porém, quando você vai investigar por que seu programa teve um soluço você está falhando em ver os piores 5% do que aconteceu. Para obter esse tipo de pico, é necessário que os 5% principais dos dados sejam significativamente piores.
agora olhe para o mesmo gráfico que também mostra o percentil 99,99:
Nota do Editor: o produto BeeInstant que produziu esta captura de tela não está mais disponível, mas seus recursos fazem parte da plataforma APM e observabilidade da Instana.
essa linha vermelha é o percentil 95, enquanto o verde é a linha do percentil 99,99. Como você pode ver claramente, o percentil 95 mostra apenas 2 de 22 de seus problemas! É por isso que você deve olhar para todo o espectro de seus dados.
apesar do fato de que muitas pessoas podem pensar que os últimos 5% dos dados não têm tanto significado. Claro, pode ser apenas uma máquina virtual reiniciando ou um soluço em seu sistema, ou algo assim, mas embora isso seja verdade ao ignorá-lo, você está dizendo que isso simplesmente não acontece quando pode ser uma das coisas mais importantes para você atingir!
Gil Tenel gosta de fazer a afirmação ousada de que “o indicador número um do qual você nunca deve se livrar é o valor máximo. Isso não é ruído, esse é o sinal. O resto é barulho.”Embora o máximo seja realmente um ótimo single em um sistema em grande escala, muitas vezes não é prático buscar apenas o caso máximo. Nenhum sistema é perfeito e soluços ocorrem, em um sistema prático em grande escala, perseguir o caso máximo exclusivamente é muitas vezes uma boa maneira de queimar sua equipe de desenvolvimento.
ao olhar para o percentil 99.99 você está vendo o que acontece com a grande maioria de seus clientes e quaisquer picos que você vê lá você sabe que são problemas reais, enquanto quaisquer picos em seu máximo pode ser apenas um soluço em seu sistema. Quando suas equipes de devops concentram seu esforço nesses pequenos soluços, elas estão fazendo isso a um grande custo de oportunidade, pois não podem trabalhar em questões mais importantes.
é de notar que se o seu 99.99 th e seu máximo são muito próximos uns dos outros (e são ambos cravados) do que é um grande sinal de que este é um problema que sua equipe deve trabalhar. Dessa forma, Gil está certo de que o máximo é um ótimo sinal, mas errado de que o resto de seus dados seja apenas ruído. Como você pode ver neste gráfico:
Nota do Editor: Como acima, o produto que produziu esta imagem não está mais disponível, mas seus recursos são parte do Instana da APM e Relevância Plataforma.
nosso 99.Percentil 99 e máximo do nosso exemplo anterior correspondem exatamente. Este é um ótimo sinal de que o que você está olhando é um bug real e não apenas um soluço.
percentis médios: como a pré-Computação está causando uma latência de medição incorreta:
uma armadilha ainda pior em que as pessoas caem do que apenas olhar para o percentil 95 não está reconhecendo que seus percentis são calculados em média. A média dos percentis é estatisticamente absurda; remove todo o significado do que você está olhando. Já mostramos como as médias não são boas, ao olhar para a latência, e se você está olhando para percentis médios, você está simplesmente de volta ao quadrado um. Muitos softwares medem seus percentis, por exemplo, Este gráfico Grafana:
se você percebeu ou não antes de todos os percentis sobre isso são médios! Ele diz isso ali mesmo no livro-razão do eixo x. QUASE TODOS OS SERVIÇOS DE MONITORAMENTO MEDEM SEUS PERCENTIS! Esta é uma realidade devido à pré-computação. Quando seu serviço de monitoramento recebe seus dados, eles estão computando o percentil dos dados para esse minuto.
então, quando você vai dar uma olhada no seu percentil 95, eles estão mostrando uma média de todos os seus percentis. Este atalho para” seu bem ” para tornar seu serviço mais rápido é, na realidade, remover toda a significância estatística de seus dados.
por que você deve ter dados não amostrados para medir a latência corretamente:
se você sabe ou não, monitorando as ferramentas que participam da amostragem de dados, eles estão produzindo dados médios. Quase todas as ferramentas de monitoramento amostras seus dados. Tomemos por exemplo DataDog; eles têm grande perda de dados. Se você enviar 3 milhões de pontos em um minuto, eles não levarão todos eles. Em vez disso, eles amostrarão aleatoriamente os pontos e os agregarão em 1 ponto por minuto.
você deve ter dados não amostrados para entender sua latência. É inerente que, com os dados amostrados, você não possa acessar a distribuição completa! Seu máximo não é seu verdadeiro máximo, nem seu percentil global é uma representação precisa do que está acontecendo!
os dados amostrados exacerbam a omissão coordenada!
quando você Amostra dados, você está omitindo dados. Digamos, por exemplo, que você tenha 10.000 operações acontecendo em um minuto enviando 2 pontos de dados cada para o seu sistema de monitoramento. Digamos que você tenha um bug em seu sistema e um desses pontos de dados mostre isso por 10.000 operações. Seu sistema de monitoramento tem apenas 1/20. 000 de chance de escolher isso como o ponto de dados que ele mostra como o máximo!
se você correr o suficiente, o ponto de dados aparecerá eventualmente, mas, como resultado, parecerá um caso de borda esporádico, mesmo que esteja acontecendo com um de seus clientes a cada minuto! Quando você não provar dados e tiver um desses picos, ele aparecerá claramente em seu percentil 99,99 e seu máximo aparecerá perto dele, sinalizando que você tem um bug em seu programa. Ao amostrar seus dados, no entanto, ele não aparecerá com tanta frequência, o que significa que você não o verá como um bug, mas sim como um soluço. Isso significa que sua equipe de engenharia não perceberá o significado disso!
não deixe sua ferramenta de monitoramento enganá-lo a pensar que você sabe o que está acontecendo com sua latência.
Escolha uma ferramenta que não forneça dados amostrados. Escolha uma ferramenta que não Média seus percentis globais. Comece um teste gratuito de duas semanas hoje!
