Personalizar a captura de métricas do Prometheus no serviço gerenciado do Azure Monitor para o Prometheus

  • Artigo

Este artigo fornece instruções sobre como personalizar a extração de métricas para um cluster do Kubernetes com o complemento de métricas no Azure Monitor.

Configmaps

Quatro configmaps diferentes podem ser configurados para fornecer configuração da extração e outras configurações para o complemento de métricas. Todos os mapas de configuração devem ser aplicados ao namespace kube-system de qualquer cluster.

Observação

Nenhum dos quatro configmaps existe por padrão no cluster quando o Prometheus gerenciado está habilitado. Dependendo do que precisa ser personalizado, você precisa implantar qualquer um ou todos esses quatro configmaps com o mesmo nome especificado, no namespace kube-system. Os pods AMA-Metrics pegarão esses configmaps depois de implantá-los no namespace kube-system e serão reiniciados em 2 a 3 minutos para aplicar as definições de configuração especificadas no(s) configmap(s).

  1. ama-metrics-settings-configmap Esse mapa de configuração tem abaixo configurações simples que podem ser definidas. Você pode pegar o configmap do repositório do GitHub acima, alterar as configurações necessárias e aplicar/implantar o configmap no namespace kube-system do cluster
    • alias do cluster (para alterar o valor do rótulo cluster em cada série temporal/métrica que é ingerida de um cluster)
    • ativar/desativar destinos de extração padrão: ATIVA/DESATIVA a extração padrão com base em destinos. A configuração de extração para esses alvos padrão já está predefinida/integrada
    • habilitar extração baseada em anotações do pod por namespace
    • listas de manutenção de métricas: esta configuração é usada para controlar quais métricas estão listadas para serem permitidas em cada destino padrão e para alterar o comportamento padrão
    • intervalos de extração para destinos padrão/predefinidos. 30 secs é a frequência de extração padrão e pode ser alterada pelo destino padrão usando esse configmap
    • modo de depuração: ativar isso ajuda a depurar problemas de métrica/ingestão ausentes; veja mais na solução de problemas
  2. ama-metrics-prometheus-config Esse mapa de configuração pode ser usado para fornecer a configuração de extração do Prometheus para complemento de réplica. O complemento executa uma réplica singleton, sendo que qualquer serviço em nível de cluster pode ser descoberto e copiado fornecendo trabalhos de extração neste configmap. Você pode pegar o exemplo de configmap do repositório GitHub acima, adicionar os trabalhos de extração necessários e aplicar/implantar o configmap no namespace kube-system do seu cluster. Embora haja suporte para isso, observe que a maneira recomendada de raspar destinos personalizados é usar recursos personalizados
  3. ama-metrics-prometheus-config-node (Avançado) Esse mapa de configuração pode ser usado para fornecer a configuração de extrair do Prometheus para o DaemonSet do addon que é executado em cada nó do Linux no cluster, e quaisquer destinos de nível de nó em cada nó podem ser raspados fornecendo trabalhos de raspagem neste mapa de configurações. Ao usar esse configmap, você poderá usar a variável $NODE_IP na sua configuração de extração, que é substituída pelo endereço IP do nó correspondente no pod do DaemonSet em execução em cada nó. Dessa forma, você tem acesso para extrair qualquer coisa que seja executada nesse nó a partir do complemento de métricas DaemonSet. Tenha cuidado ao usar as descobertas na configuração de extração nesse mapa de configuração em nível de nó, pois cada nó do cluster configurará e descobrirá os destinos e coletará métricas redundantes. Você pode pegar o exemplo de configmap do repositório GitHub acima, adicionar os trabalhos de extração necessários e aplicar/implantar o configmap no namespace kube-system do seu cluster
  4. ama-metrics-prometheus-config-node-windows (Advanced) Este mapa de configuração pode ser usado para fornecer a configuração de extrair do Prometheus para o daemonSet de complemento que é executado em cada nó do Windows no cluster, e os destinos de nível de nó em cada nó podem ser raspados fornecendo trabalhos de raspagem neste mapa de configurações. Ao usar esse configmap, você poderá usar a variável $NODE_IP na sua configuração de extração, que será substituída pelo endereço IP do nó correspondente no pod do DaemonSet em execução em cada nó. Dessa forma, você tem acesso para extrair qualquer coisa que seja executada nesse nó a partir do complemento de métricas DaemonSet. Tenha cuidado ao usar as descobertas na configuração de extração nesse mapa de configuração em nível de nó, pois cada nó do cluster configurará e descobrirá os destinos e coletará métricas redundantes. Você pode pegar o exemplo de configmap do repositório GitHub acima, adicionar os trabalhos de extração necessários e aplicar/implantar o configmap no namespace kube-system do seu cluster

