Partilhar via

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

  • Artigo

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

Mapas de configuração

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

Nota

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

  1. ama-metrics-settings-configmap Este mapa de configuração tem abaixo configurações simples que podem ser configuradas. Você pode pegar o configmap do repositório do hub git acima, alterar as configurações necessárias e aplicar/implantar o configmap ao kube-system namespace para seu cluster
    • alias de cluster (para alterar o valor de cluster label em cada série/métrica temporal ingerida de um cluster)
    • ativar/desativar alvos de raspagem padrão - Ative / DESATIVE a raspagem padrão com base nos destinos. A configuração de raspagem para esses destinos padrão já está pré-definida/integrada
    • habilitar a raspagem baseada em anotação de pod por namespace
    • Listas de manutenção de métricas - essa configuração é usada para controlar quais métricas são listadas para serem permitidas a partir de cada destino padrão e para alterar o comportamento padrão
    • Intervalos de raspagem para Default/Pre-DefineTargets. 30 secs é a frequência de raspagem padrão e pode ser alterada por destino padrão usando este configmap
    • modo de depuração - ativar esta opção ajuda a depurar problemas de métrica/ingestão ausentes - veja mais sobre solução de problemas
  2. ama-metrics-prometheus-config Este mapa de configuração pode ser usado para fornecer Prometheus scrape config para réplica de addon. O Addon executa uma réplica singleton e qualquer serviço de nível de cluster pode ser descoberto e raspado fornecendo trabalhos de raspagem neste configmap. Você pode pegar o exemplo configmap do repositório do hub git acima, adicionar trabalhos de raspagem que você precisaria e aplicar/implantar o mapa de configuração ao kube-system namespace para seu cluster. Embora isso seja suportado, observe que a maneira recomendada de raspar destinos personalizados é usando recursos personalizados
  3. ama-metrics-prometheus-config-node (Avançado) Este mapa de configuração pode ser usado para fornecer Prometheus scrape config para addon DaemonSet que é executado em cada nó Linux no cluster, e quaisquer alvos de nível de nó em cada nó podem ser raspados fornecendo trabalhos de raspagem neste configmap. Quando você usa este configmap, você pode usar $NODE_IP a variável em sua configuração de scrape, que é substituída pelo endereço IP do nó correspondente no pod DaemonSet em execução em cada nó. Dessa forma, você tem acesso para raspar qualquer coisa que seja executada nesse nó a partir do addon de métricas DaemonSet. Tenha cuidado ao usar descobertas na configuração de raspagem neste mapa de configuração de nível de nó, pois cada nó no cluster configurará & descobrirá o(s) destino(s) e coletará métricas redundantes. Você pode pegar o exemplo configmap do repositório git hub acima, adicionar trabalhos de raspagem que você precisaria e aplicar/implantar o mapa de configuração no namespace para kube-system seu cluster
  4. ama-metrics-prometheus-config-node-windows (Avançado) Este mapa de configuração pode ser usado para fornecer Prometheus scrape config para addon DaemonSet que é executado em cada nó do Windows no cluster, e os alvos de nível de nó em cada nó podem ser raspados fornecendo trabalhos de raspagem neste configmap. Quando você usa este configmap, você pode usar $NODE_IP a variável em sua configuração de scrape, que será substituída pelo endereço ip do nó correspondente no pod DaemonSet em execução em cada nó. Dessa forma, você tem acesso para raspar qualquer coisa que seja executada nesse nó a partir do addon de métricas DaemonSet. Tenha cuidado ao usar descobertas na configuração de raspagem neste mapa de configuração de nível de nó, pois cada nó no cluster configurará & descobrirá o(s) destino(s) e coletará métricas redundantes. Você pode pegar o exemplo configmap do repositório git hub acima, adicionar trabalhos de raspagem que você precisaria e aplicar/implantar o mapa de configuração no namespace para kube-system seu cluster

Definições de recursos personalizados

O complemento de métricas do Azure Monitor dá suporte à raspagem de métricas do Prometheus usando o Prometheus - Pod Monitors e Service Monitors, semelhante ao operador OSS Prometheus. 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 no cluster.

Configurações do complemento de métricas 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 e desabilitar 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 raspar por padrão e se ele está habilitado inicialmente. Os alvos padrão são raspados a cada 30 segundos. Uma réplica é implantada para raspar destinos em todo o cluster, como kube-state-metrics. Um DaemonSet também é implantado para raspar alvos em todo o nó, como kubelet.

