Sigue las instrucciones a continuación para instalar y configurar este check para un Agent que se ejecuta en un host. Para entornos en contenedores, consulta las plantillas de integración de Autodiscovery para obtener orientación sobre la aplicación de estas instrucciones.
Esta integración basada en OpenMetrics tiene un modo más reciente (que se habilita al configurar openmetrics_endpoint de modo que apunte hacia el endpoint de destino) y un modo heredado (que se habilita al configurar prometheus_url en su lugar). Para obtener todas las características más actualizadas, Datadog recomienda habilitar el modo más reciente. Para obtener más información, consulta Control de versiones más reciente y heredado para las integraciones basadas en OpenMetrics.
Edita el archivo conf.d/openmetrics.d/conf.yaml en la raíz de tu directorio de configuración del Agent. Consulta el openmetrics.d/conf.yaml de ejemplo para todas las opciones disponibles de configuración. Este es el ejemplo más reciente del check de OpenMetrics a partir de la versión 7.32.0 de Datadog Agent. Si previamente implementaste esta integración, consulta el ejemplo de legacy.
Para cada instancia, se requieren los siguientes parámetros:
Parámetro
Descripción
openmetrics_endpoint
La URL donde se expone tus métricas de aplicación en formato Prometheus u OpenMetrics (debe ser única).
namespace
El espacio de nombres se añade a todas las métricas.
metrics
Una lista de métricas para recuperar como métricas personalizadas. Añade cada métrica a la lista como metric_name o metric_name: renamed para renombrarla. Las métricas se interpretan como expresiones regulares. Utiliza ".*" como comodín (metric.*) para recuperar todas las métricas que coincidan. Nota: Las expresiones regulares pueden enviar muchas métricas personalizadas.
A partir del Datadog Agent v7.32.0, de acuerdo con el estándar de especificación de OpenMetrics, los nombres de contador que terminan en _total deben especificarse sin el sufijo _total. Por ejemplo, para recopilar promhttp_metric_handler_requests_total, especifica el nombre de métrica promhttp_metric_handler_requests. Esto envía a Datadog el nombre de métrica con .count, promhttp_metric_handler_requests.count.
Este check tiene un límite de 2000 métricas por instancia. El número de métricas devueltas se indica al ejecutar el comando de estado del Datadog Agent. Puedes especificar las métricas que te interesan editando la configuración. Para saber cómo personalizar las métricas a recopilar, consulta Recopilación de métricas de Prometheus y OpenMetrics.
Si necesitas monitorizar más métricas, ponte en contacto con el soporte de Datadog.
Todas las métricas recopiladas por el check de OpenMetrics se reenvían a Datadog como métricas personalizadas.
Eventos
El check de OpenMetrics no incluye ningún evento.
Checks de servicio
El check de OpenMetrics no incluye ningún check de servicio.
Solucionar problemas
Facturación alta de métricas personalizadas
Las configuraciones de OpenMetrics con valores comodín genéricos para la opción metrics tienen un impacto significativo en la facturación de métricas personalizadas.
Datadog recomienda utilizar nombres específicos de métrica o coincidencias parciales de nombres de métrica para una recopilación más precisa.
Métricas sin tipo faltantes
Por defecto, la integración omite métricas que no tienen tipo en una exposición de Prometheus. Si deseas recopilar métricas sin tipo, debes especificar explícitamente su tipo en la asignación metrics, por ejemplo:
Recuerda que los nombres de métrica pueden especificarse como expresiones regulares, lo que permite especificar el tipo para un conjunto de métricas sin enumerarlas todas individualmente.
Errores en el parseo de la carga útil de OpenMetrics con Agent 7.46
La versión de esta integración incluida en la versión 7.46 del Agent da preferencia por defecto al formato de OpenMetrics cuando solicita métricas al endpoint de métricas. Lo hace estableciendo el encabezado Accept en application/openmetrics-text;version=1.0.0,application/openmetrics-text;version=0.0.1;q=0.75,text/plain;version=0.0.4;q=0.5,*/*;q=0.1. Esto se hizo en combinación con la determinación dinámica de qué seleccionador utilizar en función del Content-Type que recibe del servidor, para reducir la necesidad de configuración manual.
Las versiones anteriores utilizaban por defecto text/plain, lo que normalmente hace que el servidor devuelva métricas en el formato de exposición de Prometheus. Esto significa que la actualización a esta versión de integración puede provocar el cambio del formato de Prometheus al formato de OpenMetrics.
Aunque el comportamiento debería seguir siendo el mismo en la mayoría de las circunstancias, algunas aplicaciones devuelven métricas en un formato que no es totalmente compatible con OpenMetrics, a pesar de configurar Content-Type para indicar el uso del formato estándar de OpenMetrics. Esto puede hacer que nuestra integración informe de errores durante el parseo de la carga útil de métricas.
Si observas errores en el parseo al seleccionar el endpoint de OpenMetrics con esta nueva versión, puedes forzar el uso del formato menos estricto de Prometheus, al configurar manualmente el encabezado Accept que la integración envía a text/plain mediante la opción headers en el archivo de configuración. Por ejemplo:
## Todas las opciones definidas aquí están disponibles para todas las instancias.#init_config:...instances:- openmetrics_endpoint:<OPENMETRICS_ENDPOINT>...headers:Accept:text/plain