Definições de Recurso Personalizado

O complemento de métricas do Azure Monitor dá suporte à eliminação de métricas do Prometheus usando o Prometheus – Monitores de Pod e Monitores de Serviço, semelhante ao operador Prometheus do OSS. Habilitar o complemento implantará as definições de recursos personalizados do Pod e do Service Monitor para permitir que você crie seus próprios recursos personalizados. Siga as instruções para criar e aplicar recursos personalizados em seu cluster.

Configurações do complemento de métricas do configmap

O ama-metrics-settings-configmap pode ser baixado, editado e aplicado ao cluster para personalizar os recursos prontos para uso do complemento de métricas.

Habilitar ou desabilitar os destinos padrão

A tabela a seguir tem uma lista de todos os destinos padrão que o complemento de métricas do Azure Monitor pode extrair por padrão e se ele estiver inicialmente habilitado. Os destinos padrão são extraídos a cada 30 segundos. Uma réplica é implantada para extrair destinos em todo o cluster, como o kube-state-metrics. Um DaemonSet também é implantado para extrair destinos em todo o nó, como o kubelet.

Chave Tipo habilitado Pod Descrição
kubelet bool true DaemonSet do Linux Extrair o kubelet em cada nó no cluster K8s sem nenhuma configuração extra de extração.
cadvisor bool true DaemonSet do Linux Extrair o cadvisor em cada nó no cluster K8s sem nenhuma configuração extra de extração.
Somente Linux.
kubestate bool true Réplica do Linux Extrair o kube-state-metrics no cluster K8s (instalado como parte do complemento) sem qualquer configuração extra de extração.
nodeexporter bool true DaemonSet do Linux Extraia as métricas de nó sem configuração adicional de extração.
Somente Linux.
coredns bool false Réplica do Linux Serviço de coredns de extração no cluster K8s sem nenhuma configuração extra de extração.
kubeproxy bool false DaemonSet do Linux Extrair o kube-proxy em cada nó do Linux descoberto no cluster K8s sem nenhuma configuração extra de extração.
Somente Linux.
apiserver bool false Réplica do Linux Extrair o servidor de API do Kubernetes no cluster do K8s sem nenhuma configuração extra de extração.
windowsexporter bool false DaemonSet do Windows Extrair o windows-exporter em todos os nós no cluster K8s sem nenhuma configuração extra de extração.
Somente Windows.
windowskubeproxy bool false DaemonSet do Windows Extrair o windows-kube-proxy em todos os nós no cluster K8s sem nenhuma configuração extra de extração.
Somente Windows.
prometheuscollectorhealth bool false Réplica do Linux Extrair informações sobre o contêiner do coletor do prometheus, como a quantidade e o tamanho das séries temporais extraídas.

Se você quiser ativar a extração dos destinos padrão que não estão habilitados por padrão, edite o configmapama-metrics-settings-configmap para atualizar os destinos listados em default-scrape-settings-enabled para true. Aplicar o configmap ao cluster.

Habilitar a extração baseada em anotação de pod

Anotações podem ser adicionadas aos pods para extrair pods de aplicativo sem a necessidade de criar uma configuração personalizada do Prometheus. A anotação prometheus.io/scrape: "true" é necessária para extrair o pod. As anotações prometheus.io/path e prometheus.io/port indicam o caminho e a porta em que as métricas estão hospedadas no pod. As anotações de um pod que está hospedando métricas em <pod IP>:8080/metrics seriam:

metadata:   
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/path: '/metrics'
    prometheus.io/port: '8080'

