OpenMetrics 2.0: option to keep _total and unit suffixes, so switching from OM1 doesn't rename series
Maintainer thường phản hồi trong vòng 1 ngày
Đá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
- 62/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- java
- Lĩnh vực
- observability-sre
Hướng nghiên cứu
Start with OpenMetrics2TextFormatWriter.java and OpenMetrics2Properties, then compare their behavior with the OM1 expositionBaseName logic. Review docs/content/exporters/openmetrics2.md for the current naming contract. Done means OM2 can preserve _total and unit suffixes for existing metrics, with a documented default or opt-out matching the chosen design.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
With io.prometheus.openmetrics2.enabled, the OM2 writer exposes names exactly as passed to the builder. It never appends _total or the unit suffix:
This is documented in https://github.com/prometheus/client_java/blob/9e9deb6b9e591c2a62b12882d8a987f120661b71/docs/content/exporters/openmetrics2.md#L57-L77, e.g. Counter("req").unit(BYTES) is req_bytes_total in OM1 but req in OM2.
The problem is that switching a target from OM1 to OM2 renames every counter, and every metric with a unit, that was instrumented the way client_java has always recommended (Counter.builder().name("events")). Prometheus then stores them as new series, so existing queries, dashboards and alerts silently stop matching.
[!NOTE]
I hit this with a demo that scrapes the same client_java app with OM1 and OM2 and diffs the stored series: the JVM metrics match (they already have the suffixes in their names), buthttp_requests_total(OM1) becamehttp_requests(OM2), andhttp_request_size_bytes_totalbecamehttp_request_size. Demo: https://35-204-166-191.sslip.io/, code: https://github.com/bwplotka/prometheus/pull/7.
The OM2 spec relaxed _total and the unit suffix from MUST to SHOULD, mainly for OpenTelemetry compatibility (https://github.com/prometheus/docs/blob/605cf81fefc2e8e91f8ba89bb1555ae52a43a318/docs/guides/open_metrics_2_0_migration.md?plain=1#L140). Both are still recommended though (https://github.com/prometheus/docs/blob/605cf81fefc2e8e91f8ba89bb1555ae52a43a318/docs/specs/om/open_metrics_spec_2_0.md?plain=1#L220 and https://github.com/prometheus/docs/blob/605cf81fefc2e8e91f8ba89bb1555ae52a43a318/docs/specs/om/open_metrics_spec_2_0.md?plain=1#L664). Today there is no way to get them in OM2 other than renaming every metric in code; OpenMetrics2Properties has no option for it.
Proposal:
- add a property, e.g.
io.prometheus.openmetrics2.suffixes(or a naming mode), that keeps the OM1 suffix behaviour in the OM2 writer: append_totalto counters and the unit suffix where missing, asexpositionBaseNamealready does for OM1. - I'd argue it should default to on, so that negotiating OM2 doesn't change any series names, and users who want names exactly as written (e.g. for OTel-style names) can opt out.
For comparison, client_golang keeps the names users register (which by convention include _total and the unit), so there OM1 and OM2 produce the same series.
- Ngôn ngữ chính
- Java
- Star
- 2.3k
- Fork
- 832
- Merge trung bình
- 1 ngày 9 giờ
- Pull request đã merge (30 ngày)
- 73
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của prometheus/client_java
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
prometheus/client_java#2416 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Switch Micrometer compatibility workflow to upstream once typed-descriptor path becomes defaultCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 86/100
prometheus/client_java#2182 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
prometheus/client_java#2306 · 10 bình luận · 4 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 32/100
prometheus/client_java#2084 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
prometheus/client_java#2075 · 10 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của prometheus/client_java
Issue tương tự
-
waiting-for-triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
spring-cloud/spring-cloud-openfeign#1443 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 84/100
ADORSYS-GIS/keycloak-oid4vp-plugin#221 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Upgrade to Spring Pulsar 2.0.8Đang mởstatus: team-only type: dependency-upgrade
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
spring-projects/spring-boot#52099 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
tchiotludo/akhq#3307 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
objectionary/jeo-maven-plugin#1885 ·
Maintainer thường phản hồi trong vòng 4 ngày