Métriques extensibles pour la surveillance et les alertes

Vous pouvez utiliser la structure de surveillance des métriques de HCL Commerce version 9.1 avec des tableaux de bord de performances intégrés ou créer le vôtre. Les données de surveillance sont recueillies à l'aide de Micrometer et sont fournies au format Prometheus respectant les normes de l'industrie. Cela signifie que vous pouvez les utiliser avec de nombreux outils. HCL fournit un ensemble de tableaux de bord Grafana pour vous lancer.

Vous pouvez également utiliser cette structure de surveillance des métriques pour visualiser les demandes de cache envoyées et reçues par Nifi. A l'aide de cette nouvelle API, http://NIFIHOST:30690/monitor/metrics, les données de surveillance peuvent être collectées au format Prometheus conforme aux normes de l'industrie qui peut être utilisé dans Grafana ou tout autre outil pour visualiser les demandes de cache envoyées et reçues par Nifi.

La structure de surveillance comporte trois volets. Tout d'abord, une couche de présentation entièrement personnalisable vous permet d'utiliser vos outils préférés pour générer des rapports sur les performances de vos systèmes et les analyser. La flexibilité de cette couche provient de son utilisation d'un langage de représentation des données respectant les normes de l'industrie et neutre en termes de fournisseur. Il s'agit de la boîte à outils Open Source Prometheus. Enfin, Prometheus obtient ses données à partir de la bibliothèque Micrometer entièrement personnalisable, qui "racle" les données de vos conteneurs.

Note: Pour plus d'informations sur l'utilisation de Grafana et d'exemples de tableaux de bord, voir HCL Commerce Monitoring - Prometheus and Grafana Integration.

Reporting et tableau de bord