A extração desses pods com anotações específicas é desabilitada por padrão. Para habilitar, no ama-metrics-settings-configmap, adicione o regex para os namespaces dos pods com anotações que você deseja extrair como o valor do campo podannotationnamespaceregex.

Por exemplo, a configuração a seguir extrai pods com anotações somente nos namespaces kube-system e my-namespace:

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = "kube-system|my-namespace"

Para habilitar a extração de pods com anotações em todos os namespaces, use:

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = ".*"

Aviso

Raspar as anotações de pod de muitos namespaces pode gerar um volume muito grande de métricas, dependendo do número de pods que tenham anotações.

Personalizar a métricas coletadas pelos destinos padrão

Por padrão, para todos os destinos padrão, apenas as métricas mínimas usadas nas regras de gravação padrão, alertas e dashboards do Grafana são ingeridos conforme descrito em minimal-ingestion-profile. Para coletar todas as métricas dos destinos padrão, atualize o keep-lists no configmap de configurações em default-targets-metrics-keep-list e defina minimalingestionprofile como false.

Para permitir a lista de mais métricas além das métricas padrão listadas como permitidas, para qualquer destino padrão, edite as configurações em default-targets-metrics-keep-list para o trabalho correspondente que você deseja alterar.

Por exemplo, kubelet é a configuração de filtragem de métrica para o kubelet de destino padrão. Use o seguinte script para filtrar nas métricas coletadas para os destinos padrão usando a filtragem baseada em regex.

kubelet = "metricX|metricY"
apiserver = "mymetric.*"

Observação

Se você usar aspas ou barras invertidas no regex, precisará escapar delas usando uma barra invertida, como nos exemplos "test\'smetric\"s\"" e testbackslash\\*.

Para personalizar ainda mais os trabalhos padrão para alterar propriedades como frequência de coleta ou rótulos, desabilite o destino padrão correspondente definindo o valor do configmap do destino como false. Em seguida, aplique o trabalho utilizando um configmap personalizado. Para obter detalhes sobre a configuração personalizada, consulte Personalizar a extração de métricas do Prometheus no Azure Monitor.

Alias de cluster

O rótulo do cluster anexado a cada série temporal extraída usa a última parte da ID de recurso do Azure Resource Manager de todo o cluster AKS. Por exemplo, se a ID do recurso for /subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclustername, o rótulo do cluster será myclustername.

Para substituir o rótulo de cluster na série temporal extraída, atualize a configuração cluster_alias para qualquer cadeia de caracteres em prometheus-collector-settings no configmapama-metrics-settings-configmap. Você pode criar esse configmap se ele não existir no cluster ou pode editar o existente se ele já existir no seu cluster.

O novo rótulo também aparece no menu suspenso de parâmetros do cluster nos painéis do Grafana, em vez do padrão.

Observação

Somente caracteres alfanuméricos são permitidos. Todos os outros caracteres são substituídos por _. Essa alteração destina-se a garantir que os diferentes componentes que consomem esse rótulo respeitam a convenção alfanumérica básica.

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.

Para exibir todas as métricas que estão sendo extraídas para fins de depuração, o agente de complemento de métricas pode ser configurado para ser executado no modo de depuração atualizando a configuração enabled para true na configuração debug-mode no configmapama-metrics-settings-configmap. É possível criar esse configmap ou editar um existente. Para obter mais informações, confira a seção Modo de depuração na Solução de problemas da coleção de métricas do Prometheus.

Configurações de intervalo de extração

Para atualizar as configurações do intervalo de extração para qualquer destino, você pode atualizar a duração na configuração default-targets-scrape-interval-settings desse destino no configmapama-metrics-settings-configmap. Você precisa definir os intervalos de extração no formato correto especificado neste site. Caso contrário, o valor padrão de 30 segundos será aplicado aos destinos correspondentes. Por exemplo, se você quiser atualizar o intervalo de extração do trabalho kubelet para 60s, você poderá atualizar a seção a seguir no YAML:

