Elastic 全新指標監控技術：大幅提升公部門 IT 系統可用性的關鍵突破

Elastic 產品資訊 2026 年 8 月 3 日

Elastic Observability 推出全新欄式指標引擎（Columnar Metrics Engine），重構了底層時間序列資料的儲存與查詢架構。

這項更新讓公部門（如政府機關、國營事業、醫療單位與公立大學）的 IT 維運與 SRE 團隊，得以在單一平台上整合日誌、指標與追蹤，在確保系統可用性的同時控管整體持有成本。

公部門 IT 面臨的觀測性挑戰

政府機關與公部門的 SRE 團隊承受著獨特的維運壓力。團隊必須在複雜的混合雲、地端甚至實體隔離（Air-gapped）的基礎架構中維持關鍵任務運作，同時滿足嚴格的資安稽核與法規遵循，且每筆 IT 預算都必須對審計機關與公眾負責。

然而，傳統可觀測性工具的計價機制，與現代架構（如 Kubernetes 容器環境）的擴展需求相衝突：

Elastic 重新設計了 Elasticsearch 儲存與查詢時間序列資料的底層邏輯，將指標功能建構於專為時間序列資料流（TSDS）優化的欄式儲存引擎之上。

這項架構重構帶來了直接的數據改變：

儲存空間縮減 6.6 倍：以 OpenTelemetry 指標為例，單一資料點的儲存體積從過往的 25 bytes 降至 3.75 bytes。與開源的 Prometheus 相比，儲存效率高出 2.5 倍。
查詢速度提升 160 倍：時間序列資料的查詢速度較舊版 TSDS 提升達 160 倍，較 Prometheus 快上 30 倍，且索引寫入吞吐量提升了 50%。

對公部門而言，這意味著無需犧牲系統效能或調降解析度，就能以極低的儲存成本將完整的指標資料留存數月甚至數年，滿足長期趨勢分析與法規稽核需求。新增 Kubernetes 標籤或雲端標籤時，也不再需要擔心架構超載。

許多政府機關原本就使用 Elastic 儲存海量的日誌資料。現在，相同的底層架構直接延伸到指標監控。

過去，多數單位積累了諸多「觀測性債務」——使用孤島式工具，日誌、指標、追蹤各自獨立。每種資料各自存在不同的後端、使用不同的查詢語言。當資安事件或系統異常發生時，工程師必須在多個瀏覽器分頁之間頻繁切換上下文，手動拼湊問題全貌。

Elastic 將指標、日誌與追蹤儲存在統一的後端。當告警觸發時，系統會自動整合相關的日誌事件、異常指標與追蹤鏈結。內建的機器學習異常檢測會自動針對基礎架構指標進行運算，告警時直接附帶異常嚴重程度與變更上下文，而非僅僅是觸及傳統的閾值臨界點，從而縮短平均修復時間。

Elastic 提供三種部署模式：Serverless、雲端託管，以及完全自建的地端或實體隔離環境。

許多提供核心公共服務或高度機密性的政府單位，對資料落地有嚴格限制。Elastic 確保地端與隔離環境擁有與雲端完全相同的核心功能，不因部署在地端而刪減技術效益。

有別於 Datadog 等商業廠商強制且複雜的定價機制（結合主機數與客製化指標基數非線性計價），Elastic 採用非人頭、非主機數的計價邏輯，用戶純粹為資料量付費。

在 Elastic 執行 Serverless架構下，啟用 TSDS 模式的指標資料，其寫入與留存費用僅為標準可觀測性每 GB 費率的 25%，整體花費大約只需 Datadog 等廠商的一半，大幅降低了容器化環境下的監控開銷。

公部門的資訊採購與架構轉移通常較為審慎，難以接受推翻重寫的巨大風險。多數維運團隊在 Kubernetes 與雲原生環境中，已經累積了大量的 Prometheus 監控組態、告警規則、PromQL 查詢語句以及 Grafana 看板。

Elastic 提供了近乎零摩擦的轉移路徑：

原生 PromQL 支持：Prometheus 指標透過 Remote Write 寫入 Elasticsearch 的欄式儲存，資料語意不變。Kibana 原生支援 PromQL，團隊現有的查詢語句與看板不需重寫即可直接運作。
相容 Grafana 前端：Elasticsearch 提供相容 Prometheus 的 API。如果工程師習慣原本的 Grafana 視覺化介面，可以直接將 Elasticsearch 當作後端資料源進行查詢，維持既有的操作習慣。
自動化轉移工具：提供命令列工作流（Observability Migration Platform），能將 Datadog 與 Grafana 的既有看板、告警資產自動轉換為 Kibana 原生格式，並自動產出包含遷移報告、變更清冊與驗證清單的審查文件，供主管與評估小組進行合規審查。