Crie um trabalho de raspagem personalizado do Prometheus a partir do cluster do Kubernetes usando o ConfigMap

Personalize a coleta de métricas Prometheus do seu cluster Kubernetes descreve como usar o ConfigMap para personalizar a coleta (raspagem) de métricas Prometheus de destinos padrão no seu cluster Kubernetes. Este artigo descreve como usar o ConfigMap para criar tarefas de extração personalizadas para maior personalização e alvos adicionais.

ConfigMaps

A tabela a seguir descreve os ConfigMaps usados para criar trabalhos de extração de dados personalizados. Esses ConfigMaps não existem por padrão no cluster quando o Managed Prometheus está habilitado.

Criar arquivo de configuração do Prometheus

Em vez de modificar ama-metrics-prometheus-configdiretamente, é mais fácil criar um arquivo de configuração e, em seguida, convertê-lo em um ConfigMap. Consulte Configurações de scraping abaixo para detalhes sobre as diferentes seções deste arquivo.

Crie um arquivo de configuração de raspagem do Prometheus nomeado prometheus-config usando o seguinte formato. Isso lista as configurações de scraping na seção scrape_configs e, opcionalmente, pode usar a secção global para configurar globalmente os parâmetros scrape_interval, scrape_timeout e external_labels. Consulte Prometheus.io scrape configuration reference para detalhes completos sobre as opções de uma configuração de scrape.

global:
  scrape_interval: <duration>
  scrape_timeout: <duration>
  external_labels:
    <labelname1>: <labelvalue>
    <labelname2>: <labelvalue>
scrape_configs:
  - <job-x>
  - <job-y>

A seguir está um exemplo de arquivo de configuração de scrape do Prometheus:

global:
  scrape_interval: 30s
scrape_configs:
- job_name: my_static_config
  scrape_interval: 60s
  static_configs:
    - targets: ['my-static-service.svc.cluster.local:1234']
- job_name: prometheus_example_app
  scheme: http
  kubernetes_sd_configs:
    - role: service
  relabel_configs:
    - source_labels: [__meta_kubernetes_service_name]
      action: keep
      regex: "prometheus-example-service"

Validar o ficheiro de configuração de scraping

O agente usa uma ferramenta personalizada promconfigvalidator para validar a configuração do Prometheus dada a ele através do ConfigMap. Se a configuração não for válida, a configuração personalizada será rejeitada pelo agente. Depois de criar seu arquivo de configuração Prometheus, você pode usar essa ferramenta para validar sua configuração antes de criar um ConfigMap para o agente.

A promconfigvalidator ferramenta é fornecida dentro do pod complementar de métricas do Azure Monitor. Você pode usar qualquer pod no ama-metrics-node-* do namespace kube-system em seu cluster para baixar a ferramenta para efeito de validação. Use kubectl cp para baixar a ferramenta e sua configuração com o seguinte comando.

for podname in $(kubectl get pods -l rsName=ama-metrics -n=kube-system -o json | jq -r '.items[].metadata.name'); do kubectl cp -n=kube-system "${podname}":/opt/promconfigvalidator ./promconfigvalidator;  kubectl cp -n=kube-system "${podname}":/opt/microsoft/otelcollector/collector-config-template.yml ./collector-config-template.yml; chmod 500 promconfigvalidator; done

Depois de copiar o executável e o yaml, localize o caminho do seu arquivo de configuração Prometheus. Em seguida, substitua o <config path> no comando e execute o validador com o seguinte comando.

./promconfigvalidator/promconfigvalidator --config "<config path>" --otelTemplate "./promconfigvalidator/collector-config-template.yml"

A execução do validador gera o arquivo merged-otel-config.yaml de configuração mesclado se nenhum caminho for fornecido com o parâmetro opcional output . Não use esse arquivo mesclado gerado automaticamente, pois ele é usado apenas para fins de validação e depuração de ferramentas.

Implantar arquivo de configuração como ConfigMap

O seu arquivo de configuração personalizado do Prometheus é consumido como um campo nomeado prometheus-config dentro do ama-metrics-prometheus-config, ama-metrics-prometheus-config-node, ou ama-metrics-prometheus-config-node-windows ConfigMap no namespace kube-system. Crie um ConfigMap a partir do arquivo de configuração de raspagem renomeando seu arquivo de configuração Prometheus para prometheus-config sem extensão de arquivo e executando um ou mais dos seguintes comandos de exemplo, dependendo de qual ConfigMap você deseja criar para sua configuração de trabalho de raspagem personalizada.

