Share via


Métricas personalizadas no Azure Monitor (visualização)

O Azure disponibiliza algumas métricas prontas para você. Essas métricas são chamadas de padrão ou plataforma. As métricas personalizadas são indicadores de desempenho ou métricas específicas do negócio que podem ser coletadas por meio da telemetria do seu aplicativo, do Azure Monitor Agent, de uma extensão de diagnóstico executada em seus recursos do Azure ou de um sistema de monitoramento externo. Depois que as métricas personalizadas são publicadas no Azure Monitor, você pode navegar, consultar e alertar sobre elas ao lado das métricas padrão do Azure.

As métricas personalizadas do Azure Monitor estão atualmente em visualização pública.

Métodos para enviar métricas personalizadas

As métricas personalizadas podem ser enviadas para o Azure Monitor por meio de vários métodos:

Modelo de preços e retenção

Em geral, não há custo para ingerir métricas padrão (métricas da plataforma) em um repositório de métricas do Azure Monitor, mas as métricas personalizadas incorrem em custos quando entram na disponibilidade geral. As consultas à API de métricas incorrem em custos. Para obter detalhes sobre quando a cobrança está habilitada para métricas personalizadas e consultas de métricas, verifique a página de preços do Azure Monitor.

As métricas personalizadas são retidas pelo mesmo período de tempo que as métricas da plataforma.

Nota

As métricas enviadas ao Azure Monitor por meio do SDK do Application Insights são cobradas como dados de log ingeridos. Eles incorrem em cobranças de métricas adicionais somente se o recurso do Application Insights Habilitar alertas em dimensões métricas personalizadas tiver sido selecionado. Essa caixa de seleção envia dados para o banco de dados de métricas do Azure Monitor usando a API de métricas personalizada para permitir alertas mais complexos. Saiba mais sobre o modelo de preços e os preços do Application Insights na sua região.

Definições de métricas personalizadas

Cada ponto de dados métrico publicado contém um namespace, nome e informações de dimensão. Na primeira vez que uma métrica personalizada é emitida para o Azure Monitor, uma definição de métrica é criada automaticamente. Essa nova definição de métrica é então detetável em qualquer recurso a partir do qual a métrica é emitida por meio das definições métricas. Não há necessidade de predefinir uma métrica personalizada no Azure Monitor antes que ela seja emitida.

Nota

O Application Insights, a extensão de diagnóstico e o agente InfluxData Telegraf já estão configurados para emitir valores métricos em relação ao ponto de extremidade regional correto e carregar todas as propriedades anteriores em cada emissão.

Usando métricas personalizadas

Depois que as métricas personalizadas forem enviadas ao Azure Monitor, você poderá navegar por elas por meio do portal do Azure e consultá-las por meio das APIs REST do Azure Monitor. Você também pode criar alertas sobre eles para notificá-lo quando certas condições forem atendidas.

Nota

Você precisa ter uma função de leitor ou colaborador para exibir métricas personalizadas. Consulte Leitor de monitoramento.

Navegue pelas suas métricas personalizadas através do portal do Azure

  1. Aceda ao portal do Azure.
  2. Selecione o painel Monitor .
  3. Selecione Métricas.
  4. Selecione um recurso contra o qual você emitiu métricas personalizadas.
  5. Selecione o namespace de métricas para sua métrica personalizada.
  6. Selecione a métrica personalizada.

Para obter mais informações sobre como exibir métricas no portal do Azure, consulte Analisar métricas com o explorador de métricas do Azure Monitor.

Latência e retenção de armazenamento

Uma métrica recém-adicionada ou uma dimensão recém-adicionada a uma métrica pode levar até 3 minutos para aparecer. Depois que os dados estiverem no sistema, eles devem aparecer em menos de 30 segundos 99% do tempo.

Se você excluir uma métrica ou remover uma dimensão, a alteração pode levar de uma semana a um mês para ser excluída do sistema.

Quotas e limites

O Azure Monitor impõe os seguintes limites de uso em métricas personalizadas:

Category Limite
Total de séries cronológicas ativas numa subscrição por região 50 000
Teclas de dimensão por métrica 10
Comprimento da cadeia de caracteres para namespaces de métricas, nomes de métricas, chaves de dimensão e valores de dimensão 256 caracteres
O comprimento combinado de todos os nomes de métricas personalizadas, usando codificação utf-8 64 KB

Uma série temporal ativa é definida como qualquer combinação exclusiva de métrica, chave de dimensão ou valor de dimensão que tenha tido valores de métrica publicados nas últimas 12 horas.

Para entender o limite de 50.000 em séries temporais, considere a seguinte métrica:

Tempo de resposta do servidor com dimensões: região, departamento, CustomerID

Com essa métrica, se você tiver 10 regiões, 20 departamentos e 100 clientes, isso lhe dará 10 x 20 x 100 = 20.000 séries temporais.

Se você tiver 100 regiões, 200 departamentos e 2.000 clientes, isso lhe dará 100 x 200 x 2.000 = 40 milhões de séries temporais, o que está muito acima do limite apenas para essa métrica.