Chave Type Ativado(a) Pod Description
kubelet booleano true Linux DaemonSet Raspe kubelet em cada nó no cluster K8s sem qualquer configuração de raspagem extra.
cConselheiro booleano true Linux DaemonSet Raspe o cadvisor em cada nó do cluster K8s sem nenhuma configuração de raspagem extra.
Apenas Linux.
Kubestate booleano true Réplica do Linux Raspe kube-state-metrics no cluster K8s (instalado como parte do complemento) sem qualquer configuração de raspagem extra.
nodeexporter booleano true Linux DaemonSet Raspe métricas de nó sem qualquer configuração de raspagem extra.
Apenas Linux.
Coredns booleano false Réplica do Linux Serviço de raspagem de coredns no cluster K8s sem qualquer configuração de raspagem extra.
kubeproxy booleano false Linux DaemonSet Raspe kube-proxy em cada nó Linux descoberto no cluster K8s sem qualquer configuração de scrape extra.
Apenas Linux.
apiserver booleano false Réplica do Linux Raspe o servidor de API do Kubernetes no cluster K8s sem nenhuma configuração de raspagem extra.
windowsexportador booleano false Windows DaemonSet Raspe o exportador de janelas em cada nó do cluster K8s sem qualquer configuração de raspagem extra.
Apenas Windows.
windowskubeproxy booleano false Windows DaemonSet Raspe windows-kube-proxy em cada nó no cluster K8s sem qualquer configuração de raspagem extra.
Apenas Windows.
PrometheusCollectorHealth booleano false Réplica do Linux Raspe informações sobre o recipiente coletor de prometheus, como a quantidade e o tamanho da série temporal raspada.

Se você quiser ativar a raspagem dos destinos padrão que não estão habilitados por padrão, edite o configmap ama-metrics-settings-configmap para atualizar os destinos listados em .truedefault-scrape-settings-enabled Aplique o configmap ao cluster.

Habilitar a raspagem baseada em anotação de pod

Para raspar pods de aplicativos sem a necessidade de criar uma configuração personalizada do Prometheus, anotações podem ser adicionadas aos pods. A anotação prometheus.io/scrape: "true" é necessária para que o pod seja raspado. 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 para um pod que está hospedando métricas seriam <pod IP>:8080/metrics :

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

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

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

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

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 têm anotações.

Personalizar métricas coletadas por destinos padrão

Por padrão, para todos os destinos padrão, apenas métricas mínimas usadas nas regras de gravação padrão, alertas e painéis do Grafana são ingeridas conforme descrito em perfil de ingestão mínima. Para coletar todas as métricas dos destinos padrão, atualize as listas de manutenção 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 para serem permitidas, para quaisquer destinos 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 métrica para o kubelet de destino padrão. Use o script a seguir para filtrar as métricas coletadas para os destinos padrão usando a filtragem baseada em regex.

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

Nota

Se você usar aspas ou barras invertidas no regex, você precisa escapar delas usando uma barra invertida como os 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, desative o destino padrão correspondente definindo o valor configmap para o destino como false. Em seguida, aplique o trabalho usando um configmap personalizado. Para obter detalhes sobre a configuração personalizada, consulte Personalizar a raspagem de métricas do Prometheus no Azure Monitor.

Alias de cluster

O rótulo de cluster anexado a cada série temporal raspada usa a última parte da ID de recurso do Azure Resource Manager do cluster AKS completo. Por exemplo, se o ID do recurso for /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclustername, o rótulo do cluster será myclustername.

Para substituir o rótulo do cluster na série temporal raspada, atualize a configuração cluster_alias para qualquer cadeia de caracteres no prometheus-collector-settings configmap ama-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 cluster.

O novo rótulo também aparece na lista suspensa de parâmetros de cluster nos painéis do Grafana em vez do padrão.

Nota

Só são permitidos caracteres alfanuméricos. Quaisquer outros caracteres são substituídos por _. Esta alteração destina-se a garantir que os diferentes componentes que consomem este rótulo aderem à convenção alfanumérica básica. Se você estiver habilitando regras de gravação e alerta, certifique-se de usar o nome do alias do cluster no parâmetro de nome do cluster do modelo de integração de regras para que as regras funcionem.

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 cada métrica que está sendo raspada 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 sob a debug-mode configuração no configmap ama-metrics-settings-configmap.true Você pode criar este configmap ou editar um existente. Para obter mais informações, consulte a seção Modo de depuração em Solucionar problemas da coleção de métricas do Prometheus.

Configurações de intervalo de raspagem

