feat(observability): verify SigNoz three-signal route parity

This commit is contained in:
ogt
2026-07-15 01:08:31 +08:00
parent bcc87ccd7e
commit fb0150d6ae
8 changed files with 557 additions and 2 deletions

View File

@@ -1,3 +1,28 @@
## 2026-07-15 — P0-OBS-002 SigNoz canonical route Wave A
**完成內容**
- 建立 organization / canonical route machine-readable contract五個 producer 的 active endpoint 維持 `.188` incumbent僅加入 `.110` challenger application / NetworkPolicy allow未切流。
- 新增 route-scoped logs / metrics / traces verifier。`P0-OBS-002-20260715T005626+0800` 以唯一 synthetic marker 驗證 incumbent bridge、`.120 -> .110``.121 -> .110` 三條路徑。
- 三條路徑的 OTLP logs / metrics / traces 都回 HTTP `200`ClickHouse 對每條路徑各自讀回 log `1`、metric series `1`、metric sample `1`、trace `1`
- bridge user-systemd supervisor 受控接管三次均 fail closed 並回滾至 legacy process + reboot cron第三次 journal 證明 unit 曾啟動,但 executor readiness 判定過早。source 已補 takeover rollback flag 與最長 10 秒 readiness loop本輪不再進行第四次 runtime 嘗試。
- 產出 `ops/signoz/p0-obs-002-three-signal-route-parity.yaml`;明確把 synthetic route parity 與真實應用 trace freshness、producer queue gate、正式 promotion 分開。
- 最新 10 分鐘 error fingerprint 證明 normalization noise 是固定成對錯誤:`.120``cri_parser regex_no_match=156` + `move3 missing_field=156``.121``126 + 126`;同時兩個 collector queue / send_failed 都是 `0`
- 第一版 filelog candidate 的 `on_error: send_quiet` 通過 `0.96.0 validate`,但隔離 Pod 在真正 build pipeline 時明確拒絕;兩次 canary 均已刪除且未碰正式 DaemonSet。source 已移除不相容欄位,改為 parser `body matches` 前置條件、保留 malformed 原始 body、以 `awoooi.log.parse_status=fallback_unparsed` 標記,並只在 `attributes.log` 存在時 move body修正版刻意不做第三次 runtime canary狀態維持 canary pending。
**已跑驗證**
- SigNoz / OTEL / Event Exporter / API config 聚焦回歸:`43 passed`;其中 canonical route migration 為 `9 passed`。ruff、py_compile、四支 shell `bash -n`、canonical route preflight、三份 Kubernetes server dry-run、runner pressure guard、Gitea secret transport guard 與 `git diff --check` 通過。
- 先前 route-specific log replay 已驗證 `.120/.121` HTTP `200`、ClickHouse exact marker `1`、15 秒 queue / failure delta `0`;本次三訊號 direct verifier不把該結果誤宣稱成 producer canary。
- bridge rollback 後 `.120/.121 -> .188:24318` 回 HTTP `200`legacy cron 已恢復live user-systemd unit 已移除 / disabled。
**仍維持**
- `setupCompleted=false`、organization 未初始化、`.110:4317/4318` direct ingress 暴露面尚未收斂、真實應用 traces 不新鮮、filelog normalization source fix 尚未 canary、bridge 尚未由 user-systemd supervision 接管。
- synthetic 三訊號 parity 不等於正式 producer canary、Wave B promotion、bridge retirement、AI learning writeback 或 production closureactive route 仍是 incumbent。
- organization/root bootstrap 涉及 durable credentialdirect ingress policy 可能涉及 firewall / mTLS。這些維持獨立 high/critical gate本輪未讀 secret、未改 firewall、未寫 raw DB、未碰 stateful volume。
- Gitea feature branch / source 測試、main CD、deploy marker、production runtime 與 visible evidence 仍分層追蹤;不得由 feature push 或 synthetic readback 倒推 production 已部署。
**下一步**
- 等 direct ingress policy 與 organization gate 具備受控包後,先做單一 producer canary要求同一 run 的三訊號、queue/failure delta、normalization error rate、rollback與獨立 post-verifier 全綠;再逐批 promotion最後才生成 bridge retirement receipt。
## 2026-07-14 — P0-OBS-001 SigNoz OTLP 收集與持久佇列修復
**完成內容**