Jaeger v2.18.0 新增 ClickHouse 儲存後端：1000 萬條 Span 達到 8.6 倍壓縮比
CNCF Blog · 2026-06-23
分散式追蹤工具 Jaeger 於 2026 年 6 月 23 日由 Meta 維護者 Mahad Zaryab 發表 v2.18.0 ClickHouse 後端的技術分析，說明這項仍處於 alpha 階段的新儲存選項。在 1,000 萬條 Span 的基準測試中，spans 資料表的磁碟佔用從 5.99 GiB 壓縮至 722 MiB，達到 8.6 倍壓縮比。這是 Jaeger 在 Elasticsearch/OpenSearch 與 Cassandra 之外，首次引入列式儲存引擎作為後端選項。
背景
Jaeger 長期以來依賴 Elasticsearch/OpenSearch 或 Cassandra 作為 Span 儲存後端，兩者均採用行式或文件導向的儲存模型。追蹤資料本質上高度重複——相同的服務名稱、操作名稱、狀態碼在數千列中反覆出現。列式資料庫對這類資料的壓縮效果遠優於行式格式，因此 ClickHouse 成為自然的候選方案。此次實作依循 ADR-008 的設計決策，並在 Oracle Cloud VM.Standard2.4（4 OCPU、60 GB RAM）單節點環境下完成基準測試。
核心改動
Schema 核心為單一 spans 資料表，搭配多個 Materialized View 維護衍生資料。主鍵選擇了 (service_name, name, start_time) 而非 trace_id，以優化服務/操作維度的搜尋查詢，代價是單一 Trace 的 Span 不再連續存放。為補償這個取捨，Schema 在 trace_id 欄位上加了 Bloom filter skip index，並建立 trace_id_timestamps Materialized View 預先計算每個 Trace 的時間範圍，讓取得單一 Trace 時可做 partition 與 granule 剪枝。
屬性儲存採用 ClickHouse 的 Nested 資料型別，按型別分為獨立欄位：
bool_attributes Nested(key String, value Bool)double_attributes Nested(key String, value Float64)int_attributes Nested(key String, value Int64)str_attributes Nested(key String, value String)
另有 attribute_metadata 輔助表在查詢時解析字串屬性過濾條件，映射 key 對應的 (type, level) 組合，避免全表掃描。所有支援資料表均在啟動時自動建立，設定 create_schema: true 即可，無需手動執行 DDL。
規格細節
啟用方式需透過 feature gate 明確開啟，目前仍為實驗性功能：
go run ./cmd/jaeger \
--config cmd/jaeger/config-clickhouse.yaml \
--feature-gates=storage.clickhouseClickHouse 版本需求為 25.x，可用官方提供的 docker-compose 快速啟動。Schema 在未來版本中仍可能出現破壞性變更，不建議直接用於生產環境。
影響範圍
基準測試數據如下：
| 指標 | 數值 |
|---|---|
| 壓縮比（spans 表） | 8.6×（5.99 GiB → 722 MiB） |
| 寫入吞吐量 | 52,129 spans/秒 |
| 依 Trace ID 取得追蹤 | 平均 101 ms |
| 服務/操作維度搜尋 | 37–47 ms |
| 屬性過濾搜尋 | 1,769 ms |
屬性過濾查詢延遲偏高（約 1.7 秒）是目前已知弱點，後續版本將針對此場景優化。對於追蹤資料量龐大、儲存成本敏感的團隊，ClickHouse 後端提供了一條值得評估的低成本路徑，尤其適合已在其他場景部署 ClickHouse 的組織避免引入額外元件。
原始來源：CNCF Blog — Building Jaeger's ClickHouse backend、Jaeger ClickHouse Benchmarking Report、ADR-008 Schema Design
軟體原料清單 SBOM：供應鏈安全的必備基礎設施
Docker Blog · 2026-06-23
SBOM（Software Bill of Materials，軟體原料清單） 是一份機器可讀的清單，完整記錄軟體成品中每個元件、函式庫與模組的來源、版本與授權資訊。Docker 於 2026 年 6 月 23 日發表深度技術文章，說明 SBOM 在容器工作流程中的產生、儲存與應用方式。面對 Log4Shell 等重大漏洞事件，以及美國行政命令 EO 14028 與歐盟《網路韌性法》(CRA) 的合規要求，SBOM 已從選配工具轉變為交付流程的必要環節。
背景
2021 年 Log4Shell 漏洞爆發時，擁有 SBOM 的組織能在數分鐘內確認受影響映像，沒有的則需耗費數天。Sonatype 研究顯示，65% 的開源 CVE 在 NVD 資料庫中沒有 CVSS 評分，其中 46% 在獨立評估後屬於高危或嚴重等級。現有調查同時指出，逾 50% 的組織僅在特定需求時才臨時產生 SBOM，而非系統性地整合進 CI/CD 流程。
核心改動
SBOM 目前有兩大主流格式。SPDX（由 Linux Foundation 管理，ISO/IEC 5962:2021）以授權合規與開源審計為核心，支援 JSON、YAML、tag-value 及 RDF/XML；CycloneDX（由 OWASP 管理）以漏洞管理與 DevSecOps 流程為重點，支援 JSON、XML 及 Protocol Buffers。兩者各有側重但並不互斥，可視需求同時產出。
每筆元件記錄包含套件名稱、版本、供應商、授權類型、Package URL (purl)，以及 SHA-256 等加密雜湊值。以下是 SPDX 格式的範例條目：
{
"name": "openssl",
"SPDXID": "SPDXRef-Package-openssl",
"versionInfo": "3.1.4",
"supplier": "Organization: OpenSSL Project",
"licenseDeclared": "Apache-2.0",
"checksums": [{ "algorithm": "SHA256", "value": "a1b2c3..." }]
}規格細節
在容器工作流程中，SBOM 應於建置階段產生，以捕捉最終映像的完整狀態，而非僅依賴原始碼層級的分析。Docker BuildKit 支援以單一旗標在建置時產生 SBOM 並以 in-toto 格式附加為 OCI attestation：
docker buildx build --attest type=sbom --tag myapp:latest .SBOM 告訴你映像中「有什麼」，而 Provenance attestation 則說明它「如何被建置」，兩者共同構成 SLSA 框架要求的可驗證供應鏈。SBOM 必須與映像一同儲存在 OCI Registry 以防止版本漂移，並持續與最新 CVE 資料庫比對，無需重新分析原始碼。
影響範圍
法規面，美國 CISA 已於 2025 年發布 SBOM 最低元素指導方針，歐盟《網路韌性法》則將要求延伸至歐洲市場銷售的產品。金融、醫療、國防與關鍵基礎設施領域已逐漸將 SBOM 列為採購前提條件。需特別留意的是，SBOM 不等同於 SCA（軟體組成分析）工具，SBOM 是清單本身，SCA 工具是掃描清單找出漏洞的執行者；此外，SBOM 也無法偵測執行期零日漏洞或業務邏輯錯誤，僅是縱深防禦體系中的一層。
AI Agent 認證新挑戰：代理人身分、委託授權與稽核的技術架構
CNCF Blog · 2026-06-23
CNCF Ambassador Lin Sun 於 2026 年 6 月 23 日發表 Agent Auth: A Lawyer's Day in Court，以法庭類比說明 AI Agent 在身分驗證上面臨的新問題。文章的核心論點是：AI Agent 本質上是「微服務的進化版」，在傳統服務認證之上，還需要額外的委託身分、操作範圍與稽核可觀察性三層能力。隨著 MCP（Model Context Protocol）與 A2A（Agent-to-Agent）協定逐漸普及，這套問題在 2026 年已成為雲原生平台的工程實務議題。
原本的問題
傳統微服務只需回答「這個服務是誰？」，利用 mTLS 或 JWT 即可完成身分驗證。但 AI Agent 場景需要同時回答三個問題：這個 Agent 是誰（Agent Identity）、它代表哪個使用者行事（Principal Identity），以及被委託了哪些特定權限（Delegation Scope）。現有的身分基礎設施，如 SPIFFE/SPIRE 負責工作負載身分、cert-manager 負責憑證生命週期管理，可以解決第一個問題，但對後兩個問題沒有直接答案。
同時，Agent 的生命週期往往比傳統服務更短暫、更動態——一個對話可能在幾秒內產生並銷毀多個子 Agent。X.509 憑證核發的延遲在某些場景下已與 Agent 的存活時間不相容，這也是 IETF 在 2026 年初同步推進 AIMS、WIMSE、Agentic JWT、SCIM for Agents 等四份 Internet-Draft 的背景原因。
採用的方法
文章提出以 OBO Token（On-Behalf-Of Token） 作為委託授權的核心載體。一個完整的 OBO Token 需要包含四項資訊：
- Principal Identity：原始使用者的身分
- Agent Identity：執行操作的 Agent 身分（由 SPIFFE SVID 或等效機制提供）
- Delegated Permissions：被授予的操作清單
- Scope of Delegation：委託範圍與有效期限
擁有有效委託授權並不等同於可以執行任意操作——每次請求仍需通過獨立的授權策略引擎驗證，確認該操作是否在委託範圍之內。文章推薦的技術棧包含 SPIFFE 負責 Agent 身分核發、Istio 處理 mTLS 與流量授權、agentgateway 作為 Agent 請求的閘道層。
實際效果
這套架構的目標是讓 Agent 平台具備五項核心能力：強身分建立、跨請求的 Principal 身分傳播、委託 Token 核發與驗證、授權策略與範圍執行，以及完整的操作稽核追蹤。稽核可觀察性在 Agent 場景中尤其重要，因為 Agent 可能在短時間內代表多個使用者對多個後端服務發出請求，傳統日誌難以還原完整的操作鏈。Istio 的 Telemetry API 與 agentgateway 的請求日誌目前是較成熟的可觀察性方案，但標準化工作仍在 CNCF Working Group 層級進行中。
原始來源：CNCF Blog — Agent Auth: A Lawyer's Day in Court、AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A