[dodjdnh]

Summary

Add Application / Instance log entries to Dubbo Admin, supporting logs stored in Loki or Elasticsearch through Grafana and manual Trace ID searches for related logs within the log page. Provide four log dashboards and Kubernetes automatic loading configuration, plus a field contract, Collector examples, and an ES index template reference for the external collection pipeline.

This PR uses a connect-only model: Admin owns the entries and dashboard URLs, Grafana owns log queries, and deployers supply log storage, datasources, and collectors.

Motivation

Upstream already has Metric / Trace entries but lacks corresponding Application / Instance log pages. When troubleshooting application or instance problems, users need to locate the data in an external log system instead of reusing the application and instance identity selected in Admin.

This PR adds the first-stage log-viewing capability and supports Loki and Elasticsearch through shared parameters and a field contract, avoiding two separate sets of provider-specific logic in Admin.

Changes

1. Application and Instance Log Entries

• The Application log page filters by application name; the Instance log page filters by application name and bare Pod IP, without a QoS port.
• The backend returns a Grafana fullURL. It does not return log records, connect directly to Loki / Elasticsearch, or perform HTTP redirects.
• Both log backends reuse the same Vue pages and backend APIs. Dashboard URLs are selected through console.logDashboards, without provider checks.
• Preserve existing var-application behavior and add var-applicationRaw. Existing regex escaping for Application Log remains unchanged, while ES uses the actual raw application name for exact matching.

2. Manual Trace ID Search on the Log Page

• A shared Vue search component validates complete 16- or 32-character hexadecimal Trace IDs.
• The backend queries Jaeger for the earliest valid Span start time in the corresponding trace and converts microseconds to milliseconds. The frontend derives T±5 minutes and then requests a trace-focused log dashboard URL.
• Manual search does not retain the current instance filter; it searches logs by Trace ID and time range. It reuses the Application log dashboard instead of adding a third Trace log dashboard.
• Distinguish invalid input, a missing trace or invalid start time, missing or unavailable Jaeger configuration, and an unconfigured or unavailable log dashboard. Hide previous results on failure.
• Request-version checks prevent late responses from the initial log dashboard request from overwriting manual search results.

New protected GET APIs:

API	Behavior
/api/v1/application/log-dashboard	Return an application log dashboard URL
/api/v1/instance/log-dashboard	Return an instance log dashboard URL
/api/v1/trace/start-time	Return the Trace ID and start time
/api/v1/trace/log-dashboard	Validate the Trace ID and millisecond time range, then return a trace-focused log dashboard URL

3. Loki / ES Dashboards and Deployment Integration

• Provide Application and Instance dashboards for each backend, displaying Time | Level | Pod | Trace ID | Message.
• Loki uses the app index label and pod_ip structured metadata. Trace IDs may come from structured fields or the log body, with complete 16- or 32-character IDs extracted.
• ES uses a raw-mapping contract: @timestamp, the original Body, and top-level LogRecord attributes. Application, instance, and trace queries use the corresponding .keyword fields, without scanning Body for Trace IDs or using an ECS adapter.
• Table handling covers missing log levels, Pod-name fallback, and null Trace IDs. No Log → Trace Data Link is added.
• ConfigMaps and mounts allow the existing Grafana Dashboard provider to load all four dashboards. Default Admin URLs still select Loki; switching to ES requires replacing all three application, instance, and trace URLs.
• Deployers still configure external Grafana Loki / ES datasources; this PR does not register them automatically.

4. Shared Fixes and Integration Examples

• Copy configured URLs when generating dashboard URLs so requests do not mutate shared parameters.
• Stabilize container sizing and kiosk embedding for the shared Grafana iframe; these display changes also affect Metric / Trace pages.
• Provide Loki / ES reference configurations for OTel Collector Contrib 0.112.0, explaining log-file reading, Pod identity enrichment, field parsing, permissions, and preservation of the original body.
• Provide an optional ES composable index template with the required .keyword fields. It is a manual-installation example only and does not automatically create indices, alter existing indices, or overwrite production templates.

Verification

Local unit tests, builds, and static checks are complete. Runtime and browser acceptance were manually verified by the author, who confirmed on 2026-10-06 that all checks below passed. These manual acceptance results are not browser automation results.

