Visualização e agregação das Métricas do Azure Monitor explicadas

Este artigo explica a agregação de métricas no banco de dados de séries cronológicas do Azure Monitor que apoiam métricas da plataforma do Azure Monitor e métricas personalizadas. Este artigo também se aplica às métricas padrão do Application Insights.

Este é um tópico complexo e não é necessário entender todas as informações neste artigo para usar as métricas do Azure Monitor de forma eficaz.

Visão geral e termos

Quando você adiciona uma métrica a um gráfico, o explorador de métricas pré-seleciona automaticamente sua agregação padrão. O padrão faz sentido nos cenários básicos, mas você pode usar agregações diferentes para obter mais informações sobre a métrica. A visualização de diferentes agregações em um gráfico requer que você entenda como o explorador de métricas lida com elas.

Vamos definir alguns termos claramente primeiro:

  • Valor métrico – Um único valor de medição coletado para um recurso específico.
  • Banco de dados de séries temporais - Um banco de dados otimizado para o armazenamento e a recuperação de pontos de dados , todos contendo um valor e um carimbo de data/hora correspondente.
  • Período de tempo – Um período de tempo genérico.
  • Intervalo de tempo – O período de tempo entre a coleta de dois valores métricos.
  • Intervalo de tempo – O período de tempo exibido em um gráfico. O padrão típico é 24 horas. Apenas gamas específicas estão disponíveis.
  • Granularidade de tempo ou granulação de tempo – O período de tempo usado para agregar valores juntos para permitir a exibição em um gráfico. Apenas gamas específicas estão disponíveis. O mínimo atual é de 1 minuto. O valor de granularidade de tempo deve ser menor do que o intervalo de tempo selecionado para ser útil, caso contrário, apenas um valor é mostrado para todo o gráfico.
  • Tipo de agregação – Um tipo de estatística calculada a partir de vários valores métricos.
  • Agregar – O processo de pegar vários valores de entrada e, em seguida, usá-los para produzir um único valor de saída através das regras definidas pelo tipo de agregação. Por exemplo, tomando uma média de vários valores.

Resumo do processo

As métricas são uma série de valores armazenados com um carimbo de data/hora. No Azure, a maioria das métricas é armazenada no banco de dados de séries cronológicas do Azure Metrics. Quando você plota um gráfico, os valores das métricas selecionadas são recuperados do banco de dados e, em seguida, agregados separadamente com base na granularidade de tempo escolhida (também conhecida como grão de tempo). Você seleciona o tamanho da granularidade de tempo usando o seletor de tempo do explorador de métricas. Se você não fizer uma seleção explícita, a granularidade de tempo será selecionada automaticamente com base no intervalo de tempo selecionado no momento. Uma vez selecionados, os valores métricos que foram capturados durante cada intervalo de granularidade de tempo são agregados e colocados no gráfico - um ponto de dados por intervalo.

Tipos de agregação

Há cinco tipos básicos de agregação disponíveis no explorador de métricas. O explorador de métricas oculta as agregações que são irrelevantes e não podem ser usadas para uma determinada métrica.

  • Soma – a soma de todos os valores capturados ao longo do intervalo de agregação. Às vezes referida como a agregação Total.
  • Contagem – o número de medições capturadas ao longo do intervalo de agregação. A contagem não olha para o valor da medição, apenas para o número de registros.
  • Média – a média dos valores métricos capturados ao longo do intervalo de agregação. Para a maioria das métricas, esse valor é Soma/Contagem.
  • Min – o menor valor capturado ao longo do intervalo de agregação.
  • Max – o maior valor capturado ao longo do intervalo de agregação.

Por exemplo, suponha que um gráfico esteja mostrando a métrica Total de Saída de Rede para uma VM usando a agregação SOMA no último período de tempo de 24 horas. O intervalo de tempo e a granularidade podem ser alterados a partir do canto superior direito do gráfico, como visto na captura de tela a seguir.

Screenshot showing time range and time granularity picker

Para granularidade de tempo = 30 minutos e intervalo de tempo = 24 horas:

  • O gráfico é desenhado a partir de 48 pontos de dados. Isso significa 24 horas x 2 pontos de dados por hora (60min/30min) agregados de 1 minuto.
  • O gráfico de linhas conecta 48 pontos na área do gráfico do gráfico.
  • Cada ponto de dados representa a soma de todos os bytes de saída da rede enviados durante cada um dos períodos de tempo relevantes de 30 minutos.

