You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@dubbo.apache.org by "Tsukikage7 (via GitHub)" <gi...@apache.org> on 2026/07/28 10:52:55 UTC
[I] [EPIC] Complete dubbo-go observability implementation and end-to-end integration / 完整推进可观测性实现与闭环 [dubbo-go]
Tsukikage7 opened a new issue, #3562:
URL: https://github.com/apache/dubbo-go/issues/3562
**What would you like to be added**:
## Summary / 概要
I would like to volunteer to coordinate and implement most of the remaining work needed to complete dubbo-go observability across Metrics, OpenTelemetry Tracing, structured logging, metadata diagnostics, end-to-end samples/documentation, and integration with dubbo-admin.
我希望主推进 dubbo-go 剩余的大部分可观测性工作，包括统一语义、Metrics、OpenTelemetry Trace、结构化日志、Metadata 诊断、端到端 Samples/Docs，以及后续与 dubbo-admin 的联动。
This is an implementation and delivery plan under the existing observability umbrella issue #3292. It does not replace #3292, #3337, #3338, or #3356, and it does not take ownership away from contributors already working on open PRs. The purpose is to make the remaining scope explicit, coordinate parallel work, avoid duplicate code, and deliver an end-to-end operational experience.
## Relationship to existing work
| Area | Existing issue/PR | Current boundary |
| --- | --- | --- |
| Overall observability | #3292 | Existing umbrella and capability inventory; this issue proposes the complete execution plan. |
| Metrics | #3337 | Coordinate before implementing overlapping metric names or labels. |
| OpenTelemetry diagnostics | #3338 | Preserve assigned work and implement only agreed remaining parts. |
| OTel span names and base attributes | #3551 | Open PR by @jiaming2li; review and build on it instead of duplicating it. |
| Metadata observability | #3356 | Existing assigned issue; coordinate with its contributors. |
| Metadata mapping metrics/errors | #3463 | Open PR by @Rachit-Gandhi; review and build on it instead of duplicating it. |
| Community ownership context | Discussion #3534 and #3374 | Weekly notes list observability ownership and the plan to connect with Admin. |
| AI-ready observability | Discussion #3454 | Future extension; should not block the base observability closure. |
## Desired outcome
A user should be able to move through one coherent troubleshooting path:
```text
Prometheus/Grafana signal
-> affected service/method/error category
-> OpenTelemetry trace
-> correlated structured logs
-> RPC, registry, metadata, routing, retry, timeout, rejection, or codec root cause
```
The same operation or failure should use compatible semantics across Metrics, Trace, and Log. High-cardinality diagnostic context belongs in traces/logs, while Prometheus labels remain bounded and stable.
## Workstream 1: shared observability semantic contract
I would like to own the cross-signal contract and compatibility rules.
- [ ] Inventory existing metric names, labels, units, and cardinality.
- [ ] Inventory current span names, semantic attributes, events, error recording, and propagation.
- [ ] Inventory CtxLogger, zap, logrus, access-log, and trace-correlation behavior.
- [ ] Inventory metadata mapping/report/RPC/revision/cache/fallback diagnostic points.
- [ ] Publish a field mapping table for Metrics, Trace, Log, and Metadata.
- [ ] Define a shared error taxonomy: `error_type`, `error_code`, and `error_source`.
- [ ] Define low-cardinality and high-cardinality boundaries.
- [ ] Map standard fields to OpenTelemetry semantic conventions where available.
- [ ] Use a stable `dubbo.*` namespace only for Dubbo-specific trace attributes.
- [ ] Document backward-compatibility rules for existing metric names, configuration, and logger behavior.
Candidate shared dimensions:
- `application_name`, `application_version`
- `side`, `protocol`, `interface`, `method`, `group`, `version`
- `error_type`, `error_code`, `error_source`
- `metadata_operation`, `metadata_source`, `metadata_result`
- `metadata_storage_type`, `metadata_revision`, `service_key`, `registry_id`, `cache_hit`
`trace_id`, `span_id`, revision values, request IDs, full URLs, exception messages, payloads, and attachment values must not become default Prometheus labels.
## Workstream 2: shared RPC error taxonomy and structured logging
This is a candidate first implementation area because it can connect the existing signals without duplicating #3551 or #3463.
- [ ] Extract a stable error classification API from current RPC metrics logic.
- [ ] Cover timeout, cancellation, limit/rejection, service unavailable, business failure, network failure, codec/serialization failure, and unknown failure.
- [ ] Define structured mappings for Triple/gRPC and Dubbo protocol errors.
- [ ] Avoid independent error-string parsing in Metrics, Trace, and Log.
- [ ] Align zap and logrus structured fields.
- [ ] Verify `trace_id`, `span_id`, and `trace_flags` behavior in CtxLogger.
- [ ] Verify that trace integration does not break existing logger controls such as dynamic log-level updates.
- [ ] Align `record-error-to-span` with the shared error taxonomy.
## Workstream 3: Metrics completion and standardization
I would like to implement most of the remaining Metrics work after coordinating with the current contributors on #3337.
- [ ] Document built-in metric names, labels, units, and cardinality.
- [ ] Keep the existing metrics event bus and Prometheus adapter.
- [ ] Define a stable provider/consumer RED model.
- [ ] Extend RPC error classification to Dubbo protocol, network, and codec failures where possible.
- [ ] Classify registry, metadata, and config-center metrics into basic and detailed layers.
- [ ] Keep detailed/high-cardinality metrics opt-in.
- [ ] Verify Prometheus pull, Pushgateway push, graceful shutdown, and zombie-metric cleanup.
- [ ] Update PromQL examples and Grafana dashboards.
- [ ] Document compatibility impact for renamed or deprecated metrics.
Important open decision: the `side` label may duplicate information already encoded in metric names and can approximately double RPC time-series count. The contract should measure this cost before adding it by default, as already raised in #3337.
## Workstream 4: OpenTelemetry Trace completion
PR #3551 should remain the source of truth for its current span-name and base-attribute changes. I would like to implement or coordinate the remaining tracing work after it is reviewed/merged.
- [ ] Review #3551 against the shared semantic contract.
- [ ] Add stable `error_type`, `error_code`, and `error_source` attributes.
- [ ] Use `RecordError` and span status consistently.
- [ ] Add low-noise diagnostics for retries, timeouts, rejection, codec failures, registry lookups, and metadata failures.
- [ ] Add propagation tests for W3C Trace Context, B3, baggage, and Dubbo attachment carriers.
- [ ] Cover consumer-to-provider propagation for Triple and Dubbo protocol paths.
- [ ] Verify sampling and stdout/Jaeger/Zipkin/OTLP HTTP/OTLP gRPC exporters.
- [ ] Document the OpenTracing-to-Otel migration boundary.
Important open architecture decision from #3338: retry/load-balance/router selection currently occurs above the OTel filter span. We should agree whether to keep a single upper logical consumer span before implementing those diagnostic events, so we do not create incompatible span topology.
## Workstream 5: Metadata observability completion
PR #3463 should remain the source of truth for the metadata mapping metrics and MetadataError code it already implements. I would like to complete the remaining diagnostic path after coordinating with its contributors.
- [ ] Review #3463 against the shared operation/source/result/error contract.
- [ ] Cover mapping listen, revision calculation, cache hit/miss, and fallback.
- [ ] Cover metadata-report loading, RPC metadata loading, URL construction, and revision mismatch.
- [ ] Keep revision, service key, registry ID, and similar diagnostic values in Trace/Log by default.
- [ ] Keep Metrics limited to bounded operation/source/result/error dimensions.
- [ ] Add failure-path, fallback, cache, and concurrency tests.
This workstream does not include redesigning metadata lifecycle, revision algorithms, or mapping consistency.
## Workstream 6: end-to-end samples, documentation, and Admin integration
- [ ] Add a runnable end-to-end observability example in dubbo-go-samples.
- [ ] Demonstrate a Metrics -> Trace -> Log -> root-cause workflow.
- [ ] Provide Prometheus/Grafana and Jaeger/Tempo examples.
- [ ] Document Loki/Alloy-style log collection without coupling those backends to core.
- [ ] Define which stable metrics and diagnostic links dubbo-admin can consume.
- [ ] Coordinate trace deep links, log correlation, and metadata diagnostics with dubbo-admin.
- [ ] Keep AI-specific telemetry such as TTFT, stream chunk interval, token counts, fallback frequency, and cost attribution as a follow-up extension.
## Non-goals
- Replacing the metrics event bus with OpenTelemetry Metrics.
- Introducing OpenTelemetry Logs SDK into core.
- Hard-coding Grafana, Loki, Tempo, Jaeger, Alloy, or another backend into core.
- Redesigning metadata lifecycle or registry architecture.
- Adding unbounded values to default Prometheus labels.
- Reimplementing code already present in #3551 or #3463.
- Delivering all changes in one large PR.
## Collaboration and conflict-avoidance rules
- Before each implementation PR, check Apache main and all related open PRs again.
- List overlapping issues, PRs, files, and contributors in every implementation PR.
- Prefer reviewing or extending an existing PR when the same files and behavior are already being changed.
- After an upstream PR merges, synchronize main before continuing dependent work.
- Split work by independently reviewable concern.
- Keep code, tests, samples/docs, Admin integration, and release status separately verifiable.
- Do not claim existing assigned issues without confirmation from their current contributors and maintainers.
## Proposed PR sequence
1. Shared semantic contract and current-state audit.
2. Shared RPC error taxonomy.
3. Logger structured-field and correlation consistency.
4. Metrics names/labels/error-classification completion.
5. Trace error/events/propagation completion.
6. Remaining metadata observability path.
7. End-to-end Prometheus/Grafana -> Trace -> Log sample.
8. Admin integration contract and documentation.
The actual split should be adjusted after maintainers and the contributors on #3337, #3338/#3551, and #3356/#3463 confirm the boundaries.
## Acceptance criteria
- [ ] Maintainers and current contributors have confirmed the major ownership boundaries.
- [ ] A shared semantic contract is documented and reused by implementation code.
- [ ] Metrics, Trace, and Log do not maintain conflicting error taxonomies.
- [ ] Metrics names/labels/units/cardinality are documented and bounded.
- [ ] Trace behavior covers stable span semantics, error recording, diagnostic events, and propagation tests.
- [ ] Logger correlation is consistent across zap/logrus without breaking existing controls.
- [ ] Metadata mapping/report/RPC/revision/cache/fallback has a diagnosable path.
- [ ] At least one end-to-end Metrics -> Trace -> Log/Metadata troubleshooting scenario is verified.
- [ ] Compatibility and migration impact is documented.
- [ ] Changes are delivered through small, independently reviewable PRs with explicit tests.
## Request to maintainers and current contributors
I would like to take primary responsibility for coordinating and implementing most of the remaining work described above. Before coding overlapping areas, please help confirm:
1. Whether this execution plan is suitable as a meta issue under #3292.
2. Which remaining workstreams I can formally own.
3. Which parts should stay with the current assignees/contributors.
4. Whether the proposed Admin integration boundary belongs in this effort.
5. Whether the proposed PR sequence is appropriate.
Once the boundaries are confirmed, I will update this checklist with the agreed owners and start from the shared semantic contract and the first non-overlapping implementation slice.
**Why is this needed**:
dubbo-go already has substantial observability capabilities, but they are not yet expressed as one stable operational contract. Metrics, Trace, Log, and Metadata diagnostics can expose different dimensions and error semantics, making production troubleshooting harder and increasing the risk of high-cardinality metrics or incompatible follow-up implementations.
A coordinated implementation plan is needed to reuse the work already in progress, prevent duplicate PRs, keep compatibility visible, and deliver a complete troubleshooting workflow rather than isolated observability features.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [I] [EPIC] Complete dubbo-go observability implementation and end-to-end integration / 完整推进可观测性实现与闭环 [dubbo-go]
Posted by "Tsukikage7 (via GitHub)" <gi...@apache.org>.
Tsukikage7 commented on issue #3562:
URL: https://github.com/apache/dubbo-go/issues/3562#issuecomment-5165951800
## Workstream 6 progress: end-to-end sample PR
The end-to-end observability sample has now been implemented in a separate samples PR:
- PR: https://github.com/apache/dubbo-go-samples/pull/1128
- Scope: runnable Dubbo Triple consumer/provider sample, Nacos discovery, OpenTelemetry Collector and OTLP HTTP, Jaeger, Prometheus, Grafana, trace-correlated logs, deterministic business-error validation, and bilingual documentation.
- The PR description now contains the integration screenshots and the complete local validation flow.
This PR is intentionally limited to the `dubbo-go-samples` repository. It does not modify or reimplement the core observability semantics tracked by `#3337`, `#3338`, `#3356`, `#3551`, `#3463`, or `#3568`. The sample is an integration-validation and documentation slice for Workstream 6, not a replacement for those core implementation issues.
@Alanxtl @Saramanda9988 @jiaming2li @Modo-me @AlexStocks, please review the sample scope and call out any existing implementation, PR, branch, or sample that should be reused. In particular, please confirm that the telemetry validation flow and the documented ownership boundaries do not overlap with the current Metrics, Trace, Metadata, or protocol-error work.
I will keep the Workstream 6 checklist open until the maintainers and current contributors confirm the boundary and the sample PR is reviewed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [I] [EPIC] Complete dubbo-go observability implementation and end-to-end integration / 完整推进可观测性实现与闭环 [dubbo-go]
Posted by "Tsukikage7 (via GitHub)" <gi...@apache.org>.
Tsukikage7 commented on issue #3562:
URL: https://github.com/apache/dubbo-go/issues/3562#issuecomment-5131193627
@Alanxtl, after the recent coordination on #3338 and a new review of the currently active observability work, I would like to narrow my ownership proposal under #3562 so that I do not duplicate work already being implemented by other contributors.
## Work I would like to own
### 1. Shared observability semantic contract and current-state audit
I would like to take responsibility for Workstream 1, including:
- inventorying the existing Metrics, Trace, Log and Metadata semantics;
- defining the cross-signal mapping for stable fields such as `service`, `method`, `protocol`, `side`, `error_type`, `error_code` and `error_source`;
- defining low-cardinality and high-cardinality boundaries;
- documenting compatibility requirements for existing metrics, configuration and logger behavior;
- producing the shared test matrix and the file/owner overlap matrix for follow-up PRs.
This work will start as an audit and reviewable contract. It will not modify the implementation currently owned by #3337, #3338 or #3356.
### 2. Proposed shared RPC error-classification core
Subject to maintainer and current-contributor confirmation, I would also like to own the narrow cross-signal classification core from Workstream 2.
The goal would be a minimal typed classification result that can eventually be reused by Metrics, Trace and structured logging without each signal parsing error strings independently.
The first implementation would be constrained to:
- preserving the original error cause;
- using `errors.Is`, `errors.As` and typed protocol errors;
- covering cancellation, deadline exceeded and existing Triple/Dubbo structured error codes;
- safely falling back to `unknown` when no reliable structured code exists;
- adding table-driven and wrapped-error tests;
- integrating only with the first consumer explicitly agreed by the relevant owner.
I will not submit an unused abstraction package with no real consumer.
## Explicit non-overlap boundaries
- #3338 and PR #3551 remain with @jiaming2li and the existing assignees. I will not implement Trace span lifecycle, diagnostic events, propagation or Trace-specific error attributes.
- #3337 remains with its current owner. I will not change metric names, labels, counters, dashboards or cardinality behavior without agreement.
- #3356 and PR #3463 remain with their current contributors. I will not implement or replace `MetadataError` or metadata metrics.
- I will not take the filter auto-injection/default-on work proposed in #3568.
- I will not create a parallel implementation of the existing dubbo-admin PromQL/trace-diagnosis work.
## Coordination questions
@Saramanda9988, are you already changing `metrics/rpc/error_classifier.go` as part of #3337? If not, would you be comfortable with the current Metrics classifier becoming the first consumer of a shared classification core, while all metric names, labels and collection behavior remain under #3337?
@AlexStocks @Modo-me, #3568 also proposes Dubbo protocol error classification. If that implementation is already planned or in progress, please let me know and I will not duplicate it. If useful, a possible boundary would be:
- shared protocol-neutral classifier core under #3562;
- Metrics/default-filter wiring and the #3568-specific integration under #3568.
@Alanxtl, could you please confirm whether this ownership split is appropriate, and where the shared classification API should live?
Until these boundaries are confirmed, I will only continue the audit/semantic-contract work and will not start implementation code.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [I] [EPIC] Complete dubbo-go observability implementation and end-to-end integration / 完整推进可观测性实现与闭环 [dubbo-go]
Posted by "Alanxtl (via GitHub)" <gi...@apache.org>.
Alanxtl commented on issue #3562:
URL: https://github.com/apache/dubbo-go/issues/3562#issuecomment-5138945043
@Tsukikage7 cool plan,
@Saramanda9988 @Modo-me @jiaming2li , please check this and avoid conflict
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [I] [EPIC] Complete dubbo-go observability implementation and end-to-end integration / 完整推进可观测性实现与闭环 [dubbo-go]
Posted by "dodjdnh (via GitHub)" <gi...@apache.org>.
dodjdnh commented on issue #3562:
URL: https://github.com/apache/dubbo-go/issues/3562#issuecomment-5598910584
---
@AsperforMias Hi,关于 Dubbo Admin 和 dubbo-go #3562 的可观测性对齐，以下是目前需要确认的契约。
目标不是要求 dubbo-go 照搬 Dubbo Java 实现，而是以 **Dubbo Java 当前已被 Admin 使用的字段为兼容基线**，让 Java / Go 的 Metric、Trace、Log 能被 Admin 用统一逻辑消费。以不阻碍于dubbo-java的原则，现只做 **Trace → Metric、Trace → Log、Log → Trace**。
清单状态说明：
- [x] 已实现，当前不需要修改
- [ ] 尚未实现、需要修改或需要补充材料
- [/] 第一期暂不修改或不属于 dubbo-go 的修改范围
### 1. 第一阶段希望对齐的核心字段
- [x] **应用名**
- Dubbo Java：Metric 使用 `application_name`，Trace 使用 `service.name`。
- dubbo-go：当前同样已有 `application_name` 和 `service.name`。
- 最终保证：`service.name == application_name`，值都为 Dubbo application name。
- [ ] **服务接口**
- Dubbo Java：Metric 使用 `interface`；Trace 的 `rpc.service` 为接口全限定名。
- dubbo-go：Metric 已有 `interface`；Trace 的 `rpc.service` 当前使用 `ServiceKey()`，可能是 `group/interface:version`。
- 需要修改：**`rpc.service` 改为纯接口全限定名，与 `interface` 一致。**
- [x] **方法**
- Dubbo Java：Metric 使用 `method`；Trace 使用 `rpc.method`。
- dubbo-go：当前同样已有 `method` 和 `rpc.method`。
- 最终保证：两者值可以直接匹配。
- [x] **调用侧**
- Dubbo Java：Metric 使用 `dubbo_provider_*` / `dubbo_consumer_*`；Trace 使用 `SERVER` / `CLIENT`。
- dubbo-go：当前已经一致。
- 最终保证：`SERVER → provider`，`CLIENT → consumer`。
- [x] **实例**
- Dubbo Java：Metric 使用 `ip`、`hostname`。
- dubbo-go：Metric 当前已有 `ip`、`hostname`。
- 最终保证：保持现有字段；Admin 实例查询优先使用 Metric 的 `ip`。
- [ ] **Group / Version 不再混入 `rpc.service`**
- Dubbo Java：Metric 使用 `group`、`version`；但Java Trace 不保证一定能找到 group 和 version 这两个字段。
- dubbo-go：Metric 已有 `group`、`version`；但 Trace 目前可能通过 ServiceKey() 把它们一起塞进 rpc.service。
- 需要修改：rpc.service 只保留接口全限定名，group/version 不再混进去；第一阶段不要求 Trace 单独新增这两个字段。
- [/] **Trace 单独增加 Group / Version 属性**
- 第一期不强制 dubbo-go 新增独立 Trace 属性。
- 当前由 Admin 从应用、实例或服务页面上下文补充。
- [x] **Trace ID / Span ID 日志字段**
- Dubbo Java：日志 MDC 常见字段为 `traceId`、`spanId`。
- dubbo-go：Zap/Logrus Context Logger 已注入 `trace_id`、`span_id`、`trace_flags`。
- 最终保证：Go 保持现有字段；Admin 同时兼容 Java/Go 两种写法。
- [x] **RPC system**
- Dubbo Java：`rpc.system=apache_dubbo`。
- dubbo-go：当前同样为 `rpc.system=apache_dubbo`。
- 最终保证：保持标准值 `apache_dubbo`。
其中目前**最明确需要 dubbo-go 修改的点只有一个核心问题**：
```text
当前可能：
rpc.service = gray/org.apache.dubbo.samples.OrderService:1.0.0
希望：
rpc.service = org.apache.dubbo.samples.OrderService
```
因为 Admin 要直接做：
```text
Trace rpc.service
↓
Metric interface
```
如果 `group/version` 混在 `rpc.service` 里，就无法稳定匹配。
- [/] **Span 名称改为 `接口全限定名/方法名`**
- dubbo-go 当前主要使用单独的方法名。
- 改名主要用于提升 Jaeger/Tempo 的阅读体验，不影响 Admin 依据 `rpc.service`、`rpc.method` 做字段映射，因此第一期暂不强制修改。
```
请参考 Dubbo Java 的 AbstractDefaultDubboObservationConvention 对齐 Trace 中 rpc.service 的语义。
Dubbo Java 最终写入 rpc.service 的是纯接口全限定名；Dubbo-go 当前在 Server 和 Client Trace Filter 中使用 invoker.GetURL().ServiceKey()，可能产生 group/interface:version，无法直接匹配 Dubbo Metric 的 interface Label。
建议只修改 filter/otel/trace/filter.go 中 rpc.service 的取值逻辑，从 URL 的 interface 参数获取接口全限定名，并保留 Path fallback。请不要修改公共的 URL.ServiceKey()，因为注册和路由仍然需要组合服务键。
同时请补充 Provider/Consumer 测试，验证带 group/version 时，最终 Span 仍满足：
rpc.service == Metric interface。
Span 名称本期不要求修改。
```
PR #3551 (draft) 已提出独立的 dubbo.group / dubbo.version；Admin P0 不依赖它们，但 group/version 不应继续混入 rpc.service
### 2. 希望 dubbo-go 侧提供的交付材料
如果当前代码已经满足，不需要重新实现，只需要给出真实可复现证据。以下是尚待提供的材料：
- [ ] **字段契约确认**：确认上述 Metric Label、Trace 属性、SpanKind、Log Trace 字段是否作为稳定契约。
- [ ] **Metric 样本**：提供一份真实 `/metrics` 输出，例如 `metrics.prom`。
- [ ] **Trace 样本**：提供同一次 RPC 的 Provider / Consumer Span，各一份。
- [ ] **Log 样本**：提供一份带 `trace_id` 的日志，以及一份正常无 Trace ID 的普通日志。
- [ ] **可运行配置**：提供开启 Prometheus Metric、OTel Trace、JSON Log / Context Logger 的配置。
- [ ] **对齐测试**：至少覆盖 Provider、Consumer、带 `group/version` 的服务，确保 group/version 不会再串入 `rpc.service`。
- [ ] **README**：写明启动服务 → 发起 RPC → 查 `/metrics` → 查 Trace → 用 Trace ID 查日志的完整步骤。
建议最终提供以下文件：
- [ ] `README.md`
- [ ] `config.yaml`
- [ ] `metrics.prom`
- [ ] `trace-provider.json`
- [ ] `trace-consumer.json`
- [ ] `logs-with-trace.jsonl`
- [ ] `logs-without-trace.jsonl`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [I] [EPIC] Complete dubbo-go observability implementation and end-to-end integration / 完整推进可观测性实现与闭环 [dubbo-go]
Posted by "AsperforMias (via GitHub)" <gi...@apache.org>.
AsperforMias commented on issue #3562:
URL: https://github.com/apache/dubbo-go/issues/3562#issuecomment-5742003728
@dodjdnh hello老师，你要的第一期内容ok（有部分你之前自己的pr改了，在rpc service的trace契约那里，变更为纯借口名），现在rpc.service 不带 group/version，等 #3743 merge后我再去做后面的
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org