ClickHouse Terraform Provider 新增 ClickStack 資源模組，可觀測性設定正式納入版控流程
ClickHouse/clickhouse Terraform Provider · v3.25.0 · 2026-08-11
背景
ClickStack 是 ClickHouse 推出的可觀測性套件，整合日誌、追蹤與指標查詢，但過去 dashboard、alert、saved search 等設定只能透過網頁介面或 API 手動建立，難以納入版本控制。ClickHouse 官方 Terraform provider（ClickHouse/clickhouse）在 v3.20.0（2026-07-17）先以 alpha 型式加入九個 ClickStack 資源與兩個 data source，讓 HyperDX 自建部署的觀測資源能用 Terraform 描述。ClickStack 支援因此已經迭代了一個多月，這次的 v3.25.0 是延續這條路線的修正版本。
核心改動
最新的 v3.25.0（2026-08-11）沒有新增資源型別，而是修正 clickhouse_clickstack_dashboard 資源在 terraform import 後產生的 state 含有伺服器端專屬 ID，導致後續 terraform plan 驗證失敗的問題；import 後的 state 現在會先剝除這些欄位再寫入。同一版本也讓 Kafka 家族的 ClickPipe 可以在 settings 區塊設定 kafka_read_committed = true，跳過尚未提交交易的紀錄，這項改動與 ClickStack 無直接關聯，但屬於同次發版。這次改動對應的 PR 為 #631、#652、#654。
規格細節
ClickStack 資源模組維持與既有 provider 相同的驗證機制：dashboard 定義會在 terraform plan 階段呼叫 ClickStack API 做 schema 驗證，避免上線後才發現欄位錯誤。Provider 同時支援兩種認證模式：
- ClickHouse Cloud：以 organization ID 搭配 API key 認證
- 自建（self-hosted）：以 HyperDX endpoint 搭配 personal API key 認證
文件同時提供既有 dashboard 的 import 流程與批次匯出（bulk-export）指令，方便既有部署回填成 Terraform 設定檔。使用這個版本需要 Terraform 1.5 以上版本。
影響範圍
對已經用 Terraform 管理 ClickHouse Cloud 的團隊而言，這代表 dashboard、alert、saved search、connection、webhook 等原本分散在 UI 上的設定，現在可以走 PR review 流程，跟基礎設施程式碼放在一起版控。因為 ClickStack 資源被整合進既有 provider 而非獨立發佈，認證與升版節奏跟其餘 ClickHouse 資源共用同一套流程，不需要額外安裝或管理另一個 provider。目前 ClickStack 資源仍標示為 beta，本次修正的 import state 清理問題顯示這塊功能還在快速迭代中。
ClickStack 與 Hud 用 Trace ID 打通服務層與函式層可觀測性，讓 AI 代理讀懂上線風險
Hud 整合文件 · 更新於 2026-07-28（ClickHouse Blog 發布於 2026-08-13）
背景
AI coding agent 大量產生程式碼之後，工程團隊面對的問題從「怎麼寫」轉成「哪些改動能安全上線、上線後怎麼發現異常、出事時要花多久才能定位」。ClickStack 提供服務層的日誌、追蹤與指標查詢，Hud 則是一套執行期程式碼分析工具，能在不插入額外埋點的情況下，記錄函式層級的執行鑑識（forensic）資訊。兩者原本各自獨立，資料無法互相對照，這次整合就是要補上這個缺口。
核心改動
整合做法是讓兩邊共用 OpenTelemetry trace ID 當作關聯鍵。Hud 會從 W3C traceparent header 擷取 trace context，寫入自己的鑑識紀錄欄位 observability_identifiers.otel_trace_id；只要服務原本就有傳遞 OpenTelemetry context header（多數已接入 ClickStack 追蹤的服務都符合），Hud 記錄的函式層資料就能跟 ClickStack 的服務層 span 對上號，不需要額外建置一條專門的資料管線。兩個平台各自都以 MCP（Model Context Protocol）伺服器對外提供查詢介面：ClickStack MCP 用 Streamable HTTP 加 Bearer token 認證，回傳 service／deployment／endpoint 層級的日誌、追蹤與指標；Hud MCP 則回傳綁定原始碼的函式層指標與鑑識內容。
規格細節
當同一個 coding agent 同時掛載這兩個 MCP 伺服器時，就能做雙向查詢：從 Hud 查到的 otel_trace_id 可以回頭向 ClickStack 要對應的 log 與 span；反過來，ClickStack 上發現的服務層異常，也能讓 agent 用同一個 trace ID 去 Hud 找出對應的函式層根因。串接步驟如下：
1. 安裝 Hud MCP（IDE extension 或 Remote MCP Server，供 CI 使用）
2. claude mcp add --transport http clickstack \
https://<hyperdx-url>/api/mcp \
--header "Authorization: Bearer <key>"
3. 確認服務已傳遞 OpenTelemetry context header文件本身沒有列出對應的軟體版本號，最後更新時間為 2026-07-28，ClickHouse 官方部落格則在 2026-08-13 發布這篇整合公告。
影響範圍
這套串接鎖定三種情境：部署前用 agent 評估程式碼變更的風險、部署後偵測效能或錯誤率的回歸、以及事故發生時讓 agent 用同一組 trace ID 自動收斂根因、縮短排查時間。因為兩邊都是透過 MCP 暴露資料，理論上任何支援 MCP 的 agent 環境都能同時掛載兩個伺服器，不限定特定 IDE 或 CI 系統。但整合的前提是服務必須先讓 OpenTelemetry trace context 正確傳遞，如果服務間呼叫沒有全程保留 traceparent header，兩邊資料就無法對上。
原始來源：Hud 整合文件、ClickHouse Blog
開源工具 Dasha 免安裝代理監控 PostgreSQL 叢集，新版加入 Schema 健檢與 MCP 工具
Dasha GitHub (dbulashev/dasha) · CHANGELOG v1.6.0 · 2026-08-12
背景
多數 PostgreSQL 監控方案需要在每台資料庫主機上安裝 agent 或擴充套件才能收集指標，對於管理多套叢集、多個 replica 的團隊來說，佈署與維護 agent 本身就是額外負擔。Dasha 是一套開源（GPLv3）的 PostgreSQL 效能儀表板，單一實例即可連線監控多組叢集與其 replica，不需要在資料庫主機上安裝任何 agent 或擴充套件，只依賴標準連線與 pg_stat_statements 之類既有的統計視圖。PostgreSQL.org 於 2026-08-12 刊出這個專案的介紹文。
核心改動
最新版 v1.6.0 的重點是新增 Schema Checks 頁面：掃描 schema 層級的結構性缺陷，例如序號（sequence）即將耗盡、缺少主鍵等平常不會主動被注意、直到出事才發現的問題，並附上修正建議。同一版本把這項檢查包成兩個 MCP 工具 schema_lint 與 schema_lint_summary，讓 AI 助理可以直接呼叫做 schema 健檢，不必先讀懂 Dasha 的網頁介面。此外，新版也加入依 regex 篩選的自動資料庫探索機制，能在叢集內自動找出符合條件的資料庫，不用逐一手動註冊。
規格細節
Dasha 的核心功能圍繞在一個綜合的 Health Score：把八個類別的檢查結果彙整成 0–100 的分數並附建議，涵蓋範圍包括：
- 查詢分析：top queries、正在執行／被鎖住的查詢、
pg_stat_statements快照 - 索引分析：偵測膨脹（bloat）、重複索引、失效索引，並給出可刪除建議（Index candidates）
- 資料表維護：容量分析、autovacuum 門檻與 vacuum 進度追蹤
- 鎖與連線監控：鎖等待樹（lock tree）、wait event、連線狀態
本版也改進 Live Queries 畫面，補上 wait type、wait event、client address 與 session 狀態；快照比較功能改為分頁載入以改善大量資料時的效能。執行環境需求為 PostgreSQL 14 以上（官方測試涵蓋 14 到 18），選配 pgstattuple 擴充套件以取得更準確的膨脹估算，另建議準備一個獨立的 PostgreSQL 資料庫存放快照與歷史紀錄。存取控制支援 OIDC、API key、以 Casbin 實作的 RBAC，以及個人存取權杖（PAT）。
影響範圍
對維運多組 PostgreSQL 叢集的團隊，免 agent 架構代表可以在不改動生產主機的前提下接上監控，降低導入門檻。Schema Checks 與對應的 MCP 工具，讓「結構性技術債」這類過去要靠人工 code review 才會發現的問題，變成可以排程掃描、也能被 AI 助理直接查詢的項目。這個版本同時修掉幾個既有問題：擁有數千個物件的資料庫在產生「最大資料表」報表時會逾時、小型資料庫的 cache hit ratio 計分不準確、部分快照只能在特定資料庫底下才看得到等。
原始來源：GitHub Repo、CHANGELOG