Crie o ConfigMap para ser usado pelo replicaset:

kubectl create ConfigMap ama-metrics-prometheus-config --from-file=prometheus-config -n kube-system

Isso cria um ConfigMap nomeado ama-metrics-prometheus-config no kube-system namespace. Para ver se há algum problema com a validação, processamento ou mesclagem de configuração, você pode examinar os ama-metrics pods de réplica

Crie o ConfigMap para ser usado pelo Linux DaemonSet:

kubectl create ConfigMap ama-metrics-prometheus-config-node --from-file=prometheus-config -n kube-system

Isso cria um ConfigMap nomeado ama-metrics-prometheus-config-node no kube-system namespace. Para verificar se há algum problema com a validação, processamento ou fusão da configuração, pode consultar os pods daemonset do Linuxama-metrics-node.

Criar ConfigMap para ser usado pelo Windows DaemonSet

kubectl create ConfigMap ama-metrics-prometheus-config-node-windows --from-file=prometheus-config -n kube-system

Isso cria um ConfigMap nomeado ama-metrics-prometheus-config-node-windows no kube-system namespace. Para ver se há algum problema com a validação, processamento ou mesclagem de configuração, você pode olhar para os ama-metrics-win-node pods deamonset do Windows

Solução de problemas

Se tu criaste com êxito o ConfigMap no namespace kube-system e ainda não vês os alvos personalizados a serem recolhidos, verifica se há erros nos logs do pod de réplica do ConfigMap ama-metrics-prometheus-config ou nos logs do DaemonSet pod do ConfigMap ama-metrics-prometheus-config-node utilizando o comando kubectl logs e certifica-te de que não há erros na seção Start Merging Default and Custom Prometheus Config com o prefixo prometheus-config-merger

Raspar configurações

Atualmente, os métodos suportados de descoberta de alvos para uma configuração de raspagem de dados são ou static_configs ou kubernetes_sd_configs para especificar ou descobrir alvos.

Uma configuração estática tem uma lista de destinos estáticos e quaisquer rótulos extras para adicionar a eles, como a seguir.

scrape_configs:
  - job_name: example
    - targets: [ '10.10.10.1:9090', '10.10.10.2:9090', '10.10.10.3:9090' ... ]
    - labels: [ label1: value1, label1: value2, ... ]

Os destinos descobertos usando kubernetes_sd_configs têm cada um rótulos diferentes __meta_*, dependendo da função especificada. Você pode usar os rótulos na relabel_configs seção para filtrar destinos ou substituir rótulos para os destinos.

Renomear configurações

A relabel_configs seção é aplicada no momento da descoberta do destino e se aplica a cada destino para o trabalho. Os exemplos a seguir mostram maneiras de usar relabel_configs.

Adicionar uma etiqueta Adicione um novo rótulo chamado example_label com o valor example_value a cada métrica do trabalho. Use __address__ como rótulo de origem somente porque esse rótulo sempre existe e adiciona o rótulo para cada destino do trabalho.

relabel_configs:
- source_labels: [__address__]
  target_label: example_label
  replacement: 'example_value'

Usar rótulos de Descoberta de Serviço do Kubernetes

Se um trabalho estiver a usar kubernetes_sd_configs para identificar alvos, cada função tem rótulos associados __meta_* para métricas. Os __* rótulos são descartados depois de descobrir os alvos. Para filtrar usando-os no nível de métricas, primeiro mantenha-os usando relabel_configs atribuindo um nome de rótulo. Em seguida, use metric_relabel_configs para filtrar.

# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
  action: replace
  target_label: kubernetes_namespace

# Keep only metrics with the kubernetes namespace 'default'
metric_relabel_configs:
- source_labels: [kubernetes_namespace]
  action: keep
  regex: 'default'

Rerotulagem de tarefas e instâncias

Você pode alterar os valores dos rótulos job e instance com base no rótulo de origem, assim como qualquer outro rótulo.

# Replace the job name with the pod label 'k8s app'
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_k8s_app]
  target_label: job

# Replace the instance name with the node name. This is helpful to replace a node IP
# and port with a value that is more readable
relabel_configs:
- source_labels: [__meta_kubernetes_node_name]
  target_label: instance