default-targets-scrape-interval-settings: |-
    kubelet = "60s"
    coredns = "30s"
    cadvisor = "30s"
    kubeproxy = "30s"
    apiserver = "30s"
    kubestate = "30s"
    nodeexporter = "30s"
    windowsexporter = "30s"
    windowskubeproxy = "30s"
    kappiebasic = "30s"
    prometheuscollectorhealth = "30s"
    podannotations = "30s"

e aplique o YAML usando o comando a seguir: kubectl apply -f .\ama-metrics-settings-configmap.yaml

Configurar trabalhos personalizados de extração do Prometheus

Você pode raspar as métricas do Prometheus usando o Prometheus – Monitores de Pod e Monitores de Serviço(Recomendado), semelhante ao operador Prometheus do OSS. Siga as instruções para criar e aplicar recursos personalizados em seu cluster.

Além disso, você pode seguir as instruções para criar, validar e aplicar o configmap ao seu cluster. O formato da configuração é semelhante ao arquivo de configuração do Prometheus.

Dicas e exemplos de configuração do Prometheus

Aprenda algumas dicas com os exemplos desta seção.

Use os modelos do Pod e do Monitor de Serviço e siga a especificação da API para criar seus recursos personalizados(PodMonitor e Service Monitor). Observe que a única alteração necessária para as CRs de OSS existentes para serem captadas pelo Prometheus Gerenciado é o grupo de API – azmonitoring.coreos.com/v1. Veja aqui para saber mais

Observação

Quando a configuração de extração personalizada não for aplicada devido a erros de validação, a configuração de extração padrão continuará sendo utilizada.

Se você quiser usar as configurações globais que se aplicam a todos os trabalhos de raspagem e só tiver Recursos Personalizados você ainda precisará criar um configmap apenas com as configurações globais(As configurações para cada um deles nos recursos personalizados substituirão as da seção global)

Configurações de extração

Atualmente, os métodos compatíveis de descoberta de destino para recursos personalizados são pod e monitor de serviço

Monitores de Pod e Serviço

Os destinos descobertos usando monitores de pod e serviço têm rótulos de __meta_* diferentes, dependendo do monitor usado. Você pode usar os rótulos na seção relabelings para filtrar destinos ou substituir os rótulos dos destinos.

Consulte os exemplos do Pod e do Monitor de Serviço de monitores de pod e serviço.

Relançamentos

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

Adicionar um rótulo

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

relabelings:
- sourceLabels: [__address__]
  targetLabel: example_label
  replacement: 'example_value'

Usar rótulos do Pod ou do Monitor de Serviço

Os destinos descobertos usando monitores de pod e serviço têm rótulos de __meta_* diferentes, dependendo do monitor usado. Os rótulos __* são removidos após a descoberta dos destinos. Para filtrar usando-os no nível das métricas, primeiro mantenha-os usando relabelings atribuindo um nome de rótulo. Em seguida, utilize metricRelabelings para filtrar.

# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabelings:
- sourceLabels: [__meta_kubernetes_namespace]
  action: replace
  targetLabel: kubernetes_namespace

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

Rotulando novamente o trabalho e a instância

Você pode alterar os valores do rótulo 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'
relabelings:
- sourceLabels: [__meta_kubernetes_pod_label_k8s_app]
  targetLabel: 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
relabelings:
- sourceLabels: [__meta_kubernetes_node_name]]
  targetLabel: instance

Relançamentos de métrica

Os rótulos de métrica são aplicados após a extração e antes da ingestão. Use a seção metricRelabelings para filtrar as métricas após a extração. Os exemplos a seguir mostram como fazer isso.

Remover métricas por nome

# Drop the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
  action: drop
  regex: 'example_metric_name'

Manter apenas determinadas métricas por nome

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

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

Renomear as métricas

Não há suporte para renomeação da métrica.

Filtrar as métricas por rótulos

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

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

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

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

Extração baseada no TLS

Se você tiver uma instância do Prometheus atendida com o TLS e quiser extrair métricas dela, defina o esquema como https e as configurações do TLS no mapa de configurações ou no respectivo CRD. Use a propriedade de configuração tls_config dentro de um trabalho de extração personalizado para definir as configurações do TLS usando um CRD ou um mapa de configurações. Você precisa fornecer um Certificado de Autoridade de Certificação que será usado para validar o certificado do servidor de API. O Certificado de Autoridade de Certificação é usado para verificar a autenticidade do certificado do servidor quando o Prometheus se conecta ao destino via TLS. Isso ajuda a garantir que o certificado do servidor seja assinado por uma autoridade confiável.

