Personalización de la extracción de métricas de Prometheus en el servicio administrado de Azure Monitor para Prometheus

  • Artículo

En este artículo se proporcionan instrucciones sobre cómo personalizar la extracción de métricas para un clúster de Kubernetes con el complemento de métricas en Azure Monitor.

Configmaps

Es posible establecer cuatro objetos ConfigMap diferentes para proporcionar la configuración de extracción y otras opciones de configuración para el complemento de métricas. Todos los objetos ConfigMap deben aplicarse al espacio de nombres kube-system de cualquier clúster.

Nota

De forma predeterminada, no existe ninguno de los cuatro mapas de configuración en el clúster cuando se habilita Prometheus administrado. En función de lo que se necesite personalizar, se debe implementar uno de estos cuatro mapas de configuración o todos ellos con el mismo nombre especificado, en el espacio de nombres kube-system. Los pods de AMA-Metrics recogerán estos mapas de configuración después de que se implementen en el espacio de nombres kube-system y se reiniciarán después de 2 o 3 minutos para aplicar la configuración espacio de nombres en los mapas de configuración.

  1. ama-metrics-settings-configmap Este ConfigMap tiene una configuración sencilla que se puede aplicar a continuación. Puede tomar el ConfigMap del repositorio de GitHub que está más arriba, cambiar la configuración necesaria y aplicar o implementar ConfigMap en el espacio de nombres kube-system del clúster
    • alias de clúster (para cambiar el valor de la etiqueta cluster en cada serie temporal o métrica que se ingiere desde un clúster)
    • habilitar o deshabilitar destinos de extracción predeterminados: active o desactive la extracción predeterminada en función de los destinos. La configuración de extracción de estos destinos predeterminados ya está predefinida o integrada
    • habilitación de la extracción basada en anotaciones de pod por espacio de nombres
    • listas de mantenimiento de métricas: esta configuración se usa para controlar qué métricas se muestran para permitirse desde cada destino predeterminado y cambiar el comportamiento predeterminado
    • intervalos de extracción para los objetivos predeterminados/pre-definetargets. 30 secs es la frecuencia de extracción predeterminada y se puede cambiar por destino predeterminado mediante este ConfigMap
    • modo de depuración: activar esta opción ayuda a depurar problemas de ingesta o métricas que faltan; consulte más información sobre la solución de problemas
  2. ama-metrics-prometheus-config Esta instancia de ConfigMap se puede usar para proporcionar la configuración de extracción de Prometheus para la réplica del complemento. El complemento ejecuta una réplica singleton y los servicios de nivel de clúster se pueden detectar y extraer proporcionando trabajos de extracción en este ConfigMap. Puede tomar el ConfigMap de ejemplo del repositorio de GitHub que está más arriba, agregar los trabajos de extracción que necesitaría y aplicar o implementar el ConfigMap al espacio de nombres kube-system del clúster. Aunque esto es compatible, ten en cuenta que la forma recomendada de extraer destinos personalizados es usar recursos personalizados,
  3. ama-metrics-prometheus-config-node (Avanzado) Este ConfigMap se puede usar para proporcionar la configuración de extracción de Prometheus para el complemento DaemonSet que se ejecuta en cada nodo de Linux del clúster y se pueden extraer los destinos de nivel de nodo de cada nodo al proporcionar trabajos de extracción en este ConfigMap. Cuando se usa este ConfigMap, puede usar la variable $NODE_IP en la configuración de extracción, que se sustituye por la dirección IP del nodo correspondiente en el pod DaemonSet que se ejecuta en cada nodo. De esta manera, obtendrá acceso para extraer todo lo que se ejecute en ese nodo desde el complemento de métricas DaemonSet. Tenga cuidado al usar las detecciones en la configuración de extracción en este ConfigMap de nivel de nodo, ya que cada nodo del clúster configurará acciones de detección de objetivos y recopilará métricas redundantes. Puede tomar el ConfigMap de ejemplo del repositorio de GitHub que está más arriba, agregar los trabajos de extracción que necesitaría y aplicar o implementar el ConfigMap al espacio de nombres kube-system del clúster
  4. ama-metrics-prometheus-config-node-windows (Avanzado) Este ConfigMap se puede usar para proporcionar la configuración de extracción de Prometheus para el complemento DaemonSet que se ejecuta en cada nodo de Windows del clúster y se pueden extraer los destinos de nivel de nodo de cada nodo al proporcionar trabajos de extracción en este ConfigMap. Cuando se usa este ConfigMap, puede usar la variable $NODE_IP en la configuración de extracción, que se sustituirá por la dirección IP del nodo correspondiente en el pod DaemonSet que se ejecuta en cada nodo. De esta manera, obtendrá acceso para extraer todo lo que se ejecute en ese nodo desde el complemento de métricas DaemonSet. Tenga cuidado al usar las detecciones en la configuración de extracción en este ConfigMap de nivel de nodo, ya que cada nodo del clúster configurará acciones de detección de objetivos y recopilará métricas redundantes. Puede tomar el ConfigMap de ejemplo del repositorio de GitHub que está más arriba, agregar los trabajos de extracción que necesitaría y aplicar o implementar el ConfigMap al espacio de nombres kube-system del clúster