Configurações de re-rotulação de métricas

As configurações de rerótulo de métrica são aplicadas após a raspagem e antes da ingestão. Use a metric_relabel_configs seção para filtrar métricas após a raspagem. Veja os exemplos a seguir.

Eliminar métricas por nome

# Drop the metric named 'example_metric_name'
metric_relabel_configs:
- source_labels: [__name__]
  action: drop
  regex: 'example_metric_name'

Mantenha apenas determinadas métricas com base no nome

# Keep only the metric named 'example_metric_name'
metric_relabel_configs:
- source_labels: [__name__]
  action: keep
  regex: 'example_metric_name'

# Keep only metrics that start with 'example_'
metric_relabel_configs:
- source_labels: [__name__]
  action: keep
  regex: '(example_.*)'

Filtrar métricas por rótulos

# Keep metrics only where example_label = 'example'
metric_relabel_configs:
- source_labels: [example_label]
  action: keep
  regex: 'example'

# Keep metrics only if `example_label` equals `value_1` or `value_2`
metric_relabel_configs:
- source_labels: [example_label]
  action: keep
  regex: '(value_1|value_2)'

# Keep metrics only if `example_label_1 = value_1` and `example_label_2 = value_2`
metric_relabel_configs:
- source_labels: [example_label_1, example_label_2]
  separator: ';'
  action: keep
  regex: 'value_1;value_2'

# Keep metrics only if `example_label` exists as a label
metric_relabel_configs:
- source_labels: [example_label_1]
  action: keep
  regex: '.+'

Renomear métricas Não há suporte para renomeação de métricas.

relabel_configs:
- source_labels: [__address__]
  target_label: example_label
  replacement: 'example_value'

Autenticação básica e tokens de portador

Se você estiver usando nome de usuário, senha ou credenciais como texto sem formatação na configuração de raspagem, nenhuma alteração adicional será necessária. Os valores especificados na configuração serão usados para extração de dados. Se estiveres a usar o username_file ou password_file (ou quaisquer _file definições de configuração) para basic_auth ou bearer_token configurações na tua configuração do Prometheus, segue as etapas abaixo:

1. Crie um segredo no kube-system namespace chamado ama-metrics-mtls-secret.

   O nome da chave password1 pode ser qualquer coisa, desde que corresponda ao nome do arquivo no caminho do password_file arquivo na configuração de raspagem do Prometheus na próxima etapa. O valor da chave precisa ser codificado em base64.

   apiVersion: v1
   kind: Secret
   metadata:
     name: ama-metrics-mtls-secret
     namespace: kube-system
   type: Opaque
   data:
     password1: <base64-encoded-string>
   

   O ama-metrics-mtls-secret segredo é montado nas ama-metrics cápsulas ao longo do caminho /etc/prometheus/certs/ e é disponibilizado para o Prometheus scraper. A chave (password1 no exemplo acima) será o nome do arquivo. O valor é base64 decodificado e adicionado como o conteúdo do arquivo dentro do contêiner.

2. Forneça o caminho do arquivo na configuração de raspagem personalizada no ConfigMap:

   Autenticação básica O username campo deve conter a cadeia de caracteres do nome de usuário real. O password_file campo deve conter o caminho para o arquivo que contém a senha.

   # Sets the `Authorization` header on every scrape request with the
   # configured username and password.
   basic_auth:
     username: <username string>
     password_file: /etc/prometheus/certs/password1
   

   Token Bearer O campo bearer_token_file deve conter o caminho para o ficheiro que contém o token.

   # Sets the `Authorization` header on every scrape request with the bearer token
   # read from the configured file. It is mutually exclusive with `bearer_token`.
   bearer_token_file: /etc/prometheus/certs/password1
   

Consulte a documentação do Prometheus scrape_config para obter mais informações sobre essas configurações.

Raspagem baseada no protocolo TLS

Se quiser extrair métricas do Prometheus de um endpoint https, a configuração do Prometheus, PodMonitor ou ServiceMonitor deve ter o scheme definido como https e configurações adicionais de TLS.