Mais uma vez, esse limite não é para uma métrica individual. É para a soma de todas essas métricas em uma assinatura e região.

Siga as etapas abaixo para ver suas métricas atuais de séries cronológicas totais ativas e mais informações para ajudar na solução de problemas.

  1. Navegue até a seção Monitor do portal do Azure.
  2. Selecione Métricas no lado esquerdo.
  3. Em Selecione um escopo, verifique a assinatura aplicável e os grupos de recursos.
  4. Em Refinar escopo, escolha Uso de Métrica Personalizada e o local desejado.
  5. Selecione o botão Aplicar.
  6. Escolha Série Temporal Ativa, Limite de Série Temporal Ativa ou Série Temporal Limitada.

Há um limite de 64 KB no comprimento combinado de todos os nomes de métricas personalizadas, assumindo utf-8 ou 1 byte por caractere. Se o limite de 64 KB for excedido, os metadados para métricas adicionais não estarão disponíveis. Os nomes de métricas para métricas personalizadas adicionais não aparecerão no portal do Azure em campos de seleção e não serão retornados pela API em solicitações de definições de métrica. Os dados da métrica ainda estão disponíveis e podem ser consultados.

Quando o limite for excedido, reduza o número de métricas que você está enviando ou diminua o comprimento de seus nomes. Em seguida, leva até dois dias para que os nomes das novas métricas apareçam.

Para evitar atingir o limite, não inclua aspetos variáveis ou dimensionais em seus nomes de métricas. Por exemplo, as métricas para o uso da CPU do servidor,CPU_server_12345678-319d-4a50-b27e-1234567890ab e devem ser definidas como métricas CPU e CPU_server_abcdef01-319d-4a50-b27e-abcdef012345 com uma Server dimensão.

Limitações e considerações de design

Usando o Application Insights para fins de auditoria. O pipeline de telemetria do Application Insights é otimizado para minimizar o impacto no desempenho e limitar o tráfego de rede do monitoramento do seu aplicativo. Como tal, ele acelera ou coleta amostras (leva apenas uma porcentagem da sua telemetria e ignora o resto) se o conjunto de dados inicial se tornar muito grande. Devido a esse comportamento, você não pode usá-lo para fins de auditoria porque alguns registros provavelmente serão descartados.

Métricas com uma variável no nome. Não use uma variável como parte do nome da métrica. Em vez disso, use uma constante. Cada vez que a variável altera seu valor, o Azure Monitor gera uma nova métrica. Em seguida, o Azure Monitor atinge rapidamente o limite do número de métricas. Geralmente, quando os desenvolvedores querem incluir uma variável no nome da métrica, eles realmente querem rastrear várias séries temporais dentro de uma métrica e devem usar dimensões em vez de nomes de métricas variáveis.

Dimensões métricas de alta cardinalidade. Métricas com muitos valores válidos em uma dimensão (uma cardinalidade alta) têm muito mais probabilidade de atingir o limite de 50.000. Em geral, você nunca deve usar um valor em constante mudança em uma dimensão. O carimbo de data/hora, por exemplo, nunca deve ser uma dimensão. Você pode usar a ID do servidor, do cliente ou do produto, mas somente se tiver um número menor de cada um desses tipos.

Como teste, pergunte-se se alguma vez você traçaria esses dados em um gráfico. Se você tiver 10 ou talvez até 100 servidores, pode ser útil vê-los todos em um gráfico para comparação. Mas se você tiver 1.000, o gráfico resultante provavelmente será difícil ou impossível de ler. Uma prática recomendada é mantê-lo com menos de 100 valores válidos. Até 300 é uma área cinzenta. Se você precisar ultrapassar esse valor, use os logs personalizados do Azure Monitor.

Se você tiver uma variável no nome ou uma dimensão de alta cardinalidade, os seguintes problemas podem ocorrer:

  • As métricas tornam-se não confiáveis por causa da limitação.
  • O Metrics Explorer não funcionará.
  • Alertas e notificações tornam-se imprevisíveis.
  • Os custos podem aumentar inesperadamente. A Microsoft não está cobrando por métricas personalizadas com dimensões enquanto esse recurso estiver em visualização pública. Depois que as cobranças começarem no futuro, você incorrerá em cobranças inesperadas. O plano é cobrar pelo consumo de métricas com base no número de séries temporais monitoradas e no número de chamadas de API feitas.

Se o nome da métrica ou o valor da dimensão for preenchido com um identificador ou dimensão de alta cardinalidade por engano, você poderá corrigi-lo facilmente removendo a parte variável.

Mas se a alta cardinalidade é essencial para o seu cenário, as métricas agregadas provavelmente não são a escolha certa. Alterne para o uso de logs personalizados (ou seja, chamadas de API trackMetric com trackEvent). No entanto, considere que os logs não agregam valores, portanto, cada entrada será armazenada. Como resultado, se você tiver um grande volume de logs em um pequeno período de tempo (1 milhão por segundo, por exemplo), isso pode causar atrasos de limitação e ingestão.

Próximos passos

Use métricas personalizadas de vários serviços: