Métricas personalizadas no Azure Monitor (versão prévia)

Ao implantar recursos e aplicativos no Azure, é melhor começar a coletar dados telemétricos para obter percepções sobre sua integridade e desempenho. O Azure disponibiliza algumas métricas para você imediatamente. Essas métricas são chamadas de padrão ou de plataforma. No entanto, elas são limitadas.

Você pode querer coletar alguns indicadores de desempenho personalizados ou métricas específicas de negócios para fornecer insights mais profundos. Essas métricas personalizadas podem ser coletadas por meio da telemetria do aplicativo, de um agente que é executado nos recursos do Azure ou até mesmo de um sistema de monitoramento externo. Em seguida, podem ser enviadas diretamente para o Azure Monitor. Depois que as métricas personalizadas são publicadas no Azure Monitor, você pode procurar, consultar e alertar sobre métricas personalizadas para os recursos e aplicativos do Azure, lado a lado com as 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

Métricas personalizadas podem ser enviadas ao Monitor do Azure por vários métodos:

Modelo de preços e retenção

Para obter detalhes sobre quando a cobrança será habilitada para métricas personalizadas e consultas de métricas, confira a página de preços do Azure Monitor. Em resumo, não há nenhum custo para ingerir métricas padrão (métricas de plataforma) no repositório de métricas do Azure Monitor, mas as métricas personalizadas gerarão custos quando elas entrarem em disponibilidade geral. As consultas à API de métricas geram custos.

As métricas personalizadas são mantidas durante o mesmo período de tempo que as métricas de plataforma.

Observação

As métricas enviadas para Azure Monitor por meio do SDK do Application Insights são cobradas como dados de log ingeridos. Elas incorrerão em cobranças de métricas adicionais se o recurso Habilitar alertas em dimensões de métricas personalizadas do Application Insights 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 personalizadas para permitir o uso de alertas mais complexos. Saiba mais sobre o modelo de preços do Application Insights e os preços em sua região.

Como enviar métricas personalizadas

Quando você envia as métricas personalizadas para o Azure Monitor cada ponto de dados ou valor relatado nas métricas deve incluir as informações a seguir.

Autenticação

Para enviar métricas personalizadas para o Monitor do Azure, a entidade que envia a métrica precisa de um token válido do Azure AD (Azure Active Directory) no cabeçalho Portador da solicitação. Maneiras de adquirir um token de portador válido:

  • Identidades gerenciadas para recursos do Azure. Você pode usar uma identidade gerenciada para dar permissões aos recursos para executar determinadas operações. Um exemplo é permitir que um recurso emita métricas sobre si mesmo. Um recurso, ou sua identidade gerenciada, pode receber permissões de Monitoring Metrics Publisher em outro recurso. Com essa permissão, a identidade gerenciada também pode emitir métricas para outros recursos.

  • Entidade de serviço do Azure AD. Nesse cenário, um aplicativo ou serviço do Azure AD pode receber permissões para emitir métricas sobre um recurso do Azure. Para autenticar a solicitação, o Monitor do Azure valida o token do aplicativo usando as chaves públicas do Azure AD. A função existente do Monitoring Metrics Publisher já tem essa permissão. Ele está disponível no portal do Azure.

    A entidade de serviço, dependendo dos recursos para os quais ela emite métricas personalizadas, pode receber a função Monitoring Metrics Publisher no escopo necessário. Exemplos são uma assinatura, grupo de recursos ou recurso específico.

Dica

Quando você solicitar que um token do Azure AD emita métricas personalizadas, verifique se o público ou recurso para o qual o token é solicitado é https://monitoring.azure.com/. Inclua uma barra à direita.

Assunto

Essa propriedade indica a ID do recurso do Azure para a qual a métrica personalizada é relatada. Essas informações serão codificadas na URL da chamada à API. Cada API pode enviar valores de métrica apenas para um único recurso do Azure.

Observação

Você não pode emitir métricas personalizadas contra o ID do recurso de um grupo de recursos ou assinatura.

Região

Essa propriedade captura a região do Azure em que o recurso para o qual você está emitindo métricas está implantado. As métricas devem ser emitidas para o mesmo ponto de extremidade regional do Azure Monitor que a região em que o recurso está implantado. Por exemplo, as métricas personalizadas de uma VM implantada no oeste dos EUA devem ser enviadas ao ponto de extremidade regional do Azure Monitor WestUS. As informações de região também estão codificadas na URL da chamada à API.

Observação

Durante a visualização pública, as métricas personalizadas estão disponíveis apenas em um subconjunto de regiões do Azure. Uma lista de regiões com suporte é fornecida em uma seção posterior deste artigo.

Timestamp

Cada ponto de dados enviado ao Azure Monitor deve estar marcado com um carimbo de data/hora. Esse registro de data e hora captura a data e a hora em que o valor da métrica é medido ou coletado. O Monitor do Azure aceita dados de métricas com registros de data e hora em até 20 minutos no passado e 5 minutos no futuro. O carimbo de data/hora precisa estar no formato ISO 8601.