1. Crie um segredo no kube-system namespace chamado ama-metrics-mtls-secret. Cada par chave-valor especificado na seção de dados do objeto secreto será montado como um arquivo separado neste local /etc/prometheus/certs com nomes de arquivo iguais às chaves especificadas na seção de dados. Os valores secretos devem ser codificados em base64.

   Segue-se um exemplo YAML de um segredo:

   apiVersion: v1
   kind: Secret
   metadata:
     name: ama-metrics-mtls-secret
     namespace: kube-system
   type: Opaque
   data:
     <certfile>: base64_cert_content    
     <keyfile>: base64_key_content 
   

   O ama-metrics-mtls-secret segredo é montado nas ama-metrics cápsulas ao longo do caminho /etc/prometheus/certs/ e é disponibilizado para o Prometheus scraper. A chave será o nome do arquivo. O valor é base64 decodificado e adicionado como o conteúdo do arquivo dentro do contêiner.

2. Forneça o caminho do arquivo na configuração do Prometheus, PodMonitor ou ServiceMonitor:

   • Use o exemplo a seguir para fornecer a configuração TLS em um ConfigMap:

   tls_config:
      # CA certificate to validate API server certificate with.
      ca_file: /etc/prometheus/certs/<certfile>
   
      # Certificate and key files for client cert authentication to the server.
      cert_file: /etc/prometheus/certs/<certfile>
      key_file: /etc/prometheus/certs/<keyfile>
   
      # Disable validation of the server certificate.
      insecure_skip_verify: false
   

Autenticação básica e TLS

Se você quiser usar as configurações básicas de autenticação ou token de portador (credenciais baseadas em arquivo) e TLS em seu ConfigMap, certifique-se de que o segredo ama-metrics-mtls-secret inclua todas as chaves na seção de dados com seus valores correspondentes codificados em base64, conforme mostrado no exemplo a seguir:

apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  certfile: base64_cert_content    # used for TLS
  keyfile: base64_key_content      # used for TLS
  password1: base64-encoded-string # used for basic auth
  password2: base64-encoded-string # used for basic auth

Configuração avançada: configurar trabalhos de raspagem personalizados do Prometheus para o DaemonSet

O ama-metrics pod de réplica consome a configuração personalizada do Prometheus e raspa os destinos especificados. Para um cluster com um grande número de nós e pods e um grande volume de métricas para raspar, alguns dos alvos de raspagem personalizados aplicáveis podem ser descarregados do único ama-metrics pod de réplica para o ama-metrics pod DaemonSet.

O ama-metrics-prometheus-config-node ConfigMap é semelhante ao ConfigMap do conjunto de réplicas e pode ser criado para ter configurações de raspagem estáticas em cada nó. A configuração de scrape deve ter como alvo apenas um único nó e não deve usar anotações de service discovery ou de pods. Caso contrário, cada nó tenta coletar todos os alvos e faz muitas chamadas para o servidor de API do Kubernetes.

Os destinos de raspagem personalizados podem seguir o mesmo formato usando static_configs com destinos e usando a $NODE_IP variável de ambiente e especificando a porta a ser raspada. Cada pod do DaemonSet obtém a configuração, recolhe as métricas e as envia a partir desse nó.

A configuração a seguir node-exporter é um dos destinos padrão para os pods DaemonSet. Ele usa a $NODE_IP variável de ambiente, que já está definida para cada ama-metrics container de add-on para direcionar uma porta específica no nó alvo.

- job_name: nodesample
  scrape_interval: 30s
  scheme: http
  metrics_path: /metrics
  relabel_configs:
  - source_labels: [__metrics_path__]
    regex: (.*)
    target_label: metrics_path
  - source_labels: [__address__]
    replacement: '$NODE_NAME'
    target_label: instance
  static_configs:
  - targets: ['$NODE_IP:9100']

Extrair definições de configuração

As seções a seguir descrevem as configurações suportadas no arquivo de configuração Prometheus usado no ConfigMap. Consulte a referência de configuração do Prometheus para obter mais detalhes sobre essas configurações.

Configurações globais

O formato de configuração para definições globais é idêntico ao suportado pela configuração do prometheus OSS

global:
  scrape_interval: <duration>
  scrape_timeout: <duration>
  external_labels:
    <labelname1>: <labelvalue>
    <labelname2>: <labelvalue>
scrape_configs:
  - <job-x>
  - <job-y>

As configurações fornecidas na secção global aplicam-se a todas as tarefas de scraping (tanto no Configmap quanto nos recursos personalizados), mas são substituídas se forem especificadas nas tarefas individuais.

Próximos passos

• Saiba mais sobre como coletar métricas do Prometheus.