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.

Note: Para obtener más información sobre el uso de Grafana y paneles de control de ejemplo, consulte Supervisión de HCL Commerce: Integración de Prometheus y Grafana.

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

Las métricas se habilitan de forma predeterminada cuando se utilizan los gráficos Helm de HCL Commerce. También se pueden habilitar al configurar la variable del entorno:
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() y increase() que se pueden utilizar como protección ante los restablecimientos del contador
Consulte los siguientes ejemplos para definir un tipo de contador:
Añadir un nuevo contador con etiquetas de valor conocido
private static Counter BACKEND_COUNTER = 
        Metrics.isEnabled() 
            ? Counter.builder( "backend.calls.total" )
               .tags( "result", "ok" )
               .description("Number of successful backend requests")
               .builder.register( Metrics.getRegistry())
            : null;
…

if ( BACKEND_COUNTER != null ) {
   BACKEND_COUNTER.increment();
}
Añadir por adelantado un nuevo contador con etiquetas desconocidas
if ( Metrics.isEnabled() ) {

   Metrics.getRegistry().counter( 
      "backend.calls.total", 
      "result",
      myGetResult()
     ).increment();  
}
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étodos Metrics.applySLO(final String metricName, final long[] slos) o Metrics.applySLO(final String metricName, final String name) del programa de utilidad se pueden utilizar para el mismo.

Ejemplo: Agregar un nuevo temporizador con valores de etiqueta no conocidos de antemano
private static String TIMER_NAME = "backend.calls.duration";

static {
   Metrics.applySLO( TIMER_NAME, Metrics.DEFAULT_SLO_REST_DURATIONS_NAME );
}

…

if ( Metrics.isEnabled() ) {
  startTime = System.nanoTime();
}

doWork();

if ( Metrics.isEnabled() ) {
   final long deltaTime = System.nanoTime() - startTime;
   Metrics.getRegistry().timer(
        TIMER_NAME,
        "result",
        getResult() )
            .record( deltaTime , TimeUnit.MILLISECONDS ); 

}
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.
Ejemplo: Definición de un medidor
class MyService {

 private Gauge myActiveClientsGauge;

 final void setup() {
   if (Metrics.isEnabled()) {
     myActiveClientsGauge = Gauge.builder( "myservice.activeclients", this,       
                                MyService::getActiveClients )
      .tags("endpoint", getEndpointName())
      .register(Metrics.getRegistry());
   }
 }
 
 private double getActiveClients() {		
   return nActiveClients; 
 }
}