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:
- Use o SDK do Azure Application Insights para instrumentar seu aplicativo enviando telemetria personalizada para o Azure Monitor.
- Instale o Agente do Azure Monitor em sua máquina virtual ou conjunto de escala de máquina virtual do Azure Windows ou Linux e use uma regra de coleta de dados para enviar contadores de desempenho para métricas do Azure Monitor.
- Instale a extensão de Diagnóstico do Azure na sua VM do Azure, Conjunto de Dimensionamento de Máquina Virtual, VM clássica ou serviço de nuvem clássico. Em seguida, envie contadores de desempenho para o Azure Monitor.
- Instale o agente InfluxData Telegraf em sua VM Linux do Azure. Envie métricas usando o plug-in de saída do Azure Monitor.
- Envie métricas personalizadas diretamente para a API REST do Azure Monitor.
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
Para fornecer uma experiência melhor, as métricas personalizadas enviadas para o Azure Monitor a partir da API (SDKs) do Application Insights Classic são sempre armazenadas no Log Analytics e no Metrics Store. Seu custo para armazenar essas métricas é baseado apenas no volume ingerido pelo Log Analytics. Não há custo adicional para os dados armazenados no Metrics Store.
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
- Aceda ao portal do Azure.
- Selecione o painel Monitor .
- Selecione Métricas.
- Selecione um recurso contra o qual você emitiu métricas personalizadas.
- Selecione o namespace de métricas para sua métrica personalizada.
- 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:
Categoria | 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.
- Navegue até a seção Monitor do portal do Azure.
- Selecione Métricas no lado esquerdo.
- Em Selecione um escopo, verifique a assinatura aplicável e os grupos de recursos.
- Em Refinar escopo, escolha Uso de Métrica Personalizada e o local desejado.
- Selecione o botão Aplicar.
- 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 CPU_server_abcdef01-319d-4a50-b27e-abcdef012345
devem ser definidas como métricas CPU
e 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: