Introducción al monitoreo de OpenTelemetry de IBM MQ

Las arquitecturas empresariales modernas dependen en gran medida de las aplicaciones orientadas a mensajes para manejar tareas críticas como el procesamiento de pagos, el enrutamiento de pedidos y los servicios de sincronización. Sin embargo, a medida que estas redes troncales de mensajes escalan, rastrear la degradación del rendimiento se vuelve complejo. Imagine que una aplicación se ralentiza de repente —sin una visibilidad profunda, determinar si el retraso es causado por un consumidor de la aplicación o por una acumulación en la cola de IBM MQ puede ser increíblemente difícil.

New Relic le ayuda a cerrar estas brechas de observabilidad al proporcionar una ruta de monitoreo de OpenTelemetry pura para sus gestores de colas de IBM MQ. Al aprovechar el exportador de Prometheus oficial del equipo de IBM MQ mq-metric-samples, el Collector de OpenTelemetry recopila y da forma a la telemetría sin procesar directamente en la base de datos de New Relic. Cada gestor de colas aparece automáticamente como una entidad IBMMQ_MANAGER distinta con sus colas mapeadas como entidades IBMMQ_QUEUE secundarias — lo que le brinda acceso instantáneo a dashboards preconfigurados, alertas y las señales doradas de su sistema sin requerir agentes propietarios.

Característica clave

La integración de New Relic IBM MQ OpenTelemetry le brinda una visibilidad profunda e independiente del proveedor de su infraestructura de mensajería sin la sobrecarga de agentes propietarios. Al implementar esta integración, desbloquea cuatro capacidades principales de monitoreo diseñadas para mantener sus sistemas asincrónicos funcionando sin problemas:

• Prevención de acumulación y alertas automatizadas: elimine los puntos ciegos en las rutas de entrega de mensajes. Puede configurar alertas activas sobre el aumento de la profundidad de las colas, los picos de mensajes no confirmados y los canales estancados para detectar cuellos de botella antes de que causen retrasos en las aplicaciones posteriores que dependen de su red troncal de mensajería.

• Optimización granular del rendimiento: aísle exactamente dónde se ralentiza el procesamiento de mensajes. Al rastrear las tasas de MQPUT y MQGET en tiempo real junto con los recuentos de conexiones y los tiempos de espera de la cola, puede determinar rápidamente si la fricción de procesamiento se encuentra dentro del propio broker de IBM MQ o en los consumidores de la aplicación lentos.

• Capacidad proactiva y dimensionamiento de recursos: elimine las conjeturas del escalado de la infraestructura. La integración muestra métricas críticas del broker a nivel de host —incluidos los umbrales de tamaño del archivo de log activo, el uso del sistema de archivos y las tendencias de identificadores abiertos—, lo que le permite escalar sus administradores de colas de manera proactiva antes de que el agotamiento de los recursos provoque una falla del broker.

• Entrega confiable y seguimiento de la cola de mensajes no entregados (DLQ): protege la integridad de tus datos transaccionales. Monitorea al instante los cambios de estado del canal, rastrea las acumulaciones en la cola de mensajes no entregados y detecta de manera temprana las llamadas MQI fallidas para identificar configuraciones de enrutamiento incorrectas y caídas antes de que los datos se pierdan permanentemente.

Cómo funciona

Comprender cómo se recopilan, procesan y modelan los telemetry data te ayuda a optimizar tu canal de monitoreo. Las siguientes secciones desglosan exactamente cómo la integración maneja tus datos desde el broker hasta la UI.

Flujo de telemetry data

Los datos de telemetría fluyen secuencialmente a través de cuatro capas distintas antes de visualizarse dentro de New Relic:

1. La capa del broker: cada administrador de colas de IBM MQ rastrea de forma nativa las estadísticas de rendimiento operativo utilizando el formato de comando programable (PCF).
2. La capa del exportador: el exportador mq-metric-samples requerido extrae estas estadísticas de PCF y las expone en un extremo de Prometheus HTTP /metrics estándar. Cada guía de configuración asume que este componente ya se está ejecutando en tu clúster.
3. La capa del Collector: configura el Collector de OpenTelemetry para extraer el extremo del exportador. El recolector filtra el ruido de fondo, formatea las etiquetas de identidad y reenvía los datos OTLP limpios a New Relic.
4. La capa de síntesis: New Relic recibe la carga de OTLP y asigna automáticamente los datos a entidades del espacio de trabajo de IBM MQ legibles y navegables.

La cadena de procesamiento del pipeline

Para mantener sus datos limpios y optimizar las tasas de ingesta, cada métrica recopilada por el recolector pasa por una secuencia de procesamiento automatizada y sensible al orden dentro de su archivo config.yaml:

1. Ingesta de Prometheus: extrae el extremo /metrics de Prometheus sin procesar del exportador en ejecución.
2. Filtro de sobrecarga: descarta las métricas propias del exportador y los ciclos de seguimiento en segundo plano para minimizar el ruido de volumen.
3. Filtro de cola: filtra las colas del sistema interno que no requieren un seguimiento activo del rendimiento.
4. Detección de recursos: sella la carga con etiquetas de identidad de la infraestructura del host y metadatos del entorno.
5. Transformación de etiquetas: normaliza las etiquetas sin procesar de Prometheus al formato estándar de OTel con puntos. Por ejemplo, reasignar targetName a target.name.
6. Limitador de memoria: impone búferes estrictos de cápsulas de memoria en el proceso del recolector para proteger la estabilidad del host.
7. Cumulative-to-Delta: convierte los contadores de métrica de Prometheus absolutos y continuos en valores delta claros.
8. Agrupación por lotes: agrupa eventos de telemetría individuales en cargas de OTLP por lotes para maximizar la eficiencia de la red.
9. Exportación HTTP de OTLP: envía el bloque de datos finalizado y comprimido directamente al sistema de ingesta de datos de New Relic.

Opciones de despliegue de Collector

New Relic es totalmente compatible con dos distribuciones de OpenTelemetry Collector para su integración de IBM MQ. Ambas opciones ofrecen capacidades funcionales idénticas y comparten los mismos archivos de configuración principales:

• NRDOT Collector (recomendado): la distribución seleccionada de New Relic de OpenTelemetry Collector, respaldada directamente por la asistencia de soporte técnico de New Relic. Revisa la base de código de código abierto en el repositorio de GitHub de NRDOT Collector.
• OpenTelemetry Collector: la distribución de la comunidad CNCF upstream. Revise los detalles del proyecto en el repositorio de GitHub de OpenTelemetry Collector Contrib.

El modelo de entidad de IBM MQ

New Relic evalúa marcadores específicos dentro de su flujo de telemetría para sintetizar automáticamente los datos sin procesar en entidades:

• Nombres de métrica con guion bajo sin procesar como ibmmq_qmgr_status y ibmmq_queue_depth
• Etiquetas de datos estructurales qmgr y queue
• El atributo de identidad target.name según la configuración de tu recolector

Al usar estas reglas, la plataforma organiza sus datos en una estructura clara de padre-hijo:

Empezar

La configuración de su canalización de monitoreo de IBM MQ implica tres fases de implementación principales.

Documentación relacionada