Monedula

Cette page a été traduite automatiquement depuis l’anglais. Lire l’original

monedula-metrics-reporter v0.10.0, AGPL-3.0

Métriques Kafka, directement vers OpenTelemetry

monedula-metrics-reporter s'exécute dans le broker et pousse les métriques via OTLP vers votre collector : les deux registres de métriques de Kafka, les métriques JVM et la télémétrie client KIP-714, avec l'identité du broker en labels. Si le collector disparaît, Kafka ne s'en aperçoit pas.

Maven Central 
VERSION=0.10.0
curl -L -o monedula-metrics-reporter-${VERSION}.jar \
  https://repo1.maven.org/maven2/dev/monedula/monedula-metrics-reporter/${VERSION}/monedula-metrics-reporter-${VERSION}.jar
GitHub Release 
VERSION=0.10.0
curl -L -o monedula-metrics-reporter-${VERSION}.jar \
  https://github.com/monedula-dev/monedula-metrics-reporter/releases/download/v${VERSION}/monedula-metrics-reporter-${VERSION}.jar
Lancer le quickstart (en anglais) GitHub
server.properties 
metric.reporters=dev.monedula.metricsreporter.OtlpMetricReporter

otlp.metric.reporter.endpoint=http://otel-collector:4317
otlp.metric.reporter.transport=grpc
terminal
cp monedula-metrics-reporter-0.10.0.jar $KAFKA_HOME/libs/# then add the lines above to server.properties# every series carries the broker's cluster and node IDs as resource attributes

Le problème

La plupart des métriques Kafka font un détour.

La stack habituelle attache un JMX exporter à chaque broker : il relit les métriques de Kafka dans les MBeans JMX, les mappe vers des noms de métriques avec des fichiers de règles, puis les expose pour un scrape ou les pousse vers un collector.

monedula-metrics-reporter se branche sur l'interface MetricsReporter de Kafka elle-même et parle OTLP directement au collector.

3
pipelines d'export : Kafka SPI et Yammer, runtime JVM et télémétrie client KIP-714
3.7 à 4.3
versions d'Apache Kafka testées pour la 0.10.0, sur JDK 17 et 21

Comment ça fonctionne

  1. Broker Kafka registres Kafka SPI et Yammer
    Clients KIP-714 les producteurs et les consommateurs poussent via le broker
  2. monedula-metrics-reporter dans le processus, asynchrone
  3. OpenTelemetry Collector OTLP via gRPC ou HTTP
  4. Prometheus, Grafana, tout backend OTLP le routage et le fan-out se font dans le collector
Les métriques passent de Kafka au reporter intégré au processus, puis à un OpenTelemetry Collector, qui les achemine vers n'importe quel backend.

Kafka continue de tourner quand le collector est en panne

Les callbacks de métriques ne font que mettre à jour une map en mémoire ; toutes les I/O réseau ont lieu sur un thread daemon. Il n'y a ni file de relance ni mémoire non bornée : un collector lent ou absent ne retarde donc jamais les requêtes produce ou fetch.

Comment fonctionne la conception fail-safe (en anglais)

  1. Collector injoignable
  2. L'appel d'export expire
  3. Lot abandonné, compté dans les métriques d'auto-surveillance
  4. Le tick suivant repart de zéro ; Kafka n'attend jamais

Métriques SPI et Yammer depuis un seul plugin

Les brokers Kafka exposent leurs métriques via deux systèmes parallèles. Plusieurs signaux du broker ne s'enregistrent que dans l'ancien registre Yammer, si bien qu'un reporter limité au SPI les manque. Ce plugin se branche sur les deux avec une seule configuration, et le même JAR fonctionne sans modification sur les clients.

  • UnderReplicatedPartitions
  • OfflinePartitionsCount
  • ActiveControllerCount
  • BrokerTopicMetrics par topic

KIP-714

Des métriques client sans toucher aux clients