Screenshot showing data on a line graph set to 24-hour time range and 30-minute time granularity

Clique nas imagens nesta seção para ver versões maiores.

Se você alternar a granularidade de tempo para 15 minutos, o gráfico será desenhado a partir de 96 pontos de dados agregados. Ou seja, 60min/15min = 4 pontos de dados por hora x 24 horas.

Screenshot showing data on a line graph set to 24-hour time range and 15-minute time granularity

Para granularidade de tempo de 5 minutos, você obtém 24 x (60/5) = 288 pontos.

Screenshot showing data on a line graph set to 24-hour time range and 5-minute time granularity

Para granularidade de tempo de 1 minuto (a menor possível no gráfico), você obtém 24 x 60/1 = 1440 pontos.

Screenshot showing data on a line graph set to 24-hour time range and 1-minute time granularity

Os gráficos parecem diferentes para essas somas, como mostrado nas capturas de tela anteriores. Observe como essa VM tem muita saída em um pequeno período de tempo em relação ao resto da janela de tempo.

A granularidade do tempo permite ajustar a relação "sinal-ruído" em um gráfico. Agregações mais altas removem o ruído e suavizam os picos. Observe as variações no gráfico inferior de 1 minuto e como elas suavizam à medida que você vai para valores de granularidade mais altos.

Esse comportamento de suavização é importante quando você envia esses dados para outros sistemas, por exemplo, alertas. Normalmente, você geralmente não quer ser alertado por picos muito curtos no tempo de CPU acima de 90%. Mas se a CPU permanecer em 90% por 5 minutos, isso provavelmente é importante. Se você configurar uma regra de alerta na CPU (ou qualquer métrica), aumentar a granularidade do tempo pode reduzir o número de alertas falsos recebidos.

É importante estabelecer o que é "normal" para sua carga de trabalho para saber qual intervalo de tempo é melhor. Este é um dos benefícios dos alertas dinâmicos, que é um tópico diferente não abordado aqui.

Como o sistema coleta métricas

A coleta de dados varia de acordo com a métrica.

Frequência de recolha da medição

Existem dois tipos de períodos de recolha.

  • Regular - A métrica é reunida em um intervalo de tempo consistente que não varia.

  • Baseado em atividade - A métrica é coletada com base em quando ocorre uma transação de um determinado tipo. Cada transação tem uma entrada métrica e um carimbo de data/hora. Eles não são coletados em intervalos regulares, portanto, há um número variável de registros ao longo de um determinado período de tempo.

Granularidade

A granularidade de tempo mínimo é de 1 minuto, mas o sistema subjacente pode capturar dados mais rapidamente, dependendo da métrica. Por exemplo, a porcentagem de CPU para uma VM do Azure é capturada em um intervalo de tempo de 15 segundos. Como as falhas HTTP são rastreadas como transações, elas podem facilmente exceder muito mais de uma por minuto. Outras métricas, como o Armazenamento SQL, são capturadas em um intervalo de tempo a cada 20 minutos. Essa escolha cabe ao provedor de recursos individual e ao tipo. A maioria tenta fornecer o menor intervalo de tempo possível.

Dimensões, divisão e filtragem

As métricas são capturadas para cada recurso individual. No entanto, o nível em que as métricas são coletadas, armazenadas e podem ser mapeadas pode variar. Esse nível é representado por métricas adicionais disponíveis em dimensões de métricas. Cada provedor de recursos individual consegue definir o quão detalhados são os dados que coletam. O Azure Monitor define apenas como esses detalhes devem ser apresentados e armazenados.

Ao criar um gráfico de uma métrica no explorador de métricas, você tem a opção de "dividir" o gráfico por uma dimensão. Dividir um gráfico significa que você está examinando os dados subjacentes para obter mais detalhes e vendo esses dados mapeados ou filtrados no explorador de métricas.

