Cloud-native 團隊為何仍運行三套可觀測性堆疊：工具就緒，但採用停滯
CNCF Blog · 2026-05-06
OpenTelemetry 已達 1.0、Prometheus 廣泛部署、Grafana 幾乎無所不在——工具已經就緒，但 CNCF 觀察到大多數 cloud-native 團隊仍同時運行三套或更多可觀測性堆疊。工具整合是技術問題，採用停滯是組織問題。
原本的問題
典型場景：團隊從不同時期繼承了 Datadog、Prometheus/Grafana 與 Jaeger 三套系統，各自由不同的業務需求驅動建立。遷移成本（告警規則重寫、dashboard 移植、on-call 流程更新）被評估為風險過高，加上工具廠商的企業合約鎖定，讓「理論上的整合路徑」停留在 backlog 中。
採用方法
CNCF 調查指出幾個成功整合的共通策略：以 OpenTelemetry Collector 作為中間層，先不改動既有接收端，而是在資料流入口統一採集——新服務發送 OTLP，Collector 同時 fan-out 到既有的 Prometheus exporter 與 Jaeger，讓既有系統在轉換期繼續運作。
另一個策略是「新服務只用一套」：對已有三套的存量系統不做全面遷移，但對所有新服務強制只使用單一堆疊（OpenTelemetry + Grafana Cloud），逐步讓整體比例向整合側傾斜。關鍵在於必須有高層技術決策者設定明確的截止期限，否則漸進式遷移會無限延期。
實際效果
成功整合的案例回報：可觀測性工具授權費用降低 40–60%（消除重複採集與儲存）、on-call 工程師學習曲線縮短（不需同時熟悉三套查詢語言：PromQL、LogQL、Datadog DSL）、以及跨訊號的關聯追蹤（trace → metrics → logs）在整合堆疊中更易實現。
Grafana Adaptive Logs Drop Rules：依模式自動丟棄高頻低價值日誌行
Grafana Labs Blog · 2026-05-08
Grafana Labs 在 Grafana Cloud 推出 Adaptive Logs drop rules，讓可觀測性平台可以根據日誌模式分析，自動識別並丟棄高頻但低資訊量的日誌行，在不影響告警與除錯能力的前提下降低儲存成本。
核心改動
Drop rules 的設計前提是：生產環境中約 30–50% 的日誌體積來自少數幾個高頻重複模式（例如 health check request、定期 cron job 輸出、固定格式的 audit log），這些日誌在實際排障時幾乎從未被查詢。Adaptive Logs 會分析流入的日誌串流，自動找出這些模式並生成建議的 drop rule，讓 SRE 審核後啟用。
Drop rule 在 Grafana Alloy（OpenTelemetry Collector 的 Grafana 分支）的管線中執行，在日誌送達 Loki 儲存前過濾，因此不產生儲存費用。規則以 LogQL 語法表示，確保可讀性與可審核性：
# 自動生成的 drop rule 範例
{job="nginx"} |= "GET /health HTTP/1.1" | drop lineGrafana gcx CLI：終端機可觀測性
同期推出的 gcx CLI 讓開發者與 AI 代理可以從終端機直接查詢 Grafana Cloud 的 metrics、logs 與 traces，無需打開瀏覽器。gcx 支援 PromQL 查詢、LogQL 日誌搜尋，以及 trace lookup，設計上刻意兼容 LLM 工具呼叫場景——結構化輸出（JSON）讓 AI 代理可以直接解析可觀測性資料進行自動化診斷。
gcx metrics query 'rate(http_requests_total[5m])' --output json
gcx logs query '{job="api"}' --since 1h --limit 100原始來源：Eliminate noisy log lines with Adaptive Logs drop rules (Grafana)、Get observability in the terminal with the gcx CLI (Grafana)
DNSSEC 失效案例：.de TLD 斷線事故的技術解析與 1.1.1.1 serve-stale 緩解
Cloudflare Blog · 2026-05-06
2026 年 5 月 5 日，德國頂級域名（.de）的管理機構 DENIC 發布了格式錯誤的 DNSSEC 簽章，導致全球遵循 DNSSEC 驗證的 DNS 解析器無法解析所有 .de 域名。Cloudflare 的 1.1.1.1 serve-stale 功能在此次事故中有效緩衝了用戶影響。
漏洞機制
DNSSEC 透過數位簽章（RRSIG）保護 DNS 回應的完整性：解析器驗證回應的 RRSIG 與上游信任鏈一致後才接受結果。DENIC 在此次事故中發布了驗證失敗的 RRSIG，導致所有嚴格遵循 DNSSEC 的解析器（包括 1.1.1.1 的驗證模式）拒絕接受 .de 的 NS 記錄，使所有 .de 子域名回傳 SERVFAIL。
Serve-Stale 緩解機制
1.1.1.1 的 serve-stale（RFC 8767）功能在 DNSSEC 驗證失敗時，允許解析器繼續服務已過期但仍在 stale TTL 範圍內的快取記錄，同時在背景嘗試更新。此機制在此次事故中讓使用者在快取有效期間內幾乎感受不到中斷。
然而 serve-stale 存在一個邊界條件：對從未被該解析器快取過的域名，以及快取已完全過期的域名，仍會回傳解析失敗。DNSSEC 的強制驗證與服務可用性之間存在根本張力——此次事故是典型案例，說明 DNSSEC 配置的操作複雜性是其普及率低的直接原因之一。
原始來源：When DNSSEC goes wrong: how we responded to the .de TLD outage (Cloudflare)