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 configmapama-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"

Para habilitar a raspagem para 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 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/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 do cluster na série temporal raspada, atualize a configuração cluster_alias para qualquer cadeia de caracteres no prometheus-collector-settingsconfigmapama-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.

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 raspadas 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 configmapama-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 configmapama-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

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

Raspagem baseada em TLS

Se você tiver uma instância do Prometheus servida com TLS e quiser extrair métricas dela, precisará definir o esquema e https definir as configurações de TLS em seu configmap ou respetivo CRD. Você pode usar a tls_config propriedade configuration dentro de um trabalho de raspagem personalizado para definir as configurações de TLS usando um CRD ou um configmap. Você precisa fornecer um certificado de autoridade de certificação para validar o certificado do servidor de API. O certificado da autoridade de certificação é usado para verificar a autenticidade do certificado do servidor quando o Prometheus se conecta ao destino por TLS. Ele 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 configmap/CRD deve ser criado no namespace kube-system. A ordem da criação secreta é importante. Quando não há segredo, mas um mapa CRD/config válido, você encontrará erros no log do coletor ->no file found for cert....

Abaixo estão os detalhes sobre como fornecer as configurações de configuração TLS através de um configmap ou CRD.

  • Para fornecer a configuração TLS em um configmap, crie o certificado autoassinado e a chave dentro do seu aplicativo habilitado para mtls. Um exemplo de tlsConfig dentro do mapa de configuração 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 TLS em um CRD, crie o certificado autoassinado e a chave dentro do seu 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

Nota

Certifique-se de que o nome do arquivo de certificado e o nome da chave dentro do aplicativo mtls estejam no seguinte formato no caso de uma raspagem 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 secreto deve ser exatamente ama-metrics-mtls-secret no namespace kube-system. Um exemplo de comando para criar 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, os seguintes documentos podem ser úteis.

Autenticação Básica

Se você estiver usando basic_auth a configuração em sua configuração prometheus, por favor, siga os passos -

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

O valor para password1 é base64encoded A chave password1 pode ser qualquer coisa, mas só precisa corresponder ao seu scrapeconfig password_file filepath.

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

Nota

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

O caminho /etc/prometheus/certs/ é obrigatório, mas password1 pode ser qualquer string 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 base64 é automaticamente decodificado pelos pods do agente quando o segredo é montado como arquivo.

Qualquer outra definição de configuração para autorização que seja considerada como um segredo na configuração do Prometheus precisa usar a alternativa de configuração de arquivo em vez disso, conforme descrito acima.

Próximos passos

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