Le haut de la structure correspond à la couche de rapports. Etant donné que vos données sont représentées au format Prometheus, vous pouvez utiliser de nombreux outils pour les afficher et les analyser. Grafana (https://grafana.com/) est un outil de tableau de bord populaire. Grafana est souvent utilisé avec Prometheus pour fournir une analyse graphique des données de surveillance.

Vous pouvez télécharger les tableaux de bord HCL Commerce Grafana à partir de HCL License and Delivery portal. Pour plus d'informations sur le package Tableau de bord Grafana HCL Commerce disponible, voir HCL Commerce eAssemblies.

La boîte à outils Prometheus

HCL Commerce Les métriques X utilisent le format d'exposition texte de Prometheus. Bien que ce format soit natif de la structure de surveillance de Prometheus (https://prometheus.io/), la popularité du format a conduit à son adoption de façon généralisée. Par exemple, Prometheus a rejoint la Cloud Native Computing Foundation en 2016 en tant que deuxième projet hébergé, après Kubernetes.

Surveillance d'application Micrometer

Les données de surveillance et de performances sont raclées à l'aide de la bibliothèque d'instruments Micrometer basée sur une JVM. Le concept clé pour Micrometer est le mètre. Il existe un riche ensemble de primitives de mètres prédéfinies qui définissent les temps, les compteurs, les jauges et d'autres types de collecte de données. Vous pouvez utiliser les mètres par défaut pour agréger les performances et surveiller les données de vos conteneurs, ou personnaliser les vôtres.

Les métriques de performances de chaque conteneur sont exposées à son nœud final /monitor/metrics. Elles sont recueillies par un processus connu sous le nom de "raclage". Micromètre racle le nœud final metrics sur tous les conteneurs à un interne configurable. Les métriques sont stockées dans une base de données à laquelle peuvent accéder d'autres services. Dans les environnements Kubernetes, les racleurs ajoutent également des métadonnées contextuelles aux métriques obtenues par les points de terminaison, tels que le service, l'espace de nom et le pod qui identifient l'origine des données.

Configuration des mètres

Les métriques sont activées par défaut lors de l'utilisation des graphiques HCL Commerce Helm. Ils peuvent également être activés en configurant la variable d'environnement :
EXPOSE_METRICS=true
Les métriques sont exposées sur chaque pod sur les chemins et ports suivants :
Déploiement Chemin Port métrique (http)
demoqaauthcrs-app /monitor/metrics 8280
demoqaauthsearch-* /monitor/metrics 3280
demoqaliveingest-app /monitor/metrics 30880
demoqalivequery-app /monitor/metrics 30280
demoqaauthts-app /monitor/metrics 5280
demoqaauthxc-app /monitor/metrics 9280
demoqaingest-app /monitor/metrics 30880
demoqalivequery-app /monitor/metrics 30280

En plus d'activer les métriques, le graphique Helm expose le port métrique à travers les services, et offre la possibilité de définir un servicemonitor (metrics.servicemonitor.enabled, metrics.servicemonitor.namespace) pour une utilisation avec Prometheus Operator.

Implémentation de mètres personnalisés

En plus de l'ensemble par défaut de mètres, vous pouvez ajouter le vôtre. Lorsque les mètres sont activés, la classe Metrics rend le registre global disponible. Les mètres ajoutés au registre global sont automatiquement publiés au nœud final métrique.

De nouveaux mètres peuvent être ajoutés au registre à l'aide des API Micrometer. Voir le Micrometer Javadoc pour plus de détails sur l'API : https://javadoc.io/doc/io.micrometer/micrometer-core/1.3.5/index.html.

Exemples

Les exemples suivants montrent comment les métriques peuvent être utilisées à partir de code personnalisé.

Compteurs
Nombre positif pouvant être augmenté d'un nombre fixe. Par exemple, "nombre de requêtes". Prometheus inclut des fonctions telles que rate() et increase() qui peuvent être utilisées pour se protéger contre les réinitialisations de compteur.
Voir les exemples suivants pour définir un type de compteur :
Ajout d'un nouveau compteur dont les libellés de valeur sont connus
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();
}
Ajout d'un nouveau compteur dont les libellés ne sont pas connus à l'avance
if ( Metrics.isEnabled() ) {

   Metrics.getRegistry().counter( 
      "backend.calls.total", 
      "result",
      myGetResult()
     ).increment();  
}
Temporisateurs
Les temporisateurs sont utilisés pour suivre la durée et la fréquence des événements. Outre le calcul des durées moyennes, l'API permet de configurer un ensemble d'objectifs de niveau de service (SLO), qui sont traduits en périodes d'histogramme. Les SLO peuvent également être utilisés pour calculer les quantiles. Pour plus d'informations, voir Histograms and Summaries (Histogrammes et résumés) sur le site Web de Prometheus.

La classe Metrics définit les SLO pour les usages courants. Par exemple, Metrics.DEFAULT_SLO_REST_DURATIONS_NAME définit les périodes adaptées aux temps d'exécution typiques de REST. Si votre temporisateur ne correspond pas à ces durées, vous pouvez spécifier de nouvelles valeurs en tant que tableau long. Pour plus d'informations, voir .sla() dans la définition de la classe Timer.Builder sur le site Web de Micrometer.

Exemple : Ajout d'un nouveau temporisateur dont les libellés de valeur sont connus

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 );
}

Lorsque vous utilisez un temporisateur avec des valeurs d'étiquette qui ne sont pas connues à l'avance, l'API Micrometer ne permet pas de spécifier le SLO (.sla(..)). Pour ce faire, définissez un filtre de mètre pour fusionner la configuration. Les méthodes d'utilitaire Metrics.applySLO(final String metricName, final long[] slos) ou Metrics.applySLO(final String metricName, final String name) peuvent également être utilisées.

Exemple : Ajout d'un nouveau temporisateur dont les valeurs de libellés ne sont pas connues à l'avance
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 ); 

}
Jauges
Une jauge détient une valeur qui peut augmenter et diminuer au fil du temps. Le mètre est mappé à une fonction pour obtenir la valeur. Le nombre de sessions actives et la taille actuelle du cache en sont des exemples.
Exemple : Définition d'une jauge
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; 
 }
}