Definiciones de recursos personalizados

El complemento de métricas de Azure Monitor admite la extracción de métricas de Prometheus mediante Prometheus: monitores de pods y monitores de servicios, similar al operador Prometheus de OSS. Al habilitar el complemento, se implementarán las definiciones de recursos personalizados del monitor de pods y de servicios para que puedas crear tus propios recursos personalizados. Sigue las instrucciones para crear y aplicar recursos personalizados en el clúster.

Configmap de configuración del complemento de métricas

ama-metrics-settings-configmap se puede descargar, editar y aplicar al clúster para personalizar las características preconfiguradas del complemento de métricas.

Habilitar y deshabilitar destinos predeterminados

En la tabla siguiente se incluye una lista de todos los destinos predeterminados que el complemento de métricas de Azure Monitor puede extraer de forma predeterminada y si está habilitado inicialmente. Los destinos predeterminados se extraen cada 30 segundos. Se implementa una réplica para extraer destinos de todo el clúster, como kube-state-metrics. Un DaemonSet también se implementa para extraer destinos de todo el nodo, como kubelet.

Clave Tipo habilitado Pod Descripción
Kubelet bool true DaemonSet de Linux Permite extraer kubelet en todos los nodos del clúster K8s sin ninguna configuración de extracción adicional.
cadvisor bool true DaemonSet de Linux Permite extraer cadvisor en todos los nodos del clúster K8s sin ninguna configuración de extracción adicional.
Solo Linux.
kubestate bool true Réplica de Linux Permite extraer kube-state-metrics en el clúster K8s (instalado como parte del complemento) sin ninguna configuración de extracción adicional.
nodeexporter bool true DaemonSet de Linux Permite extraer las métricas de nodo sin ninguna configuración de extracción adicional.
Solo Linux.
coredns bool false Réplica de Linux Permite extraer el servicio coredns del clúster K8s sin ninguna configuración de extracción adicional.
kubeproxy bool false DaemonSet de Linux Permite extraer kube-proxy en cada nodo de Linux detectado en el clúster K8s sin ninguna configuración de extracción adicional.
Solo Linux.
apiserver bool false Réplica de Linux Permite extraer el servidor de API de Kubernetes en el clúster K8s sin ninguna configuración adicional de extracción.
windowsexporter bool false DaemonSet de Windows Permite extraer windows-exporter en todos los nodos del clúster K8s sin ninguna configuración de extracción adicional.
Solo Windows.
windowskubeproxy bool false DaemonSet de Windows Permite extraer windows-kube-proxy en todos los nodos del clúster K8s sin ninguna configuración de extracción adicional.
Solo Windows.
prometheuscollectorhealth bool false Réplica de Linux Permite extraer información sobre el contenedor prometheus-collector, como la cantidad y el tamaño de las series temporales que se extraen.