Sur les brokers, le plugin reçoit aussi la télémétrie que poussent les clients KIP-714, comme la latence des requêtes côté client et la durée des rééquilibrages, et la transmet au même collector. Les séries client portent l'identité du broker et le client id, si bien qu'on peut les joindre aux séries broker dans PromQL.

Collecter les métriques client (en anglais)

Labels des métriques client transmises
kafka_cluster_id, kafka_node_idactivé par défaut
client_idactivé par défaut
client_instance_idopt-in, cardinalité élevée
principal et adresse du clientopt-in, données personnelles

Dashboards inclus

Le quickstart démarre Kafka, le reporter, un OpenTelemetry Collector, Prometheus et Grafana avec Docker Compose, avec des dashboards Grafana et des règles d'alerte Prometheus prêts à l'emploi.

Le quickstart Grafana (en anglais)

Dashboard Grafana de vue d'ensemble des métriques Kafka exportées par monedula-metrics-reporter

Installation

Maven Central 
VERSION=0.10.0
curl -L -o monedula-metrics-reporter-${VERSION}.jar \
  https://repo1.maven.org/maven2/dev/monedula/monedula-metrics-reporter/${VERSION}/monedula-metrics-reporter-${VERSION}.jar
GitHub Release 
VERSION=0.10.0
curl -L -o monedula-metrics-reporter-${VERSION}.jar \
  https://github.com/monedula-dev/monedula-metrics-reporter/releases/download/v${VERSION}/monedula-metrics-reporter-${VERSION}.jar

Coordonnées dev.monedula:monedula-metrics-reporter. Chaque release GitHub contient aussi le JAR, avec un SBOM CycloneDX et des signatures Sigstore.

Questions

monedula-metrics-reporter est-il gratuit, et puis-je l'utiliser au travail ?
Oui. Il est sous licence AGPL-3.0, sans édition payante, et l'exécuter dans vos propres brokers et clients ne vous oblige pas à partager votre code ni votre configuration : les obligations de l'AGPL s'appliquent lorsque vous le distribuez, modifié ou non, ou lorsque vous permettez à d'autres d'utiliser une version modifiée via un réseau.
Mes applications clientes doivent-elles être modifiées pour les métriques client ?
Non. Le push KIP-714 est actif par défaut dans le client Java et dans librdkafka 2.5 et versions ultérieures. Vous l'activez de façon centralisée avec un abonnement client-metrics côté broker, et le reporter transmet ce que les clients poussent. Voir collecter les métriques client (en anglais).
Ai-je besoin de Prometheus ?
Non. Le reporter parle OTLP à un OpenTelemetry Collector, et le collector peut exporter vers n'importe quel backend qu'il prend en charge. Le routage, le fan-out et les exporters des éditeurs se configurent dans le collector.
Quelles versions de Java et de Kafka sont prises en charge ?
Java 17 ou plus récent et Apache Kafka 3.7.0 à 4.3.0, sur les brokers comme sur les clients : pour la 0.10.0, la CI a testé JDK 17 et 21 avec Kafka 3.7.0, 3.9.0, 4.2.0 et 4.3.0. Les versions de Kafka antérieures à 3.7 n'ont pas l'interface ClientTelemetry que le plugin implémente et ne sont pas testées. Voir la compatibilité (en anglais).
En quoi est-il différent de jmx_exporter ?
Les deux peuvent s'exécuter dans la JVM Kafka. monedula-metrics-reporter n'a besoin d'aucun fichier de règles : il dérive les noms de ceux de Kafka, ajoute aux séries broker les ID de cluster et de nœud en labels, et transmet les métriques client KIP-714. La page de comparaison (en anglais) couvre les autres options.

Assistance

L’aide de ceux qui le développent

Nous pouvons vous aider à mettre en œuvre monedula-metrics-reporter sur un parc étendu, de la conception à l’exploitation au quotidien.

Parlons-en

Fait partie de
Monedula Flock

D’autres outils gratuits pour Apache Kafka, par la même équipe. À propos de Flock