Solução de problemas da coleção de métricas do Prometheus no Azure Monitor

Siga as etapas neste artigo para determinar a causa das métricas do Prometheus não estarem sendo coletadas conforme o esperado no Azure Monitor.

O pod de réplica extrai métricas de kube-state-metrics, destinos de extração personalizados no configmap ama-metrics-prometheus-config e destinos de extração personalizados definidos nos Recursos personalizados. Os pods do DaemonSet extraem as métricas dos seguintes destinos sem seus respectivos nós: kubelet, cAdvisor, node-exporter e nos destinos de extração personalizados no configmap ama-metrics-prometheus-config-node. O pod em que você deseja exibir os registros e a interface do usuário do Prometheus dependem de qual destino de extração você está investigando.

Solucionar problemas usando um script do PowerShell

Se você se deparar com um erro ao tentar ativar o monitoramento para o seu cluster do AKS, siga essas instruções para executar o script de resolução de problemas. Esse script foi projetado para fazer um diagnóstico básico de quaisquer problemas de configuração no seu cluster. Você pode anexar os arquivos gerados ao criar uma solicitação de suporte para obter uma resolução mais rápida do seu caso de suporte.

Limitação de Métricas

O serviço Gerenciado do Azure Monitor para Prometheus tem limites e cotas padrão para ingestão. Quando você atingir os limites de ingestão, a limitação poderá ocorrer. Você pode solicitar um aumento nesses limites. Para obter informações sobre os limites de métricas do Prometheus, confira Limites de serviço do Azure Monitor.

No portal do Azure, navegue até seu Espaço de Trabalho do Azure Monitor. Acesse Metrics, e selecione as métricas Active Time Series % Utilization e Events Per Minute Received % Utilization. Verificar se ambos estão abaixo de 100%.

Para obter mais informações sobre o monitoramento e alerta nas suas métricas de ingestão, confira Ingestão de métricas do Workspace do Monitor Azure Monitor.

Lacunas intermitentes na coleta de dados de métricas

Durante as atualizações de nó, você pode ver uma lacuna de 1 a 2 minutos nos dados de métrica para as métricas coletadas do nosso coletor de nível de cluster. Essa lacuna ocorre porque o nó em que ele é executado está sendo atualizado como parte de um processo normal de atualização. Isso afeta alvos em todo o cluster, como kube-state-metrics e destinos de aplicativos personalizados especificados. Isso ocorre quando seu cluster é atualizado manualmente ou por meio da atualização automática. Esse comportamento é esperado e ocorre devido à atualização do nó em que ele é executado. Nenhuma das nossas regras de alerta recomendadas é afetada por este comportamento.

Status do pod

Verifique o status do pod com o seguinte comando:

kubectl get pods -n kube-system | grep ama-metrics

Quando o serviço está em execução corretamente, a seguinte lista de pods no formato ama-metrics-xxxxxxxxxx-xxxxx é retornada:

• ama-metrics-operator-targets-*
• ama-metrics-ksm-*
• ama-metrics-node-* pod para cada nó no cluster.

Cada estado do pod deve ser Running e ter um número de reinicializações igual ao número de alterações de configmap que foram aplicadas. O pod ama-metrics-operator-targets-* pode ter uma reinicialização extra no início e isso é esperado:

Se cada estado do pod for Running, mas apenas um ou mais pods tiverem reinicializações, execute o seguinte comando:

kubectl describe pod <ama-metrics pod name> -n kube-system

• Esse comando fornece o motivo das reinicializações. As reinicializações do pod são esperadas se foram feitas alterações de configmap. Se o motivo da reinicialização for OOMKilled, o pod não poderá acompanhar o volume de métricas. Consulte as recomendações de escala do volume de métricas.

Se os pods estiverem em execução conforme o esperado, o próximo local a ser verificado será nos logs de contêiner.

Verificar se há configurações de rerrotulagem

Se as métricas estiverem ausentes, você também poderá verificar se tem configurações de rerrotulagem. Com as configurações de nova rotulagem, certifique-se de que a nova rotulagem não filtre os alvos e que os rótulos configurados correspondam corretamente aos destinos. Para obter mais informações, consulte Documentação de configuração da nova rotulagem do Prometheus.

Logs dos contêineres

Exiba os logs de contêiner com o seguinte comando:

