AlexStocks opened a new issue, #3568: URL: https://github.com/apache/dubbo-go/issues/3568
## Summary While reviewing dubbo-go's observability stack, I found that the three pillars — **Metrics**, **Tracing**, and **Logging** — are all implemented, but every one of them is **opt-in by default** and **not wired into the default filter chain**. As a result, a fresh dubbo-go application is effectively "blind" out of the box: no metrics endpoint, no traces, and logs are not correlated with trace IDs unless the user manually enables and wires everything together. This issue summarizes the current state, the concrete gaps, and a proposed roadmap. I'm happy to drive the implementation via PRs. ## Current state ### Metrics - Backend: **Prometheus only**. `metrics/api.go` registers a single registry (`prometheus`); the multi-backend `CompositeRegistry` is commented out. No OpenTelemetry Metrics backend. - Dimensions are rich: request count (success/fail/processing), QPS, RT with `p50/p90/p95/p99` quantiles, and error classification (`timeout` / `limit` / `service_unavailable` / `business` / `unknown`). - Decoupled via an event bus (`metrics/bus.go`): the `metrics` filter only publishes events; collection happens in a separate goroutine. Good design. - **Gap**: `MetricsConfig.Enable` defaults to `false`, and the `"metrics"` filter is **not** in `DefaultServiceFilters` / `DefaultReferenceFilters`, so the user must both flip the config *and* add `metrics` to the filter list. ### Tracing - Two implementations coexist: the **new OpenTelemetry** path (`otel/trace/` + `filter/otel/trace/`) and the **deprecated OpenTracing** path (`filter/tracing/`, default `NoopTracer`). The OpenTracing path is marked deprecated but still imported. - The OTel path is solid: exporters for `jaeger` / `zipkin` / `otlp-http` / `otlp-grpc` / `stdout`, W3C + B3 propagation, sampling (always/never/ratio, default 0.5). Cross-process propagation is done correctly via `Attachments` (`filter/otel/trace/attachment.go`). - **Gap**: `OtelConfig.TracingConfig.Enable` defaults to `false`, and `otelServerTrace` / `otelClientTrace` are **not** in the default filter chain. ### Logging - Unified facade with two drivers: **zap** (default) and **logrus**. Supports JSON structured output, log levels (dynamic), and `lumberjack` rotation (100MB / 5 backups / 3 days). - **Gap (weakest pillar)**: trace-ID injection into logs requires **three conditions simultaneously**: `LoggerConfig.TraceIntegration.Enabled` (default `false`) **AND** calling the `Ctx*` logger methods (plain `Info()` does not carry trace fields) **AND** an active OTel span in the context. Since OTel is off by default, logs and traces are decorrelated out of the box. There is no independent request-ID concept. ### Health probes - `metrics/probe/` implements liveness / readiness / startup endpoints (default port 22222) fully. - **Gap**: `ProbeConfig.Enabled` defaults to `false` — no health/readiness endpoint out of the box. ## Key problems to fix 1. **All observability filters are opt-in.** `common/constant/default.go` `DefaultServiceFilters` and `DefaultReferenceFilters` contain none of `metrics` / `otelServerTrace` / `otelClientTrace` / `tracing`. Users get nothing unless they manually wire filters. 2. **Logs are not correlated with traces by default**, and only via `Ctx*` methods. 3. **Metrics error classification only covers the triple/gRPC protocol.** `metrics/rpc/error_classifier.go`'s `classifyError` has `TODO: Support dubbo protocol error classification`; dubbo-protocol errors fall into `unknown`. 4. **Metrics backend is Prometheus-only** (no OTLP / multi-backend). 5. **Deprecated OpenTracing implementation still ships** and is imported, causing confusion. 6. **Health/readiness probes are off by default.** ## Proposed improvements (incremental, reviewable PRs) - [ ] Auto-inject `metrics` / `otelServerTrace` / `otelClientTrace` into the filter chain when the corresponding config is enabled (lowest-effort, highest-value). - [ ] Make log trace-ID injection work by default and also for the plain `Info()` path. - [ ] Implement dubbo-protocol error classification in `error_classifier.go` (resolve the TODO). - [ ] Add an OpenTelemetry Metrics backend / multi-backend support. - [ ] Enable health/readiness probes by default (or document a one-line enable). - [ ] Remove / clearly isolate the deprecated OpenTracing path. I can start with the auto-injection + dubbo error-classification fixes as the first PR. Feedback welcome on scope and default-on vs opt-in philosophy. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