Namespace

Namespaces são uma maneira de categorizar ou agrupar métricas semelhantes. Ao usar namespaces, você pode obter isolamento entre grupos de métricas que podem coletar diferentes insights ou indicadores de desempenho. Por exemplo, você pode ter um namespace chamado contosomemorymetrics, que monitora as métricas de uso de memória que formam o perfil do seu aplicativo. Outro namespace, chamado contosoapptransaction, pode rastrear todas as métricas sobre transações do usuário em seu aplicativo.

Nome

É o nome da métrica que está sendo relatada. Normalmente, o nome é descritivo para ajudar a identificar o que está sendo medido. Um exemplo é uma métrica que mede o número de bytes de memória usados em uma VM. Pode ter um nome de métrica como Memory Bytes In Use.

Chaves de dimensão

Uma dimensão é um par chave-valor que ajuda a descrever outras características sobre a métrica que está sendo coletada. Usando as outras características, você pode coletar mais informações sobre a métrica, o que permite insights mais profundos.

Por exemplo, a métrica Memory Bytes In Use pode ter uma chave de dimensão chamada Process que captura quantos bytes de memória cada processo em uma VM consome. Usando essa chave, você pode filtrar a métrica para ver quantos processos específicos de memória usam ou para identificar os cinco principais processos pelo uso da memória.

As dimensões são opcionais, e nem todas as métricas têm dimensões. Uma métrica personalizada pode ter até dez dimensões.

Valores de dimensão

Ao relatar um ponto de dados de métrica, para cada chave de dimensão na métrica que está sendo relatada, há um valor de dimensão correspondente. Por exemplo, você pode querer relatar a memória usada pelo ContosoApp em sua VM:

  • O nome da métrica seria Bytes de Memória em Uso.
  • A chave de dimensão seria processo.
  • O valor da dimensão seria ContosoApp.exe .

Ao publicar um valor de métrica, você pode especificar apenas um valor de dimensão por chave de dimensão. Se você coletar a mesma utilização de memória para vários processos na VM, poderá relatar vários valores de métrica para esse registro de data e hora. Cada valor de métrica especificaria um valor de dimensão diferente para a chave de dimensão Process.

Embora as dimensões sejam opcionais, se uma postagem de métrica definir chaves de dimensão, os valores de dimensão correspondentes serão obrigatórios.

Valores métricos

O Azure Monitor armazena todas as métricas em intervalos com granularidade de um minuto. Durante determinado minuto, uma métrica pode precisar ser amostrada várias vezes. Um exemplo é a utilização da CPU. Ou uma métrica pode precisar ser medida para muitos eventos discretos, como latências de transação de logon.

Para limitar o número de valores brutos que você precisa emitir e pagar no Azure Monitor, é possível pré-agregar os valores localmente e emiti-los:

  • Mín.: O valor mínimo observado de todas as amostras e medições durante o minuto.
  • Máx: O valor máximo observado de todas as amostras e medições durante o minuto.
  • Sum: A soma de todos os valores observados de todas as amostras e medições durante o minuto.
  • Contar: o número de amostras e medições feitas durante o minuto.

Por exemplo, se há quatro transações de conexão em seu aplicativo durante um minuto, as latências medidas resultantes para cada um podem ser:

Transação 1 Transação 2 Transação 3 Transação 4
7 ms 4 ms 13 ms 16 ms

Assim, a publicação de métrica resultante para o Azure Monitor seria:

  • Mín.: 4
  • Máx.: 16
  • Soma: 40
  • Contagem: 4

Se o seu aplicativo não é capaz de pré-agregar localmente e precisa emitir cada exemplo ou evento separado imediatamente após a coleta, você pode emitir os valores de medida brutos. Por exemplo, toda vez que uma transação de login ocorre no seu aplicativo, você publica uma métrica no Monitor do Azure com apenas uma única medida. Portanto, para uma transação de login que levou 12 milissegundos, a publicação de métrica seria:

  • Mín.: 12
  • Máx.: 12
  • Soma: 12
  • Contagem: 1

Com esse processo, você pode emitir vários valores para a mesma combinação de métrica e dimensão durante determinado minuto. O Azure Monitor pega todos os valores brutos emitidos por determinado minuto e os agrega.

Publicação de métrica personalizada de exemplo

No exemplo a seguir, você cria uma métrica personalizada chamada Bytes de Memória em Uso no namespace Perfil de Memória da métrica para uma máquina virtual. A métrica tem uma única dimensão chamada Process. Para o carimbo de data/hora, os valores de métrica são emitidos para dois processos.