kubectl logs <ama-metrics pod name> -n kube-system -c prometheus-collector

Na inicialização, todos os erros iniciais são impressos em vermelho, enquanto os avisos são impressos em amarelo. (A exibição de logs coloridos requer pelo menos a versão 7 do PowerShell ou uma distribuição do Linux.)

• Verifique se há um problema ao obter o token de autenticação:
  • A mensagem Nenhuma configuração presente no recurso AKS é registrada a cada 5 minutos.
  • O pod é reiniciado a cada 15 minutos para tentar novamente com o erro: Nenhuma configuração presente para o recurso do AKS.
    • Em caso afirmativo, verifique se a regra de coleta de dados e o ponto de extremidade de coleta de dados existem no seu grupo de recursos.
    • Verifique também se o Espaço de Trabalho do Azure Monitor existe.
    • Verifique se você não tem um cluster do AKS privado e se ele não está vinculado a um Escopo de Link Privado do Azure Monitor em qualquer outro serviço. Não há suporte para esse cenário no momento.

Processamento de configuração

Exiba os logs de contêiner com o seguinte comando:

kubectl logs <ama-metrics-operator-targets pod name> -n kube-system -c config-reader

• Verifique se não há erros ao analisar a configuração do Prometheus, mesclar com quaisquer destinos de recorte padrão habilitados e validar a configuração completa.
• Se você incluiu uma configuração personalizada do Prometheus, verifique se ela foi reconhecida nos logs. Caso contrário:
  • Verifique se o configmap tem o nome correto: ama-metrics-prometheus-config no namespace kube-system.
  • Verifique se, no configmap, sua configuração do Prometheus está em uma seção chamada prometheus-config, em data, como mostrado aqui:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: ama-metrics-prometheus-config
      namespace: kube-system
    data:
      prometheus-config: |-
        scrape_configs:
        - job_name: <your scrape job here>
    

• Se você criou Recursos personalizados, deve ter visualizado erros de validação durante a criação de monitores de pod/serviço. Se você ainda não visualizar as métricas dos destinos, verifique se os logs não mostram erros.

kubectl logs <ama-metrics-operator-targets pod name> -n kube-system -c targetallocator

• Verifique se não há erros de MetricsExtension em relação à autenticação com o espaço de trabalho do Azure Monitor.
• Verifique se há erros do OpenTelemetry collector sobre a extração dos destinos.

Execute o seguinte comando:

kubectl logs <ama-metrics pod name> -n kube-system -c addon-token-adapter

• Esse comando mostra um erro se houver um problema com a autenticação com o espaço de trabalho do Azure Monitor. O exemplo abaixo mostra os logs sem problemas:

Se não houver erros nos logs, a interface do Prometheus poderá ser usada para depuração para verificar a configuração esperada e os destinos que estão sendo extraídos.

Interface do Prometheus

Cada pod ama-metrics-* tem a interface de Usuário do modo Agente do Prometheus disponível na porta 9090. Os destinos de configuração personalizada e Recursos personalizados, são extraídos pelo pod ama-metrics-* e os destinos do nó pelo pod ama-metrics-node-*. Encaminhe a porta para o pod réplica ou um dos pods do conjunto de daemons para verificar os pontos de extremidade de destinos, a descoberta do serviço e a configuração, conforme descrito aqui, para verificar se as configurações personalizadas estão corretas, se os destinos pretendidos foram descobertos para cada trabalho e se não há erros com a extração de destinos específicos.

Execute o comando kubectl port-forward <ama-metrics pod> -n kube-system 9090.

• Abra um navegador no endereço 127.0.0.1:9090/config. Essa interface de usuário tem a configuração completa de extração. Verifique se todos os trabalhos estão incluídos na configuração.

• Acesse 127.0.0.1:9090/service-discovery para exibir os destinos descobertos pelo objeto de descoberta de serviço especificado e qual relabel_configs filtrou os destinos. Por exemplo, quando as métricas de um determinado pod estão ausente, você pode descobrir se esse pod foi descoberto e qual é o seu URI. Em seguida, você pode usar esse URI ao examinar os destinos para ver se há erros de extração.

• Acesse 127.0.0.1:9090/targets para exibir todos os trabalhos, a última vez que o ponto de extremidade desse trabalho extraído e quaisquer erros

Recursos personalizados

