Qonto 以 ClickHouse Cloud 重構可觀測性：查詢窗口從 2 小時延展至 2 週
ClickHouse Blog · 2026-05-01
法國金融科技公司 Qonto 將可觀測性後端從 Grafana Tempo 遷移至 ClickHouse Cloud，解決了此前因效能限制而只能查詢 2–3 小時資料、被迫進行激進取樣的問題。
架構
資料流從應用程式、前端、Kubernetes 與 GitHub 出發，進入 OpenTelemetry Collector，透過 AWS PrivateLink 傳輸至 ClickHouse Cloud。Grafana 作為主要儀表板介面。此外，Qonto 部署了 ClickHouse MCP Server，讓 Claude 等 AI 客戶端可以用自然語言進行事件調查，自動判斷受影響的客戶與地理區域，將事故響應能力開放給非 SRE 人員。
壓縮效率
ResourceAttributes 與 SpanAttributes 資料達到 99.84% 壓縮率：231 TB 未壓縮資料壓縮後僅佔 376 GB，換算約節省每年 7 萬美元 S3 儲存成本。高基數（high-cardinality）資料的儲存成本得以控制，工程師現在可以在 span 中加入完整的 metadata 而不必顧慮成本。
查詢能力改變
遷移前：受 Tempo 效能限制，查詢窗口上限 2–3 小時，超過即崩潰，需要大量取樣以控制資料量。遷移後：查詢窗口延展至 2 週，無取樣限制，可直接從 trace 生成指標（metrics from traces），消除了 Tempo 架構下必須在 trace 儲存與指標儲存間做取捨的問題。
原始來源：ClickHouse Blog
PgQue v0.1：純 SQL 實作的零膨脹 PostgreSQL 訊息佇列
postgresql.org · 2026-05-02
PgQue 是以純 SQL 與 PL/pgSQL 實作的零膨脹（zero-bloat）PostgreSQL 事件/訊息佇列，移植自 Skype 開發的 PgQ 架構，目標是在不安裝 C 擴充的前提下，在託管 PostgreSQL 平台（RDS、Aurora、Cloud SQL、AlloyDB、Supabase、Neon 等）上執行。
零膨脹的實作原理
傳統資料庫佇列（如 SKIP LOCKED 模式）依賴持續對同一張表執行 DELETE 與 UPDATE，這會累積大量死元組（dead tuples），造成 VACUUM 壓力與索引膨脹，長期運行下效能顯著退化。PgQue 採用兩項核心設計：
- 快照批次處理（Snapshot-based Batching）：利用 PostgreSQL 的快照隔離，消費者在一個一致性快照下批次讀取事件，避免熱路徑上的行競爭。
- 表格輪換（Table Rotation）：處理完成的事件不透過 DELETE 清除，而是在特定時機整批輪換（rotate）表格，消除累積死元組的根本原因。
規格
相容 PostgreSQL 14–18，單一 SQL 檔案安裝，支援多個獨立消費者共用事件 log、內建重試機制與死信佇列（dead-letter queue）。可選整合 pg_cron 進行自動 tick；典型事件投遞延遲為 1–2 秒，適合對穩定性要求高於超低延遲的持久事件流場景。
pgagroal 2.1：PostgreSQL 連線池新增 Vault 安全機制與 Prometheus Web 主控台
postgresql.org · 2026-05-02
pgagroal 是以 C 撰寫的高效能 PostgreSQL 連線池（connection pooler），2.1 版帶來安全性強化與可觀測性改進。
Vault 安全機制（需遷移）
2.1 版重新設計了 vault 功能，即前端密碼管理（frontend password management）的儲存與驗證機制。現有部署需要按照文件執行遷移步驟方可升級；pgagroal 官方文件已提供遷移指南。
Health Check 與 Failover
新增 health check 功能，允許連線池主動監控後端 PostgreSQL 伺服器的連線狀態。配合強化的 failover 支援，pgagroal 可在後端伺服器故障時自動將連線重導至健康節點，提升高可用部署的可靠性。
Prometheus Web Console
新增 Prometheus Web 主控台介面，建立於既有的 Prometheus 指標匯出支援之上，提供直接透過瀏覽器可視化 pgagroal 指標的入口，並與 Grafana 12 儀表板整合。