なぜ
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 のメトリクスはこんなに難しくなければならないのか？をお読みください。
設定
shadow jar を $KAFKA_HOME/libs/ に置き、server.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 が今日出力するメトリクスをカバーできます。