Si desea activar la extracción de los destinos predeterminados que no están habilitados de forma predeterminada, edite el configmapama-metrics-settings-configmap para actualizar los destinos enumerados en default-scrape-settings-enabled a true. Aplique el configmap al clúster.

Habilitación de la extracción basada en anotaciones de pod

Para extraer pods de aplicación sin necesidad de crear una configuración personalizada de Prometheus, se pueden agregar anotaciones a los pods. La anotación prometheus.io/scrape: "true" es necesaria para que se extraiga el pod. Las anotaciones prometheus.io/path y prometheus.io/port indican la ruta de acceso y el puerto en los que se hospedan las métricas en el pod. Las anotaciones de un pod que hospeda métricas en <pod IP>:8080/metrics serían:

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

La extracción de estos pods con anotaciones específicas está deshabilitada de forma predeterminada. Para habilitar, en ama-metrics-settings-configmap, agregue la expresión regular para los espacios de nombres de los pods con anotaciones que desea extraer como el valor del campo podannotationnamespaceregex.

Por ejemplo, la siguiente configuración extrae pods con anotaciones solo en los espacios de nombres kube-system y my-namespace:

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

Para habilitar la extracción de pods con anotaciones en todos los espacios de nombres, use:

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

Advertencia

La extracción de las anotaciones de pod de muchos espacios de nombres puede generar un gran volumen de métricas en función del número de pods que tienen anotaciones.

Personalización de métricas recopiladas por destinos predeterminados

De forma predeterminada, para todos los destinos predeterminados, solo se ingieren métricas mínimas usadas en las reglas de grabación predeterminadas, las alertas y los paneles de Grafana, tal como se describe en minimal-ingestion-profile. Para recopilar todas las métricas de los destinos predeterminados, actualice las listas de mantenimiento en la ConfigMap de los valores en default-targets-metrics-keep-list y establezca minimalingestionprofile en false.

Para incluir más métricas en la lista de permitidos además de las métricas predeterminadas que se muestran como permitidas, para los destinos predeterminados, edite la configuración en default-targets-metrics-keep-list para el trabajo correspondiente que desea cambiar.

Por ejemplo, kubelet es la configuración de filtrado de métricas para el kubelet de destino predeterminado. Use el siguiente script para filtrar las métricas in recopiladas para los destinos predeterminados mediante el filtrado basado en regex.

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

Nota

Si usa comillas o barras diagonales inversas en la expresión regular, debe escaparlas mediante una barra diagonal inversa como en los ejemplos "test\'smetric\"s\"" y testbackslash\\*.

Para personalizar aún más los trabajos predeterminados para cambiar las propiedades, como la frecuencia de recopilación o las etiquetas, deshabilite el destino predeterminado correspondiente estableciendo el valor de configmap para el destino en false. A continuación, aplique el trabajo mediante un configmap personalizado. Para más información sobre la configuración de personalización, consulte Personalización de la extracción de métricas de Prometheus en Azure Monitor.

Alias de clúster

La etiqueta del clúster anexada a cada serie temporal que se extrae usará la última parte del id. de recurso completo de Azure Resource Manager del clúster de AKS. Por ejemplo, si el id. de recurso es /subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclustername, la etiqueta del clúster es myclustername.

Para invalidar la etiqueta del clúster en la serie temporal que se extrae, actualice la configuración cluster_alias a cualquier cadena de prometheus-collector-settings en el configmapama-metrics-settings-configmap. Puede crear este ConfigMap si no existe en el clúster o puede editar el existente si ya existe en el clúster.

La nueva etiqueta también se mostrará en la lista desplegable de parámetros del clúster en los paneles de Grafana en lugar de en la predeterminada.

Nota

Solo puede contener caracteres alfanuméricos. Cualquier otro carácter se reemplazará por _. Este cambio es para garantizar que los distintos componentes que consumen esta etiqueta se adhieran a la convención alfanumérica básica.

Modo de depuración

Advertencia

Este modo puede afectar al rendimiento y solo debe habilitarse durante un breve período de tiempo con fines de depuración.

