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.
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
EXPOSE_METRICS=trueLes 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()etincrease()qui peuvent être utilisées pour se protéger contre les réinitialisations de compteur. - 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'utilitaireMetrics.applySLO(final String metricName, final long[] slos)ouMetrics.applySLO(final String metricName, final String name)peuvent également être utilisées. - 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.