Por exemplo, Microsoft.ApiManagement/service tem Localização como uma dimensão para muitas métricas.

  • A capacidade é uma dessas métricas. Ter a dimensão Localização implica que o sistema subjacente está armazenando um registro métrico para a capacidade de cada local, em vez de apenas um para a quantidade agregada. Em seguida, você pode recuperar ou dividir essas informações em um gráfico métrico.

  • Analisando a Duração Geral das Solicitações de Gateway, há 2 dimensões Localização e Nome do Host, novamente informando a localização de uma duração e de qual nome de host ela veio.

  • Uma das métricas mais flexíveis, Solicitações, tem 7 dimensões diferentes.

Consulte o artigo com suporte de métricas do Azure Monitor para obter detalhes sobre cada métrica e as dimensões disponíveis. Além disso, a documentação para cada provedor de recursos e tipo pode fornecer informações adicionais sobre as dimensões e o que eles medem.

Você pode usar a divisão e a filtragem juntas para analisar um problema. Abaixo está um exemplo de um gráfico mostrando os bytes médios de gravação de disco para um grupo de VMs em um grupo de recursos. Temos um rollup de todas as VMs com essa métrica, mas podemos querer nos aprofundar em ver quais são realmente responsáveis pelos picos por volta das 6h. São a mesma máquina? Quantas máquinas estão envolvidas?

Screenshot showing total Disk Write Bytes for all virtual machines in Contoso Hotels resource group

Clique nas imagens nesta seção para ver versões maiores.

Quando aplicamos a divisão, podemos ver os dados subjacentes, mas é um pouco confuso. Acontece que há 20 VMs sendo agregadas no gráfico acima. Neste caso, usamos nosso mouse para pairar sobre o grande pico às 6h que nos diz que CH-DCVM11 é a causa. mas é difícil ver o resto dos dados associados a essa VM devido a outras VMs abarrotando o gráfico.

Screenshot showing Disk Write Bytes for all virtual machines in Contoso Hotels resource group split by virtual machine name

O uso da filtragem nos permite limpar o gráfico para ver o que realmente está acontecendo. Você pode marcar ou desmarcar as VMs que deseja ver. Observe as linhas pontilhadas. Estes são mencionados numa secção posterior.

Screenshot showing Disk Write Bytes for all virtual machines in Contoso Hotels resource group split and filtered by virtual machine name

Para obter mais informações sobre como mostrar dados de dimensão dividida em um gráfico do explorador de métricas, consulte Recursos avançados do explorador de métricas - filtros e divisão.

Valores NULL e zero

Quando o sistema espera dados métricos de um recurso, mas não os recebe, ele registra um valor NULL. NULL é diferente de um valor zero, o que se torna importante no cálculo de agregações e gráficos. Os valores NULL não são contados como medições válidas.

NULLs aparecem de forma diferente em gráficos diferentes. Os gráficos de dispersão ignoram a exibição de um ponto no gráfico. Os gráficos de barras ignoram a exibição da barra. Em gráficos de linha, NULL pode aparecer como linhas pontilhadas ou tracejadas como as mostradas na captura de tela na seção anterior. Ao calcular médias que incluem NULLs, há menos pontos de dados para tirar a média. Esse comportamento às vezes pode resultar em uma queda inesperada nos valores em um gráfico, embora geralmente menos do que se o valor fosse convertido em zero e usado como um ponto de dados válido.

As métricas personalizadas sempre usam NULLs quando nenhum dado é recebido. Com as métricas da plataforma, cada provedor de recursos decide se deseja usar zeros ou NULLs com base no que faz mais sentido para uma determinada métrica.

Os alertas do Azure Monitor usam os valores que o provedor de recursos grava no banco de dados de métricas, portanto, é importante saber como o provedor de recursos lida com NULLs exibindo os dados primeiro.

Como funciona a agregação

Os gráficos de métricas no sistema anterior mostram diferentes tipos de dados agregados. O sistema pré-agrega os dados para que os gráficos solicitados possam ser mostrados mais rapidamente sem muitos cálculos repetidos.

Neste exemplo:

  • Estamos coletando uma métrica transacional fictícia chamada falhas HTTP
  • Servidor é uma dimensão para a métrica de falhas HTTP .
  • Temos 3 servidores - Servidor A, B e C.

Para simplificar a explicação, começaremos apenas com o tipo de agregação SOMA.