Para ver todas las métricas que se extraen con fines de depuración, el agente del complemento de métricas se puede configurar para ejecutarse en modo de depuración mediante la actualización de la configuración enabled a true en la configuración debug-mode del configmapama-metrics-settings-configmap. Puede crear este configmap o editar uno existente. Consulte la sección Modo de depuración en la Solución de problemas de la recopilación de métricas de Prometheus para obtener más detalles.

Configuración del intervalo de extracción

Para actualizar la configuración del intervalo de extracción para cualquier destino, puede actualizar la duración en la configuración default-targets-scrape-interval-settings para ese destino en configmapama-metrics-settings-configmap. Debe establecer los intervalos de extracción en el formato correcto especificado en este sitio web. De lo contrario, el valor predeterminado de 30 segundos se aplica a los destinos correspondientes. Por ejemplo: si desea actualizar el intervalo de extracción del trabajo kubelet a 60s, puede actualizar la sección siguiente en 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"

y aplique el código YAML mediante el siguiente comando: kubectl apply -f .\ama-metrics-settings-configmap.yaml

Configuración de trabajos de extracción personalizados de Prometheus

Puedes extraer métricas de Prometheus mediante Prometheus: monitores de pods y monitores de servicios (recomendado), similar al operador Prometheus de OSS. Sigue las instrucciones para crear y aplicar recursos personalizados en el clúster.

Además, puedes seguir las instrucciones para crear, validar y aplicar el mapa de configuración del clúster. El formato de configuración es similar al archivo de configuración de Prometheus.

Sugerencias y ejemplos de configuración de Prometheus

Obtenga algunas sugerencias de ejemplos en esta sección.

Usa las plantillas de monitor de pods y de servicios y sigue la especificación de la API para crear los recursos personalizados(Monitor de pods y Monitor de servicios). Ten en cuenta que el único cambio necesario para las solicitudes de certificación del sistema operativo existentes a fin de que los recoja Prometheus administrado es el grupo de API: azmonitoring.coreos.com/v1. Consulta aquí para más información.

Nota

Cuando la configuración de extracción personalizada no se puede aplicar debido a errores de validación, se seguirá usando la configuración de extracción predeterminada.

Si quieres usar la configuración global que se aplica a todos los trabajos de extracción y solo tienes Recursos personalizados, todavía tendrías que crear un mapa de configuración solo con los valores globales (la configuración para cada uno de ellos en los recursos personalizados invalidará las de la sección global).

Configuraciones de extracción

Actualmente, los métodos admitidos de detección de destino para recursos personalizados son el monitor de pods y de servicios

Monitores de pods y de servicios

Los destinos detectados mediante monitores de pods y servicios tienen etiquetas de __meta_* diferentes en función de qué monitor se use. Las etiquetas se pueden usar en la sección relabelings para filtrar destinos o para reemplazar las etiquetas para los destinos.

Consulta los ejemplos de Monitor de pods y servicios de los monitores de pods y servicios.

Cambio de etiquetas

La sección relabelings se aplica en el momento de la detección de los destinos y a cada destino para el trabajo. Los siguientes ejemplos muestran cómo usar relabelings.

Adición de una etiqueta

Agregue una nueva etiqueta denominada example_label con valor example_value a cada métrica del trabajo. Use __address__ como etiqueta de origen solo porque esa etiqueta siempre existirá y agregará la etiqueta para cada destino del trabajo.

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

Uso de etiquetas de monitor de pods y servicios

Los destinos detectados mediante monitores de pods y servicios tienen etiquetas de __meta_* diferentes en función de qué monitor se use. Las etiquetas __* se quitan después de detectar los destinos. Para filtrarlas en el nivel de métricas, primero guárdelas mediante relabelings asignándoles un nombre de etiqueta. Después, 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'

Cambio de las etiquetas de los trabajos y las instancias

Los valores de etiqueta job y instance se pueden cambiar en función de la etiqueta de origen, al igual que cualquier otra etiqueta.

# 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

Cambio de etiquetas de métricas