• Se você incluiu os Recursos personalizados, verifique se eles aparecem na configuração, descoberta de serviço e destinos.

Configuração

Descoberta de Serviços

Destinos

Se não houver problemas e os destinos pretendidos estiverem sendo raspados, você poderá exibir as métricas exatas que estão sendo raspadas habilitando o modo de depuração.

Modo de depuração

O complemento de métricas pode ser configurado para ser executado no modo de depuração alterando a configuração enabled do configmap em debug-mode para true, seguindo as instruções aqui.

Quando habilitadas, todas as métricas do Prometheus extraídas são hospedadas na porta 9091. Execute o comando a seguir:

kubectl port-forward <ama-metrics pod name> -n kube-system 9091

Acesse 127.0.0.1:9091/metrics em um navegador para ver se as métricas foram extraídas pelo Coletor OpenTelemetry. Essa interface de usuário pode ser acessada para cada ama-metrics-* pod. Se as métricas não estiverem lá, poderá haver um problema com os comprimentos de nome da métrica ou do rótulo ou o número de rótulos. Verifique também se a cota de ingestão das métricas do Prometheus foi excedida, conforme especificado neste artigo.

Nomes de métrica, nomes dos rótulos e valores dos rótulos

Atualmente, a extração de métricas tem as limitações na tabela a seguir:

Verifique a cota de ingestão no espaço de trabalho do Azure Monitor

Se você notar que métricas foram ignoradas, você pode primeiro verificar se os limites de ingestão estão sendo excedidos no seu espaço de trabalho do Azure Monitor. No portal do Azure, você pode verificar o uso atual de qualquer espaço de trabalho do Azure Monitor. Você pode ver as métricas de uso atual no menu Metrics do espaço de trabalho do Azure Monitor. As métricas de utilização a seguir estão disponíveis como métricas padrão para cada espaço de trabalho do Azure Monitor.

• Séries temporais ativas: o número de séries temporais exclusivas recentemente ingeridas no espaço de trabalho nas 12 horas anteriores
• Limite de Série Temporal Ativa: o limite no número de séries temporais exclusivas que podem ser ativamente ingeridas no espaço de trabalho
• % de utilização de séries temporais ativas: a porcentagem da série temporal ativa atual que está sendo utilizada
• Eventos por minuto ingerido: o número de eventos (amostras) por minuto recebidos recentemente
• Limite de ingestão de eventos por minuto: o número máximo de eventos por minuto que podem ser ingeridos antes de serem limitados
• % de utilização de eventos por minuto ingerido: a porcentagem do limite atual da taxa de ingestão de métrica atual sendo utilizada

Para evitar a limitação da ingestão de métricas, você pode monitorar e configurar um alerta sobre os limites de ingestão. Consulte Monitorar limites de ingestão.

Consulte as cotas e limites de serviço para ver as cotas padrão e também para entender o que pode ser aumentado com base no seu uso. Você pode solicitar o aumento da cota para os espaços de trabalho do Azure Monitor usando o menu Support Request do espaço de trabalho do Azure Monitor. Certifique-se de incluir a ID, ID interna e a Localização/Região para o Workspace do Azure Monitor na solicitação de suporte, que você pode encontrar no menu `Propriedades' para o Workspace do Azure Monitor no portal do Azure.

A criação do espaço de trabalho do Azure Monitor falhou devido à avaliação do Azure Policy

Se a criação do Workspace do Azure Monitor falhar com um erro com os dizeres "O recurso 'resource-name-xyz' foi desautorizado pela política", talvez exista uma política do Azure impedindo a criação do recurso. Se houver uma política que imponha uma convenção de nomenclatura para seus recursos do Azure ou grupos de recursos, você precisará criar uma isenção para a convenção de nomenclatura para criação de um Workspace do Azure Monitor.

Quando você cria um espaço de trabalho do Azure Monitor, por padrão, uma regra de coleta de dados e um ponto de extremidade de coleta de dados no formato "azure-monitor-workspace-name" serão criados automaticamente em um grupo de recursos no formulário "MA_azure-monitor-workspace-name_location_managed". Atualmente não há como alterar os nomes desses recursos e você precisará definir uma isenção no Azure Policy para isentar os recursos acima da avaliação de política. Veja Estrutura de isenção da Azure Policy.

Próximas etapas

• Verifique as considerações para coletar métricas em alta escala.