O segredo deve ser criado no namespace kube-system e, em seguida, o mapa de configurações/CRD deve ser criado nele também. A ordem da criação do segredo é importante. Quando não houver nenhum segredo, mas um CRD/mapa de configurações válido, você encontrará erros no log do coletor ->no file found for cert....

Veja abaixo os detalhes sobre como fornecer as definições de configuração do TLS por meio de um mapa de configurações ou um CRD.

  • Para fornecer a configuração do TLS em um configmap, crie o certificado autoassinado e a chave dentro do aplicativo habilitado para mtls. Um exemplo de tlsConfig dentro do mapa de configurações deve ter esta aparência:
tls_config:
    ca_file: /etc/prometheus/certs/client-cert.pem
    cert_file: /etc/prometheus/certs/client-cert.pem
    key_file: /etc/prometheus/certs/client-key.pem
    insecure_skip_verify: false
  • Para fornecer a configuração do TLS em um CRD, crie o certificado autoassinado e a chave dentro do aplicativo habilitado para mtls. Um exemplo de tlsConfig dentro de um Podmonitor deve ter esta aparência:
tlsConfig:
    ca:
        secret:
        key: "client-cert.pem" # since it is self-signed
        name: "ama-metrics-mtls-secret"
    cert:
        secret:
        key: "client-cert.pem"
        name: "ama-metrics-mtls-secret"
    keySecret:
        key: "client-key.pem"
        name: "ama-metrics-mtls-secret"
    insecureSkipVerify: false

Observação

Verifique se o nome do arquivo de certificado e o nome da chave dentro do aplicativo MTLS estão no formato a seguir no caso de uma extração baseada em CRD. Por exemplo: secret_kube-system_ama-metrics-mtls-secret_cert-name.pem e secret_kube-system_ama-metrics-mtls-secret_key-name.pem. O CRD precisa ser criado no namespace kube-system. O nome do segredo deve ser exatamente ama-metrics-mtls-secret no namespace kube-system. Um exemplo de comando para criar um segredo: kubectl create secret generic ama-metrics-mtls-secret --from-file=secret_kube-system_ama-metrics-mtls-secret_client-cert.pem=secret_kube-system_ama-metrics-mtls-secret_client-cert.pem --from-file=secret_kube-system_ama-metrics-mtls-secret_client-key.pem=secret_kube-system_ama-metrics-mtls-secret_client-key.pem -n kube-system

Para ler mais sobre a autenticação TLS, a documentação a seguir pode ser útil.

Autenticação Básica

Se você estiver usando a configuração basic_auth na sua configuração do Prometheus, siga as etapas -

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

O valor de password1 é base64encoded A chave senha1 pode ser qualquer coisa, mas só precisa corresponder ao caminho do arquivo password_file de scrapeconfig.

apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  password1: <base64-encoded-string>
  1. No configmap para a configuração de raspagem personalizada, use a seguinte configuração:
basic_auth:
  username: admin
  password_file: /etc/prometheus/certs/password1

Observação

Verifique se o nome é ama-metrics-mtls-secret e está no namespace do kube-system.

O caminho /etc/prometheus/certs/ é obrigatório, mas password1 pode ser qualquer cadeia de caracteres e precisa corresponder à chave dos dados no segredo criado acima. Isso ocorre porque o segredo ama-metrics-mtls-secret é montado no caminho /etc/prometheus/certs/ dentro do contêiner.

O valor codificado em base64 é decodificado automaticamente pelos pods do agente quando o segredo é montado como arquivo.

Qualquer outra configuração para autorização considerada como um segredo na configuração prometheus precisa usar a alternativa de configuração de arquivo, conforme descrito acima.

Próximas etapas

Configurar alertas em métricas do Prometheus
Consulta de métricas do Prometheus
Saiba mais sobre a coleta de métricas do Prometheus