Area	Check	Result
Unit	Relevant Go tests in service, handler, and config/console; config/observability has no test files	Complete (PASS)
Unit	Full Vue suite: 10 test files, 30 tests, using --hookTimeout 60000	Complete (PASS)
Unit	Frontend log feature checkpoint: 18 relevant tests	Complete (PASS)
Build	go build ./...; relevant Go tests and builds at all eight commit checkpoints	Complete (PASS)
Build	Vite production build, without running the formatter that rewrites source files	Complete (build succeeded with warnings)
Static	YAML / Dashboard JSON, four dashboards, five-column definitions, ConfigMap mounts, and datasource variables	Complete (PASS)
Static	Collector raw mapping, ES template JSON, .keyword contract, and documentation links	Complete (PASS)
Static	git diff --check	Complete (PASS)
Regression	Log dashboards match the original log implementation; existing upstream dashboard definitions and instance Metric parameter generation are unchanged	Complete (code / static checks passed)
Regression	No pending Instance Trace fixes, Trace Collector / Shop deployment changes, Trace→Metric, or Metric compatibility files included	Complete (diff checks passed)
Runtime	Real Loki / ES log collection, application A+B aggregation, and bidirectional instance A/B isolation	Complete (manual verification passed)
Runtime	Original Message, actual five-column display, missing-field fallbacks, and complete Trace IDs	Complete (manual verification passed)
Runtime	Real Jaeger trace → manual search on the log page, T±5-minute range, and error states	Complete (manual verification passed)
Runtime	ES index template installation, simulation, and actual index field checks	Complete (manual verification passed)
Browser / Regression	Admin → Grafana log pages and existing Metric / Trace browser behavior	Complete (manual verification passed)

Review Focus

1. Whether shared log parameters satisfy both Loki regex semantics and ES exact matching; whether the raw application-name extension remains provider-neutral and instance identity matches the bare Pod IP known to Admin.
2. Whether the application / instance branch and Trace ID OR branch in ES queries switch correctly: the default .* for an inactive variable is not “match all” in a quoted keyword query and must not be interpreted as a Loki regex. Focus on query scope and branch-switching semantics.
3. Whether five-column transformations, complete Trace IDs, missing-field fallbacks, and the original Message match real Grafana data-frame behavior; whether the Loki structured-metadata and ES raw-mapping contracts are clear.
4. Whether Jaeger start-time lookup, T±5 minutes, backend time-range validation, search failures, and late responses are handled accurately. This is manual search on the log page, not automatic navigation from a Trace page.
5. The impact of shared URL / iframe fixes on existing Metric / Trace behavior, and the boundaries between provisioning and external datasources, Collectors, and ES templates.

Compatibility / Impact

• No Loki / ES-specific Admin branches are added, and existing Metric / Trace APIs or dashboard query definitions are not replaced.
• Instance Log uses a bare IP. Existing upstream Instance Metric / Trace parameter generation remains unchanged, and pending Instance Trace fixes are not included.
• var-applicationRaw is additive; existing log application parameters are unchanged. Manual trace search still uses wildcard application / instance parameters without a raw application parameter.
• Ordinary log viewing does not depend on Jaeger; manual Trace ID search requires a reachable Jaeger query endpoint.
• Requests no longer mutate shared URLs. Shared iframe display behavior changes, so not all Metric / Trace behavior can be described as completely unaffected. Browser regression in this verification environment was manually verified by the author and passed.
• Grafana 12.1.0 is the current dashboard verification version. ES 8.18.0, Loki 3.4.2, and OTel Collector Contrib 0.112.0 are reference integration versions, not a claim that every version combination has been verified.
• Admin iframe URLs must be reachable from the user's browser. Default .svc example addresses do not guarantee browser access outside the cluster.

Affected areas (matching the repository PR template):

• Docs
• Installation
• User Experience
• Dubboctl
• Console
• Core Component

Scope

Included

• Application / Instance log viewing and manual Trace ID search on the log page.
• Loki / ES dashboards, automatic dashboard loading, Admin URL configuration, and related shared fixes.
• The collection field contract and reference documentation for Collectors and the ES index template.

Not Included

• Service-, namespace-, or cluster-level log views.
• Click-through navigation from a Trace page to Log, Log → Trace navigation, or Trace → Metric.
• dubbo-go Metric compatibility or Dubbo SDK metric feature changes.
• Automatic deployment of log storage, production log collectors, Grafana log datasources, or ES index templates.
• ECS adaptation, full-text Body scanning for Trace IDs, or ES provider-specific backend logic.