{
    "time": "2018-08-20T11:25:20-7:00",
    "data": {

      "baseData": {

        "metric": "Memory Bytes in Use",
        "namespace": "Memory Profile",
        "dimNames": [
          "Process"
        ],
        "series": [
          {
            "dimValues": [
              "ContosoApp.exe"
            ],
            "min": 10,
            "max": 89,
            "sum": 190,
            "count": 4
          },
          {
            "dimValues": [
              "SalesApp.exe"
            ],
            "min": 10,
            "max": 23,
            "sum": 86,
            "count": 4
          }
        ]
      }
    }
  }

Observação

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

Definições de métricas personalizadas

Não há necessidade de predefinir uma métrica personalizada no Monitor do Azure antes de ser emitida. Cada ponto de dados de métrica publicado contém informações de espaço de nomes, nome e dimensão. Portanto, na primeira vez em que uma métrica personalizada é emitida para o Azure Monitor, uma definição de métrica é criada automaticamente. Essa definição de métrica é, então, detectável em qualquer recurso em que a métrica é emitida por meio das definições de métrica.

Observação

O Azure Monitor ainda não dá suporte a definição de Unidades para uma métrica personalizada.

Usando métricas personalizadas

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

Observação

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

Procurar suas métricas personalizadas no portal do Azure

  1. Acesse o portal do Azure.
  2. Selecione o painel Monitor.
  3. Selecione Métricas.
  4. Selecione um recurso em que 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, confira Introdução ao Azure Metrics Explorer.

Regiões com suporte

Durante a pré-visualização pública, a capacidade de publicar métricas personalizadas está disponível apenas em um subconjunto de regiões do Azure. Essa restrição significa que as métricas podem ser publicadas apenas para recursos em uma das regiões suportadas. Para obter mais informações sobre regiões do Azure, confira Geografias do Azure.

A tabela a seguir lista as regiões do Azure com suporte para métricas personalizadas. Ela também lista os terminais correspondentes para os quais as métricas de recursos nessas regiões devem ser publicadas. O código de região do Azure usado no prefixo do ponto de extremidade é apenas o nome da região com o espaço em branco removido.

Região do Azure Prefixo de ponto de extremidade regional
Todas as regiões de nuvem pública https://<código_da_região_do_Azure>.monitoring.azure.com

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é três minutos para aparecer. Depois que os dados estão 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 poderá levar de uma semana a um mês para ser excluída do sistema.

Cotas e limites

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

Categoria Limite
Total de séries temporais ativas em uma assinatura em todas as regiões em que você implantou 50.000
Chaves de dimensão por métrica 10
Tamanho da cadeia de caracteres para namespaces de métrica, nomes de métrica, chaves de dimensão e valores de dimensão 256 caracteres

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

Para entender o limite de 50.000 na série temporal, considere a seguinte métrica:

Tempo de resposta do servidor com as dimensões: Região, Departamento, CustomerID

Com essa métrica, se você tiver dez regiões, 20 departamentos e 100 clientes, isso resultará em 10 x 20 x 100 = 20 mil séries temporais.

Se você tiver 100 regiões, 200 departamentos e 2.000 clientes, isso equivalerá a 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.

Novamente, 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 o total atual de métricas da série temporal ativa 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 Selecionar um escopo, verifique a assinatura aplicável e os grupos de recursos.
  4. Em Refinar escopo, escolha Uso de Métrica Personalizado 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.

Limitações e considerações de design

Usar 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 limitará ou fará amostragem (usa apenas um percentual de sua telemetria e ignora o restante) se o conjunto de dados inicial se tornar grande demais. Devido a esse comportamento, você não pode usá-lo para fins de auditoria, pois alguns registros provavelmente serão removidos.

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. Sempre que a variável alterar seu valor, o Azure Monitor gera uma nova métrica. O Azure Monitor atinge rapidamente o limite do número de métricas. Em geral, quando desenvolvedores querem incluir uma variável no nome da métrica, eles realmente querem acompanhar várias séries temporais em uma métrica e devem usar dimensões em vez dos nomes de métrica variável.

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

Como um teste, pergunte se você em algum momento transformará esses dados em um grafo. Se você tiver dez ou talvez até mesmo 100 servidores, pode ser útil vê-los em um grafo para comparação. Mas se você tivesse 1.000, o grafo resultante provavelmente seria difícil ou impossível de ler. A melhor prática é manter menos de 100 valores válidos. O uso de até 300 é uma área cinza. Se você precisar ultrapassar esse valor, use logs personalizados do Azure Monitor em vez disso.

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

  • As métricas tornam-se não confiáveis devido à 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 está em visualização pública. Quando as cobranças começarem no futuro, você terá encargos inesperados. O plano é cobrar pelo consumo de métricas com base no número de séries temporais monitoradas e no número de chamadas à 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 da variável.

Mas se a alta cardinalidade for essencial para seu cenário, as métricas agregadas provavelmente não serão a escolha certa. Alternar para usar logs personalizados (ou seja, chamadas à API trackMetric com trackEvent). No entanto, considere que os logs não agregam valores para que cada entrada seja 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 poderá causar atrasos de redução e ingestão.

Próximas etapas

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