Agregação de sub minuto a 1 minuto

Primeiro, os dados brutos de métricas são coletados e armazenados no banco de dados de métricas do Azure Monitor. Nesse caso, cada servidor tem registros de transação armazenados com um carimbo de data/hora porque o servidor é uma dimensão. Dado que o menor período de tempo que você pode visualizar como cliente é de 1 minuto, esses carimbos de data/hora são primeiro agregados em valores métricos de 1 minuto para cada servidor individual. O processo de agregação para o Servidor B é mostrado no gráfico abaixo. Os servidores A e C são feitos da mesma forma e têm dados diferentes.

Screenshot showing sub minute transactional entries into 1-minute aggregations.

Os valores agregados resultantes de 1 minuto são armazenados como novas entradas no banco de dados de métricas para que possam ser reunidos para cálculos posteriores.

Screenshot showing multiple 1-minute aggregated entries across dimension of server. Server A, B, and C shown individually

Agregação de dimensões

Os cálculos de 1 minuto são então recolhidos por dimensão e novamente armazenados como registros individuais. Nesse caso, todos os dados de todos os servidores individuais são agregados em uma métrica de intervalo de 1 minuto e armazenados no banco de dados de métricas para uso em agregações posteriores.

Screenshot showing multiple 1-minute aggregated entries of Server A, B, and C aggregated into 1-minute All Servers entires

Para maior clareza, a tabela a seguir mostra o método de agregação.

Period Servidor A Servidor B Servidor C Soma (A+B+C)
Minuto 1 1 1 1 3
Minuto 2 0 5 5 6
Minuto 3 0 5 5 6
Minuto 4 2 3 4 9
Minuto 5 5 0 3 4
Minuto 6 5 0 4 5
Minuto 7 1 2 4 7
Minuto 8 0 5 0 5
Minuto 9 1 1 4 6
Minuto 10 2 1 0 3

Apenas uma dimensão é mostrada acima, mas esse mesmo processo de agregação e armazenamento ocorre para todas as dimensões suportadas por uma métrica.

  • Colete valores em 1 minuto agregado definido por essa dimensão. Armazene esses valores.
  • Recolher a dimensão em uma SOMA agregada de 1 minuto. Armazene esses valores.

Vamos introduzir outra dimensão de falhas HTTP chamada NetworkAdapter. Digamos que tínhamos um número variável de adaptadores por servidor.

  • O servidor A tem 1 adaptador
  • O servidor B tem 2 adaptadores
  • O servidor C tem 3 adaptadores

Recolhemos dados para as seguintes transações separadamente. Seriam marcados com:

  • Um tempo
  • Um valor
  • O servidor de onde a transação veio
  • O adaptador do qual a transação veio

Cada um desses fluxos de subminutos seria então agregado em valores de séries cronológicas de 1 minuto e armazenado no banco de dados de métricas do Azure Monitor:

  • Servidor A, Adaptador 1
  • Servidor B, Adaptador 1
  • Servidor B, Adaptador 2
  • Servidor C, Adaptador 1
  • Servidor C, Adaptador 2
  • Servidor C, Adaptador 3

Além disso, as seguintes agregações recolhidas também seriam armazenadas:

  • Servidor A, Adaptador 1 (porque não há nada para colapsar, ele seria armazenado novamente)
  • Servidor B, Adaptador 1+2
  • Servidor C, Adaptador 1+2+3
  • Servidores TODOS, Adaptadores TODOS

Isso mostra que métricas com grande número de dimensões têm um número maior de agregações. Não é importante conhecer todas as permutações, apenas entender o raciocínio. O sistema quer ter os dados individuais e os dados agregados armazenados para recuperação rápida para acesso em qualquer gráfico. O sistema seleciona a agregação armazenada mais relevante ou os dados brutos subjacentes, dependendo do que você escolher exibir.

Agregação sem dimensões

Como essa métrica tem uma dimensão Server, você pode acessar os dados subjacentes para o servidor A, B e C acima por meio de divisão e filtragem, conforme explicado anteriormente neste artigo. Se a métrica não tivesse Servidor como dimensão, você, como cliente, só poderia acessar as somas agregadas de 1 minuto mostradas em preto no diagrama. Ou seja, os valores de 3, 6, 6, 9, etc. O sistema também não faria o trabalho subjacente para agregar valores divididos, nunca os usaria no explorador de métricas ou os enviaria por meio da API REST de métricas.

Granularidades do tempo de visualização acima de 1 minuto

Se você solicitar métricas com uma granularidade maior, o sistema usará as somas agregadas de 1 minuto para calcular as somas para as granularidades de tempo maiores. Abaixo, linhas pontilhadas mostram o método de soma para as granularidades de tempo de 2 minutos e 5 minutos. Mais uma vez, estamos mostrando apenas o tipo de agregação SUM para simplificar.

Screenshot showing multiple 1-minute aggregated entries across dimension of server aggregated into 2-min and 5-min time periods.

Para a granularidade de tempo de 2 minutos.

Period Montantes
Minuto 1 & 2 (3 + 6) = 9
Minuto 3 & 4 (6 + 9) = 15
Minuto 4 & 5 (4 + 5) = 9
Minuto 6 & 7 (7 + 1) = 8
Minuto 8 & 9 (6 + 3) = 9

Para granularidade de tempo de 5 minutos.

Period Montantes
Minutos 1 a 5 3 + 6 + 6 + 9 + 4 = 28
Minutos 6 a 10 5 + 7 + 1 + 6 + 3 = 22

O sistema utiliza os dados agregados armazenados que proporcionam o melhor desempenho.

Abaixo está o diagrama maior para o processo de agregação de 1 minuto acima, com algumas das setas deixadas de fora para melhorar a legibilidade.

Screenshot showing consolidation of previous 3 screenshots. Multiple 1-minute aggregated entries across dimension of server aggregated in 1-minute, 2-minute, and 5-minute intervals. Server A, B, and C shown individually

Exemplo mais complexo

A seguir está um exemplo maior usando valores para uma métrica fictícia chamada tempo de resposta HTTP em milissegundos. Aqui introduzimos níveis adicionais de complexidade.

  1. Mostramos a agregação para Soma, Contagem, Mínimo e Máximo e o cálculo para Média.
  2. Mostramos valores NULL e como eles afetam os cálculos.

Considere o seguinte exemplo. As caixas e setas mostram exemplos de como os valores são agregados e calculados.

O mesmo processo de pré-agregação de 1 minuto descrito na seção anterior ocorre para Somas, Contagem, Mínimo e Máximo. No entanto, a média NÃO é pré-agregada. É recalculado utilizando dados agregados para evitar erros de cálculo.

Screenshot showing complex example of aggregation and calculation of sum, count, min, max and average from 1 minute to 10 minutes.

Considere o minuto 6 para a agregação de 1 minuto, conforme destacado acima. Este minuto é o ponto em que o Servidor B ficou offline e parou de relatar dados, talvez devido a uma reinicialização.

A partir do minuto 6 acima, os tipos de agregação de 1 minuto calculados são:

Tipo de agregação valor Notas
Sum 53+20=73
Count 2 Mostra o efeito de NULLs. O valor teria sido 3 se o servidor estivesse online.
Mínimo 20
Máximo 53
Média 73 / 2 Sempre a Soma dividida pelo Conde. Ele nunca é armazenado e sempre recalculado para cada granularidade de tempo usando os números agregados para essa granularidade. Observe o recálculo para as granularidades de tempo de 5 minutos e 10 minutos, conforme destacado acima.

A cor vermelha do texto indica valores que podem ser considerados fora do intervalo normal e mostra como eles se propagam (ou falham) à medida que a granularidade do tempo aumenta. Observe como o Min e o Max indicam que há anomalias subjacentes, enquanto a Média e as Somas perdem essas informações à medida que a granularidade do tempo aumenta.

Você também pode ver que os NULLs fornecem um cálculo melhor da média do que se zeros fossem usados em vez disso.

Nota

Embora não seja o caso neste exemplo, Count é igual a Sum nos casos em que uma métrica é sempre capturada com o valor de 1. Isso é comum quando uma métrica rastreia a ocorrência de um evento transacional - por exemplo, o número de falhas HTTP mencionadas em um exemplo anterior neste artigo.

Próximos passos