[Feature] Expose call metrics for the proxy admin gRPC interface

Đang mở
  • Có gì không ổn?
#11,474 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@Felix-Gong đang làm issue này rồi.

Từ ngày 21/10/2026.

  • #11475 của @Felix-Gong — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
54/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
grpc, java
Lĩnh vực
backend-api-design, observability

Hướng nghiên cứu

Start in the proxy module with ProxyAdminAuthInterceptor and ProxyMetricsManager, then read how the broker handles optional instruments and inspect the proxy tests. Add per-RPC counts and latency samples labeled by method and terminal status, including calls rejected by the interceptor; verify they export through the existing pipeline and become no-ops when metrics are unavailable.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Search before asking

I checked open and closed issues and PRs for proxy admin metrics, OpenTelemetry on the control plane and admin gRPC instrumentation. What exists is adjacent, not this:

  • #10901 / #10833 touch how metric config values are parsed (OTLP headers, colon-separated labels); #10950 masks them in config logs.
  • #10603 (RIP-2) adds its own ClientAdminMetricsRecorder for the new client-admin query endpoint — service-level instrumentation for code that does not exist on develop yet.
  • #10825 tracks the admin interface work in general.

Nothing records anything for the admin gRPC server that actually ships today: ProxyAdminAuthInterceptor answers every admin RPC (thread dumps, message verification, group resets, topic updates...) and rocketmq_proxy_up is the only proxy instrument in the pipeline.

What happened?

ProxyMetricsManager initializes an OpenTelemetry meter in both proxy modes and exports it (OTLP/Prometheus/log), but the only instrument it registers is the rocketmq_proxy_up gauge. The admin gRPC server — the control plane surface every ops tool talks to — contributes no counter, no latency histogram, no error count.

So on a running proxy you cannot answer: is the admin interface being called at all, which methods are hot, how long do admin calls take, and — the important one — is anything failing (auth rejections, broken forwards, internal errors) while the dashboard still shows a healthy rocketmq_proxy_up = 1.

Expected behavior

Each admin RPC should produce one count and one latency sample, labeled with the method name and terminal status code, exported through the proxy's existing OpenTelemetry pipeline alongside rocketmq_proxy_up. Calls rejected by the auth interceptor should be counted too (that is where failures would show up first), and everything should degrade to a no-op when metrics are disabled or the manager has not started — same idiom the broker uses for optional instruments.

Runtime

develop at 57c2dc0, JDK 11. No proto change, no new dependency: the interceptor, the two instruments and tests live entirely in proxy.

Ngôn ngữ chính
Java
Star
22.7k
Fork
12k
Merge trung bình
3 ngày 18 giờ
Pull request đã merge (30 ngày)
17

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/rocketmq

Tất cả issue của apache/rocketmq

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.