Los cambios de etiquetas de métricas se aplican después de la extracción y antes de la ingesta. Use la sección metricRelabelings para filtrar las métricas después de la extracción. En los ejemplos siguientes se muestra cómo hacerlo.

Eliminación de métricas por nombre

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

Mantenimiento de solo determinadas métricas por nombre

# 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_.*)'

Cambio de nombre de las métricas

No se admite el cambio de nombre de métrica.

Filtrado de métricas por etiquetas

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

Extracción basada en TLS

Si tiene una instancia de Prometheus atendida con TLS y desea extraer métricas de ella, debe establecer el esquema en https y establecer la configuración de TLS en el mapa de configuración o la CRD correspondiente. Puede usar la propiedad de configuración de tls_config dentro de un trabajo de extracción personalizado para configurar los valores de TLS mediante un CRD o un mapa de configuración. Debe proporcionar un certificado de CA con el cual validar el certificado del servidor de API. El certificado de CA se usa para comprobar la autenticidad del certificado del servidor cuando Prometheus se conecta al destino a través de TLS. Ayuda a garantizar que el certificado del servidor esté firmado por una entidad de confianza.

El secreto debe crearse en el espacio de nombres kube-system y, a continuación, se debe crear configmap/CRD en el espacio de nombres kube-system. El orden de creación de los secretos es importante. Cuando no haya ningún secreto, pero haya un mapa CRD/ConfigMap válido, encontrará errores en el registro del recopilador: >no file found for cert....

A continuación se muestran los detalles sobre cómo proporcionar la configuración de TLS a través de un mapa de configuración o CRD.

  • Para proporcionar la configuración de TLS en un mapa de configuración, crea el certificado autofirmado y la clave dentro de la aplicación habilitada para mtls. Un ejemplo de tlsConfig dentro del mapa de configuración debe tener este aspecto:
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 proporcionar la configuración de TLS en un CRD, crea el certificado autofirmado y la clave dentro de la aplicación habilitada para mtls. Un ejemplo de tlsConfig dentro de un Podmonitor debe tener este aspecto:
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:

Asegúrese de que el nombre de archivo de certificado y el nombre de clave dentro de la aplicación mtls tengan el siguiente formato en el caso de una extracción basada en CRD. Por ejemplo: secret_kube-system_ama-metrics-mtls-secret_cert-name.pem and secret_kube-system_ama-metrics-mtls-secret_key-name.pem. El CRD debe crearse en el espacio de nombres kube-system. El nombre del secreto debe ser exactamente ama-metrics-mtls-secret en el espacio de nombres kube-system. Un comando de ejemplo para crear un secreto: 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 obtener más información sobre la autenticación TLS, es posible que los siguientes documentos sean útiles.

Autenticación básica

Si utiliza basic_auth ajuste en la configuración de prometheus, siga los pasos:

  1. Cree un secreto en el espacio de nombres kube-system denominado ama-metrics-mtls-secret

El valor de password1 es base64encoded La clave password1 puede ser cualquier cosa, pero solo tiene que coincidir con su ruta de archivo 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. En el mapa de configuración de la configuración de extracción personalizada, use la siguiente configuración:
basic_auth:
  username: admin
  password_file: /etc/prometheus/certs/password1

Nota:

Asegúrese de que el nombre es ama-metrics-mtls-secret y está en el espacio de nombres kube-system.

La ruta de acceso /etc/prometheus/certs/ es obligatoria, pero password1 puede ser cualquier cadena y debe coincidir con la clave de los datos del secreto creado anteriormente. Esto se debe a que el secreto ama-metrics-mtls-secret se monta en la ruta de acceso /etc/prometheus/certs/ dentro del contenedor.

El valor codificado en base64 es descodificado automáticamente por los pods del agente cuando el secreto se monta como archivo.

Cualquier otro ajuste de configuración para la autorización que se considere secreto en la configuración de prometheus debe utilizar en su lugar la alternativa de ajuste de archivo, tal y como se ha descrito anteriormente.

Pasos siguientes

Configuración de alertas en métricas de Prometheus
Consulta de las métricas de Prometheus
Obtenga más información sobre la recopilación de métricas de Prometheus