Métricas ampliables a la supervisión y las alertas
Puede utilizar la infraestructura de supervisión de métricas versión 9.1 de HCL Commerce a través de paneles de control de rendimiento incorporados o puede crear los suyos propios. Los datos de supervisión se recopilan con Micrometer y se muestran según el formato Prometheus, que es de uso común en el sector. Esto significa que puede utilizarlos con muchas herramientas diferentes. HCL ofrece un conjunto de paneles de control de Grafana que le ayudarán a empezar a trabajar.
También puede utilizar este marco de supervisión de métricas para visualizar las solicitudes de caché enviadas y recibidas por Nifi. Utilizando esta nueva API, http://NIFIHOST:30690/monitor/metrics
, los datos de monitorización pueden recogerse en el formato Prometheus, estándar del sector, que puede utilizarse en Grafana o en cualquier otra herramienta diferente para visualizar las solicitudes de caché enviadas y recibidas por Nifi.
La infraestructura de supervisión consta de tres partes. En primer lugar, una capa de presentación completamente personalizable le permite utilizar sus herramientas preferidas para informar y analizar el rendimiento del sistema. La flexibilidad de esta capa se debe a un lenguaje estándar de representación de datos que no depende del proveedor. Este es el kit de herramientas de Prometheus de código abierto. Por último, Prometheus obtiene sus datos de la biblioteca de Micrometer, la cual es completamente personalizable y "rastrea" los datos de los contenedores.
Creación de informes y paneles
La parte superior de la infraestructura es la capa de informes. Debido a que los datos se representan en el formato Prometheus, puede servirse de diferentes herramientas para mostrarlos y analizarlos. Una herramienta popular para trabajar con paneles de control es Grafana (https://grafana.com/). Grafana se suele utilizar con Prometheus, lo que permite ofrecer un análisis gráfico de los datos de supervisión.
Puede descargar los paneles de control de Grafana HCL Commerce desde HCL License and Delivery portal. Para obtener más información sobre el paquete de panel de instrumentos de Grafana HCL Commerce disponible, consulte HCL Commerce eAssemblies.
Kit de herramientas de Prometheus
HCL Commerce las métricas utilizan Prometheus, un formato de exposición que se basa en el uso de texto. Aunque este formato es nativo de la infraestructura de supervisión de Prometheus (https://Prometheus.IO/), su popularidad hizo que un gran número de empresas lo adoptaran o fuesen compatibles. Por ejemplo, en 2016 Prometheus se unió a la Cloud Native Computing Foundation como su segundo proyecto alojado, después de Kubernetes.
Supervisión de aplicaciones Micrometer
Los datos de supervisión y rendimiento se rastrean a través de la biblioteca de instrumentación de Micrometer, la cual se basa en JVM. El concepto clave del Micrometer es el medidor. Existe un amplio conjunto de primitivas de medición predefinidas que establecen horas, contadores, indicadores y otros tipos de recopilación de datos. Puede utilizar los medidores predeterminados para recopilar datos de rendimiento y supervisión de los contenedores o para personalizar sus datos propios.
Las métricas del rendimiento de cada contenedor se exponen en el punto final de /monitor/metrics. Se recopilan mediante un proceso conocido como "rastreo". Micrometer rastrea el punto final de metrics en todos los contenedores dentro de un dispositivo interno configurable. Las métricas se almacenan en una base de datos a través de la cual otros servicios pueden acceder a ellas. En los entornos de Kubernetes, los rastreadores también agregan metadatos contextuales a las métricas que se obtienen a través de puntos finales, como el servicio, el espacio de nombres y el pod que identifican el origen de los datos.
Configuración de los medidores
EXPOSE_METRICS=true
Las métricas se exponen en cada pod en las siguientes vías de acceso y puertos:Despliegue | Vía de acceso | Puerto de métricas (http) |
---|---|---|
demoqaauthcrs-App | /supervisar/métricas | 8280 |
demoqaauthsearch-* | /supervisar/métricas | 3280 |
demoqaliveingest-App | /supervisar/métricas | 30880 |
demoqalivequery-App | /supervisar/métricas | 30280 |
demoqaauthts-App | /supervisar/métricas | 5280 |
demoqaauthxc-App | /supervisar/métricas | 9280 |
demoqaingest-App | /supervisar/métricas | 30880 |
demoqalivequery-App | /supervisar/métricas | 30280 |
Además de habilitar métricas, el gráfico Helm muestra el puerto de métricas a través de los servicios y ofrece la opción de definir un servicemonitor (metrics.servicemonitor.enabled
, metrics.servicemonitor.namespace
) que puede utilizarse con el operador de Prometheus.
Implementación de los medidores personalizados
Además del conjunto de medidores predeterminados, puede añadir el suyo propio. Cuando se habilitan los medidores, la clase de métricas hace que el registro global esté disponible. Los medidores que se añaden al registro global se publican automáticamente en el punto final de las métricas.
Se pueden añadir nuevos medidores al registro utilizando las API de Micrometer. Consulte la información de Micrometer Javadoc para API: https://javadoc.io/doc/io.micrometer/micrometer-core/1.3.5/index.html.
Ejemplos
Los ejemplos siguientes muestran cómo pueden utilizarse las métricas desde el código personalizado.
- Contadores
- Un conteo positivo que puede incrementar una cantidad fija. Por ejemplo, "número de solicitudes". Prometheus incluye funciones como
rate()
yincrease()
que se pueden utilizar como protección ante los restablecimientos del contador - Temporizadores
- Los temporizadores se utilizan para realizar un seguimiento de la duración y frecuencia de los sucesos. Además de calcular las duraciones promedio, la API permite configurar un conjunto de objetivos de nivel de servicio (SLO), los cuales se convierten en sectores de histograma. Los SLO también pueden utilizarse para calcular cuantiles. Para obtener más información, consulte Histogramas y resúmenes en el sitio web de Prometheus.
La clase de métricas define los SLO para su uso común. Por ejemplo, Metrics.DEFAULT_SLO_REST_DURATIONS_NAME define los grupos que son adecuados para los tiempos de ejecución de REST típicos. Si el temporizador no coincide con estas duraciones, puede establecer valores nuevos como una matriz larga. Para obtener más información, consulte
.sla()
en la definición de clase Timer. Builder en el sitio web de Micrometer.Ejemplo: Agregar de un nuevo temporizador con etiquetas de valor conocido
private static Timer BACKEND_TIMER = Metrics.isEnabled() ? Timer.builder( "backend.calls.duration" ) .tags( "result", "ok" ) .sla( Metrics.getSLOsByName(Metrics.DEFAULT_SLO_REST_DURATIONS_NAME) ) .description("Duration of successful backend requests") .builder.register( Metrics.getRegistry()) : null; … if (BACKEND_TIMER != null ) { startTime = System.nanoTime(); } doWork(); if (BACKEND_TIMER != null ) { final long deltaTime = System.nanoTime() - startTime; BACKEND_TIMER .record(deltaTime, TimeUnit.NANOSECONDS ); }
Cuando se utiliza un temporizador con valores de etiqueta que no se conocen de antemano, la API de Micrometer no permite especificar el
(.sla(..))
del SLO . Para poder conseguirlo, debe establecer un filtro del medidor para fusionar su configuración. Los métodosMetrics.applySLO(final String metricName, final long[] slos)
oMetrics.applySLO(final String metricName, final String name)
del programa de utilidad se pueden utilizar para el mismo. - Calibradores
- Un medidor contiene un valor que puede aumentar y disminuir con el tiempo. El medidor se correlaciona con una función para obtener el valor. Algunos ejemplos son: el número de sesiones activas y los tamaños de las memorias caché actuales.