Pourquoi

Le chemin habituel pour l’observabilité de Kafka est un sidecar JMX exporter — un processus supplémentaire par broker, avec sa propre fenêtre de scrape, ses propres modes de défaillance, et un modèle de métriques qui ne correspond pas tout à fait à ce que parle le reste de la stack.

monedula-metrics-reporter supprime le sidecar. Il s’intègre à la propre interface MetricsReporter de Kafka et pousse les métriques directement vers un collector OpenTelemetry via OTLP — gRPC ou HTTP, à vous de choisir. Le contexte du broker (cluster id, node id) est attaché comme attributs de ressource, de sorte que le même flux de métriques fonctionne sur tous les brokers sans câblage par hôte.

Toutes les I/O d’export se produisent sur un thread daemon. Si le collector est lent ou indisponible, rien n’atteint les threads que Kafka utilise pour servir le trafic.

Pour le contexte complet — les deux systèmes de métriques cachés à l’intérieur de Kafka, pourquoi les dashboards Grafana importés affichent si souvent No Data, et comment l’OTLP natif démêle tout cela — lisez Les métriques Kafka doivent-elles vraiment être si compliquées ?.

Configurer

Déposez le shadow jar dans $KAFKA_HOME/libs/, puis dans server.properties :

metric.reporters=dev.monedula.metricsreporter.OtlpMetricReporter
otlp.metric.reporter.endpoint=http://otel-collector:4317
otlp.metric.reporter.transport=grpc

Le même plugin fonctionne sur les clients Kafka — enregistrez-le via metric.reporters dans la configuration du producer ou du consumer et vous obtenez le flux côté client correspondant dans le même collector.

Une stack de démo complète (broker + collector + Prometheus + Grafana) se trouve sous quickstart/ dans le dépôt.

Compatibilité

Kafka 3.x et 4.x. Java 17+. À la fois le SPI moderne MetricsReporter et l’ancien registre Yammer sont câblés, de sorte que vous obtenez une couverture des métriques que Kafka émet aujourd’hui sans laisser de côté celles de Yammer.