Para atualizar as configurações de intervalo de raspagem para qualquer destino, você pode atualizar a duração na configuração default-targets-scrape-interval-settings para esse destino no configmap ama-metrics-settings-configmap. Você tem que definir os intervalos de raspagem 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 raspagem para o kubelet trabalho 60s , então você pode atualizar a seguinte seção 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 seguinte comando: kubectl apply -f .\ama-metrics-settings-configmap.yaml

Configurar trabalhos de raspagem personalizados do Prometheus

Você pode raspar métricas Prometheus usando Prometheus - Pod Monitors e Service Monitors(Recomendado), semelhante ao operador OSS Prometheus. Siga as instruções para criar e aplicar recursos personalizados no cluster.

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

Dicas e exemplos de configuração do Prometheus

Aprenda algumas dicas de exemplos nesta seção.

Use os modelos Pod e Service Monitor 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 OSS existentes para serem coletadas pelo Managed Prometheus é o grupo de API - azmonitoring.coreos.com/v1. Veja aqui para saber mais

Nota

Quando a configuração de raspagem personalizada não é aplicada devido a erros de validação, a configuração de raspagem padrão continua a ser usada.

Se você quiser usar configurações globais que se aplicam a todos os trabalhos de raspagem e ter apenas Recursos Personalizados , 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)

Raspar configurações

Atualmente, os métodos suportados de descoberta de destino para recursos personalizados são pod e service monitor

Monitores de pod e serviço

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

Veja os exemplos de Pod e Service Monitor de pod e monitores de serviço.

Rerotulagens

A relabelings 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 relabelingso .

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.

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

Usar rótulos do Pod ou do Service Monitor

Os alvos descobertos usando pod e monitores de serviço têm rótulos diferentes __meta_* , dependendo do monitor usado. 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 relabelings atribuindo um nome de rótulo. Em seguida, use 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'

Rerotulagem de tarefas e instâncias

Você pode alterar os job valores e instance label 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

Nota

Se você tiver configurações de rerotulagem, certifique-se de que a rerotulagem não filtre os destinos e que os rótulos configurados corretamente correspondam aos destinos.

Reetiquetas métricas

As remarcações métricas são aplicadas após a raspagem e antes da ingestão. Use a seção para filtrar métricas após a metricRelabelings raspagem. Os exemplos a seguir mostram como fazer isso.

Solte métricas por nome

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

Mantenha 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 métricas

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

Filtrar 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: '.+'

Autenticação básica e tokens ao portador

Para usar as basic_auth configurações ou bearer_token em sua configuração prometheus, siga 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 no caminho /etc/prometheus/certs/ e é disponibilizado para o raspador Prometheus. 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. Em seguida, na configuração de raspagem personalizada no configmap, forneça o caminho do arquivo:

    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 de Portador

    O bearer_token_file campo deve conter o caminho para o arquivo 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

Mais informações sobre essas configurações podem ser encontradas na documentação do Prometheus scrape_config.

Se você estiver usando autenticação básica e autenticação TLS, consulte a seção abaixo. Para obter mais detalhes, consulte a seção de notas abaixo.

Raspagem baseada em TLS

Se você quiser extrair métricas do Prometheus de um ponto de extremidade https, a configuração do Prometheus, PodMonitor ou ServiceMonitor deve ter as scheme configurações definidas como https TLS extras.

  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.

    Abaixo está 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 no caminho /etc/prometheus/certs/ e é disponibilizado para o raspador Prometheus. 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. Em seguida, na configuração do Prometheus, PodMonitor ou ServiceMonitor, forneça o caminho do arquivo:

  • Para fornecer a configuração TLS em um configmap, siga o exemplo abaixo:
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 de autenticação básica e TLS em seu configmap/CRD, certifique-se de que o segredo ama-metrics-mtls-secret inclua todas as chaves na seção de dados com seus valores codificados em base64 correspondentes, conforme mostrado abaixo:

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

Nota

Nota

O /etc/prometheus/certs/ caminho é obrigatório, mas password1 pode ser qualquer cadeia de caracteres e precisa corresponder à chave para os 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 é automaticamente decodificado pelos pods ama-metrics quando o segredo é montado como arquivo.

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

O segredo deve ser criado primeiro e, em seguida, o configmap, PodMonitor ou ServiceMonitor deve ser criado no kube-system namespace. A ordem da criação secreta é importante. Quando não houver nenhum segredo, mas um configmap, PodMonitor ou ServiceMonitor apontando para o segredo, o seguinte erro estará nos logs de contêiner prometheus-collector ama-metrics: no file found for cert....

Para ler mais sobre as definições de configuração TLS, siga estas configurações.

Próximos passos

Configurar alertas sobre métricas do Prometheus
Consultar métricas do Prometheus
Saiba mais sobre como coletar métricas do Prometheus