---
title: "monedula-metrics-reporter"
repo: https://github.com/monedula-dev/monedula-metrics-reporter
language: Java
license: AGPL-3.0
status: active
maintainers: ["grzegorz", "michal"]
---## なぜ

Kafka 可観測性の通常の道筋は JMX エクスポーターのサイドカーです——broker ごとの
追加プロセスで、独自のスクレイプウィンドウ、独自の障害モード、そしてスタックの
他の部分が話す言葉とは少しずれたメトリクスモデルを持ちます。

`monedula-metrics-reporter` はそのサイドカーを取り除きます。Kafka 自身の
`MetricsReporter` インターフェースに差し込み、メトリクスを OpenTelemetry
collector へ OTLP 経由で直接プッシュします——gRPC か HTTP か、あなた次第です。
broker のコンテキスト（クラスター ID、ノード ID）はリソース属性として
アタッチされるため、同じメトリクスストリームがホストごとの配線なしに
broker をまたいで機能します。

すべてのエクスポート I/O はデーモンスレッド上で発生します。collector が遅い、
あるいはダウンしていても、Kafka がトラフィックを処理するために使うスレッドには
何も届きません。

完全な背景——Kafka 内部に隠れた二つのメトリクスシステム、なぜインポートした
Grafana ダッシュボードがこれほど頻繁に *No Data* を表示するのか、そして
ネイティブな OTLP がそれをどう解きほぐすのか——については、[Kafka のメトリクスはこんなに難しくなければならないのか？](/blog/kafka-metrics-opentelemetry-otlp-monedula-metrics-reporter/)をお読みください。

## 設定

shadow jar を `$KAFKA_HOME/libs/` に置き、`server.properties` に次のように記述します。

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

同じプラグインが Kafka クライアントでも動作します——producer または consumer の
設定で `metric.reporters` を通じて登録すれば、対応するクライアント側のストリームが
同じ collector に流れ込みます。

完全なデモスタック（broker + collector + Prometheus + Grafana）はリポジトリの
`quickstart/` の下にあります。

## 互換性

Kafka 3.x および 4.x。Java 17 以上。最新の `MetricsReporter` SPI とレガシーの
Yammer レジストリの両方が配線されているため、Yammer 側を取りこぼすことなく、
Kafka が今日出力するメトリクスをカバーできます。