Share via

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

  • Artigo

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 script do PowerShell

Se encontrar um erro ao tentar ativar a monitorização do seu cluster AKS, siga as instruções mencionadas aqui para executar o script de resolução de problemas. Este script foi projetado para fazer um diagnóstico básico de quaisquer problemas de configuração em seu cluster e você pode verificar os arquivos gerados enquanto cria uma solicitação de suporte para uma resolução mais rápida para seu caso de suporte.

Limitação de Métricas

No portal do Azure, navegue até seu Espaço de Trabalho do Azure Monitor. Vá até Metrics e verifique se as métricas Active Time Series % Utilization e Events Per Minute Ingested % Utilization estão abaixo de 100%.

Captura de tela mostrando como navegar até as métricas de limitação.

Se qualquer um deles for superior a 100%, a ingestão neste espaço de trabalho está sendo limitada. No mesmo espaço de trabalho, navegue até New Support Request para criar uma solicitação para aumentar os limites. Selecione o tipo de problema como Service and subscription limits (quotas) e o tipo de cota como Managed Prometheus.

Lacunas intermitentes na coleta de dados de métricas

Durante as atualizações do nó, você poderá ver uma lacuna de 1 a 2 minutos nos dados das métricas coletadas do nosso coletor em 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
  • Deve haver um pod ama-metrics-xxxxxxxxxx-xxxxx de réplica, um ama-metrics-operator-targets-*, um pod ama-metrics-ksm-* e um pod ama-metrics-node-*, 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:

Captura de tela mostrando o status do pod.

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.

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: Captura de tela mostrando o log do token do complemento.

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. Captura de tela mostrando os trabalhos de 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. Captura de tela mostrando a descoberta do serviç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 Captura de tela mostrando destinos.

Recursos personalizados

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

Configuração

Captura de tela mostrando trabalhos de configuração para o monitor de pod.

Descoberta de Serviços

Captura de tela mostrando o SD para o monitor de pod.

Destinos

Captura de tela mostrando destinos para o monitor de pod.

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

Aviso

Esse modo pode afetar o desempenho e só deve ser habilitado por um curto período de tempo para fins 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 baseada em agente tem as limitações indicadas na tabela a seguir:

Propriedade Limite
Comprimento do nome do rótulo Menor que ou igual a 511 caracteres. Quando esse limite for ultrapassado em qualquer série temporal em um trabalho, todo o trabalho de extração falhará e as métricas serão removidas desse trabalho antes da ingestão. Você pode ver up=0 para esse trabalho e também o destino da experiência do usuário mostra o motivo para up=0.
Comprimento do valor do rótulo Menor que ou igual a 1023 caracteres. Quando esse limite é excedido em qualquer série temporal em uma tarefa, toda a extração falhará e as métricas serão removidas desse trabalho antes da ingestão. Você pode ver up=0 para esse trabalho e também o destino da experiência do usuário mostra o motivo para up=0.
Número de rótulos por série temporal Menor que ou igual a 63. Quando esse limite for ultrapassado em qualquer série temporal em um trabalho, todo o trabalho de extração falhará e as métricas serão removidas desse trabalho antes da ingestão. Você pode ver up=0 para esse trabalho e também o destino da experiência do usuário mostra o motivo para up=0.
Comprimento do nome da métrica Menor que ou igual a 511 caracteres. Quando esse limite é excedido em qualquer série temporal em um trabalho, somente essa série específica será removida. MetricextensionConsoleDebugLog tem os rastreamentos da métrica removida.
Nomes de rótulos com invólucros diferentes Dois rótulos dentro da mesma amostra de métrica, com capitalizações diferentes, são tratados como tendo rótulos duplicados e são descartados quando ingeridos. Por exemplo, a série temporal my_metric{ExampleLabel="label_value_0", examplelabel="label_value_1} foi removida devido a rótulos duplicados, pois ExampleLabel e examplelabel são vistos como o mesmo nome de rótulo.

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

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, a ID interna e a Localização/Região do espaço de trabalho do Azure Monitor na solicitação de suporte, que você pode encontrar no menu “Propriedades” do espaço de trabalho do Azure Monitor no portal do Azure.

Próximas etapas