Enrich GCP wire logs with trace context from the request ctx
Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
@@ -9,7 +9,7 @@ Plan: `docs/plans/2026-08-24-1025-otel-tracing.md`
|
||||
- [x] Step 5 — Reconciler spans
|
||||
- [x] Step 6 — Discovery server
|
||||
- [x] Step 7 — GC + health
|
||||
- [ ] Step 8 — GCP wire-log enrichment
|
||||
- [x] Step 8 — GCP wire-log enrichment
|
||||
- [ ] Step 9 — Manifests + docs
|
||||
|
||||
## Step 1 — Dependencies
|
||||
@@ -146,3 +146,12 @@ uninstrumented so no traceparent can leak through a proxy to external
|
||||
targets. Probe→reconcile span links stay out of scope (GenericEvent carries
|
||||
no ctx; the workqueue coalesces events) — recorded in the architecture
|
||||
Decisions in Step 9.
|
||||
|
||||
## Step 8 — GCP wire-log enrichment
|
||||
|
||||
`wireFilterHandler.Handle` clones the record and appends `traceID`/`spanID`
|
||||
when the ctx carries a valid span — same keys as the logr enrichment, added
|
||||
before the elision pass (both values are well under the 1KiB threshold).
|
||||
The new `wirelog_test.go` covers the enrichment, that the JWT/token security
|
||||
filter still drops non-wire Debug records even with a span present, and that
|
||||
spanless records stay unchanged.
|
||||
|
||||
Reference in New Issue
Block a user