Related Issue

Fixes #1586

Dependency

Built on the Service Trace parameter and Kubernetes dashboard provisioning changes already merged into develop (#1569 and #1573). This PR does not depend on the pending Instance Trace bare-IP / Kubernetes Pod-identity PRs: instance lookup and test helpers for the log backend are self-contained.

[robocanic]

Thanks for the contribution — the connect-only design is clean, CI is green, and Go/frontend tests are included. Approving with a few comments; items 1–2 are worth addressing before merge.

Good

• Added the missing return after the grafanaDashboards == nil check in GetGrafanaDashboard.
• concatURLWithQueryVars now copies the *url.URL instead of mutating the shared config URL (real bug fix, covered by a concurrency test).
• Trace ID is validated on both backend and frontend; the 10-minute range cap matches the frontend T±5min.

Suggestions

1. Trace ID comparison (service/trace.go): EqualFold(result.Data[0].TraceID, traceID) can false-positive as "different trace id". Jaeger v1 returns a 16-char ID when the high 64 bits are 0, and Jaeger v2 may zero-pad a 16-char ID to 32. Please normalize (trim or pad leading zeros) before comparing, and add a test.
2. Unbounded response body: io.ReadAll(resp.Body) has no limit; please use io.LimitReader. Also consider reusing a package-level http.Client instead of creating one per request.
3. var-application escaping is inconsistent: Application log sends a regex-quoted value (used with ${application:raw}), while Instance log sends the raw name (used with ${application:regex}). Both work, but the contract is implicit; please document it or unify.
4. GrafanaDashboardConfig.Trace is only meaningful for logDashboards, yet it lives in the shared struct, and the default config points it at the same URL as application. Consider warning in Validate() for non-log configs, or reusing Application for trace mode.
5. GrafanaPage.vue rewrite affects existing Metric/Trace pages (iframe DOM manipulation removed, kiosk=1 forced when absent). Direction is fine, but please call it out in the PR description, ideally split it out or add regression screenshots.
6. ES queries: app.keyword:"${applicationRaw:raw}" breaks if the app name contains " or \; consider escaping in the backend or documenting the limitation. In trace mode var-applicationRaw is not sent, so the query relies on the OR trace_id branch — a short comment would help.
7. Nits: ui-vue3/src/api/service/trace.ts lacks the ASF license header; app/dubbo-admin/dubbo-admin.yaml doesn't get the new jaeger / logDashboards examples; frontend error messages are hard-coded English although i18n entries were added; the baseURL == nil check for the trace log dashboard is duplicated in handler and service.

[robocanic]

审查意见

整体实现比较完整：新路由都挂在 protected 下；GetTraceStartTime 只接受 16/32 位十六进制 Trace ID 且 Jaeger 地址来自配置，没有 SSRF 风险；concatURLWithQueryVars 改为复制 url.URL 避免修改共享配置，GetGrafanaDashboard 补上缺失的 return 也修复了配置缺失时的空指针。我在 PR head 上跑了 go test ./pkg/console/service/... ./pkg/config/...，均通过。以下是几点需要关注的问题：

1. Trace ID 大小写未规范化，ES 面板会查不到日志

• pkg/console/service/trace.go（GetTraceStartTime 返回的 TraceStartTimeResp.TraceID）与 pkg/console/service/observability.go（GetTraceLogDashboard 的 var-traceId）都原样透传用户输入的大小写；前端又用后端返回的 traceId 构造请求。
• Loki 面板使用 (?i) 做不区分大小写匹配，而 ES 面板使用 trace_id.keyword:"${traceId:raw}"，.keyword 是区分大小写的精确匹配。用户粘贴大写形式的 Trace ID（traceIDPattern 与前端 isValidTraceId 都允许）时，Jaeger 能查到、Loki 能查到，但 ES 日志页会静默返回空结果，且没有任何错误提示。
• 建议：在 GetTraceStartTime 与 GetTraceLogDashboard 中统一 strings.ToLower 后再返回 / 拼接 URL，并在 trace_test.go、observability_test.go 中补一个大写输入的用例。

2. handler 层改动缺少测试

• pkg/console/handler/observability.go：新增的 LogDashboard 分支（应用 / 实例走 GetApplicationLogDashboard / GetInstanceLogDashboard）、GetTraceStartTime、GetTraceLogDashboard，以及配置缺失时新增的 return（此前会继续往下执行并解引用 nil 的 grafanaDashboards）都没有 handler 级测试。PR 描述中“Relevant Go tests in service, handler, and config/console”与实际不符——本 PR 没有改动任何 pkg/console/handler/*_test.go，该包现有测试（auth_test.go、rule_version_test.go）也与这些改动无关。
• 建议至少补：logDashboards 未配置时返回 NotFoundError 且不 panic；/trace/log-dashboard 在 logDashboards.trace 未配置时的行为。

[dodjdnh]

审查意见

整体实现比较完整：新路由都挂在 protected 下；GetTraceStartTime 只接受 16/32 位十六进制 Trace ID 且 Jaeger 地址来自配置，没有 SSRF 风险；concatURLWithQueryVars 改为复制 url.URL 避免修改共享配置，GetGrafanaDashboard 补上缺失的 return 也修复了配置缺失时的空指针。我在 PR head 上跑了 go test ./pkg/console/service/... ./pkg/config/...，均通过。以下是几点需要关注的问题：

1. Trace ID 大小写未规范化，ES 面板会查不到日志

• pkg/console/service/trace.go（GetTraceStartTime 返回的 TraceStartTimeResp.TraceID）与 pkg/console/service/observability.go（GetTraceLogDashboard 的 var-traceId）都原样透传用户输入的大小写；前端又用后端返回的 traceId 构造请求。
• Loki 面板使用 (?i) 做不区分大小写匹配，而 ES 面板使用 trace_id.keyword:"${traceId:raw}"，.keyword 是区分大小写的精确匹配。用户粘贴大写形式的 Trace ID（traceIDPattern 与前端 isValidTraceId 都允许）时，Jaeger 能查到、Loki 能查到，但 ES 日志页会静默返回空结果，且没有任何错误提示。
• 建议：在 GetTraceStartTime 与 GetTraceLogDashboard 中统一 strings.ToLower 后再返回 / 拼接 URL，并在 trace_test.go、observability_test.go 中补一个大写输入的用例。

2. handler 层改动缺少测试

• pkg/console/handler/observability.go：新增的 LogDashboard 分支（应用 / 实例走 GetApplicationLogDashboard / GetInstanceLogDashboard）、GetTraceStartTime、GetTraceLogDashboard，以及配置缺失时新增的 return（此前会继续往下执行并解引用 nil 的 grafanaDashboards）都没有 handler 级测试。PR 描述中“Relevant Go tests in service, handler, and config/console”与实际不符——本 PR 没有改动任何 pkg/console/handler/*_test.go，该包现有测试（auth_test.go、rule_version_test.go）也与这些改动无关。
• 建议至少补：logDashboards 未配置时返回 NotFoundError 且不 panic；/trace/log-dashboard 在 logDashboards.trace 未配置时的行为。

明白

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[dodjdnh]

Commit ebf1684（前）和Commit 2eb12a5（后）的体系结构

[dodjdnh]

e2e测试
1.es log正常工作

2.实例A/B隔离

3.message可以显示完整内容，但等级有时难以捕获，属于设计已知的问题

[dodjdnh]

4.traceid搜索成功

5.traceid大小写兼容搜索成功

6.非法traceid拒绝

7.位数符合但是不存在

8.存在trace，但是日志不带有

[dodjdnh]

9.loki日志功能正常

10.loki instance A/B隔离

11.Loki 和 Elasticsearch 的日志字段处理方式不同，loki默认显示pod_name，es显示pod_ip，但loki也存有pod_ip字段

[AlexStocks]

结论：可以合入，修掉一处数据竞争是本 PR 的额外收益

37 个文件，changed_files=37 与 Diff 一致；Go 侧改动集中在可观测性配置与 dashboard URL 生成，UI 侧新增日志页签与 Trace ID 搜索。

做得好的地方

• concatURLWithQueryVars 现在复制 *url.URL 再改 RawQuery。原实现直接修改配置里的 baseURL，在并发请求下是对共享配置对象的写竞争；这个修复虽然没有写在 PR 标题里，但价值很高。
• GetGrafanaDashboard 在 grafanaDashboards == nil 之后补了 return。原代码只写了错误响应却继续往下走，会拿 nil 指针继续拼 URL。
• GetTraceStartTime 的安全边界比较完整：Trace ID 限定 16/32 位十六进制、Jaeger 响应限制 16 MiB、客户端 5s 超时、校验返回的 Trace ID 与请求一致、earliest/1000 正确完成微秒到毫秒的换算。fmt.Sprintf("%032s", ...) 的补零对比我单独验证过，确实按零填充（[%032s] → 000…abc123），16 位与 32 位 ID 的等价判断成立。

已核对的转义设计

GetApplicationLogDashboard 对应用名做 regexp.QuoteMeta 后再 strconv.Quote 并去掉外层引号，结果是 shop.user → shop\.user（经过 JSON 解码后是 shop\\.user）。这个双重转义不是 bug：仪表盘里 ${application:raw} 位于 LogQL 双引号字符串内，字符串层先消费一个反斜杠，正则层再消费第二个，最终匹配字面量点号。文档里对这条契约写得很清楚，测试也断言了 shop\\.user。

P3 · Trace 搜索只有单元测试

GetTraceStartTime / GetTraceLogDashboard 的测试走 httptest，覆盖了状态码、超大响应、Trace ID 不匹配等分支，这部分很好；但没有对着真实 Jaeger 的 16 位 ID 返回做一次验证。文档里提到的「zero-padded 32 位与 16 位等价」属于 Jaeger 侧行为，建议在验收记录里补一条真实查询结果。

P3 · GetApplicationLogDashboard 未校验空应用名

req.AppName 为空时会生成 var-application=""，最终是空面板。既有 GetAppDashboard 也没有校验，属于一致行为，可以不改；如果要改，建议两个入口一起加。

P3 · 时间范围校验不检查上界

GetTraceLogDashboard 校验了 to > from 和跨度 ≤ 10 分钟，但没有拒绝明显在未来的 to。Grafana 会自行处理，影响很小，记录一下。

[dodjdnh]

结论：可以合入，修掉一处数据竞争是本 PR 的额外收益

37 个文件，changed_files=37 与 Diff 一致；Go 侧改动集中在可观测性配置与 dashboard URL 生成，UI 侧新增日志页签与 Trace ID 搜索。

做得好的地方

• concatURLWithQueryVars 现在复制 *url.URL 再改 RawQuery。原实现直接修改配置里的 baseURL，在并发请求下是对共享配置对象的写竞争；这个修复虽然没有写在 PR 标题里，但价值很高。
• GetGrafanaDashboard 在 grafanaDashboards == nil 之后补了 return。原代码只写了错误响应却继续往下走，会拿 nil 指针继续拼 URL。
• GetTraceStartTime 的安全边界比较完整：Trace ID 限定 16/32 位十六进制、Jaeger 响应限制 16 MiB、客户端 5s 超时、校验返回的 Trace ID 与请求一致、earliest/1000 正确完成微秒到毫秒的换算。fmt.Sprintf("%032s", ...) 的补零对比我单独验证过，确实按零填充（[%032s] → 000…abc123），16 位与 32 位 ID 的等价判断成立。

已核对的转义设计

GetApplicationLogDashboard 对应用名做 regexp.QuoteMeta 后再 strconv.Quote 并去掉外层引号，结果是 shop.user → shop\.user（经过 JSON 解码后是 shop\\.user）。这个双重转义不是 bug：仪表盘里 ${application:raw} 位于 LogQL 双引号字符串内，字符串层先消费一个反斜杠，正则层再消费第二个，最终匹配字面量点号。文档里对这条契约写得很清楚，测试也断言了 shop\\.user。

P3 · Trace 搜索只有单元测试

GetTraceStartTime / GetTraceLogDashboard 的测试走 httptest，覆盖了状态码、超大响应、Trace ID 不匹配等分支，这部分很好；但没有对着真实 Jaeger 的 16 位 ID 返回做一次验证。文档里提到的「zero-padded 32 位与 16 位等价」属于 Jaeger 侧行为，建议在验收记录里补一条真实查询结果。

P3 · GetApplicationLogDashboard 未校验空应用名

req.AppName 为空时会生成 var-application=""，最终是空面板。既有 GetAppDashboard 也没有校验，属于一致行为，可以不改；如果要改，建议两个入口一起加。

P3 · 时间范围校验不检查上界

GetTraceLogDashboard 校验了 to > from 和跨度 ≤ 10 分钟，但没有拒绝明显在未来的 to。Grafana 会自行处理，影响很小，记录一下。

明白