Observability 三本柱如何和 Elastic Stack 及 Kubernetes 整合?

什麼是 Observability ?

Elastic 並沒有發明「Observability」這個詞。而是從用戶那裡聽到它，主要是網站可靠性工程 (SRE) 社群中的用戶。據說這個術語的起源會追溯到 Twitter 等矽谷巨頭的 SRE 企業。儘管開創性的 Google SRE Book 沒有提及該術語，但它列出了當今與「Observability」相關的許多原則。

Observability 不是供應商打包好的一個東西，它是系統的一個屬性，就像可用性、高可用性和穩定性一樣。設計和建立「可觀察」系統的目標是確保當它在正式環境中運行時，負責的維運人員可以檢測到不良行為（例如：服務停機、錯誤、回應緩慢）並擁有可操作的訊息來有效找出根本原因（例如：詳細的事件日誌（logs）、資料粒度使用資訊和應用程式追蹤）。儘管是一個看似簡單的目標，大部分企業仍常遭到以下挑戰：沒有收集足夠的資訊或收集太多資訊，資訊無法化作行動依據，以及資訊散落各處。 

看待 Observability 的面向

第一面向：不良行為的檢測

透過定義好的 服務水準指標 (SLI) 和服務水準目標 (SLO)  作為內部衡量標準，在具有可觀察性的企業中判斷正式環境系統。如果有履行這些目標的契約責任，則 SLI/SLO 也可以轉化為服務水準協議 (SLA)。 SLI 最常見的範例是系統正常運行時間（uptime），您可以將 SLO 定義為 99.9999%。系統正常運行時間也是向外部客戶公開的最常見的 SLA。但是，您的內部 SLI/SLO 可能更精細，對正式環境行為的最重要因素進行監控和告警是任何可觀察性計劃的基礎。這一方面的可觀察性也被稱為監控（monitoring）。

第二面向：為維運人員提供詳細的資訊，快速有效的調整問題

關於 Observability  的三個主要的重點支柱 —— metrics, logs, 和 application trace 是最多人關心的。人們還認識到，使用 patchwork 工具簡單的收集所有這些粒度資料不一定是可行的，而且通常不具有成本效益。

Observability 三本柱

我們今天通常遇到的現狀是將 metrics 收集到一個系統（通常是時間序列資料庫或用於資源監控的 SaaS 服務），將日誌收集到第二個系統（ELK 堆棧），並使用第三個工具來檢測應用程式以提供請求等級追蹤。當告警觸發時，表示服務等級存在漏洞，維運人員會向系統執行最佳的解決方法，查看一個瀏覽器窗口中的 metrics，手動將其關聯到另一個窗口中的日誌，如果相關並在第三個窗口開啟 traces。

這種方法有幾個缺點。首先，手動關聯所有相同名稱但不同資料源，會在服務降級或中斷期間浪費寶貴的時間。其次，維護三個不同的營運數據儲存的營運成本是繁重的，例如： licensing 成本、不同營運工具的管理員人數、每個資料庫中不一致的機器學習能力、不同語意告警的預留空間(headspace)。

將所有資訊放在一個操作型儲存庫中，並能夠在直觀的用戶界面中自動關聯這些資料越來越重要。對於 ELK 的用戶而言，Nirvana 讓維運人員都可以接觸和他們支援服務相關的每筆資料，無論是應用程式發出的 log line、檢測產生的 trace 資料，或是由時間序列中的 metrics 表示的資源利用率。我們接收到的需求強調對這些資料的統一，與無論來源如何的臨時訪問，從搜尋和過濾到整合，再到視覺化。從 metrics 開始，在不切換上下文的情況下，點擊即可深入了解 logs 和 traces，從而加快查詢速度。相同的，從結構化日誌中提取數值看起來與 metrics 十分相似，如將兩者合併視覺化，從操作的角度來看將具有極大的價值。

如前所述，只是單純地收集資料可能會導致磁碟上的資訊過多，並且在事件發生時沒有足夠的可操作訊息。越來越多的人期望收集操作資料的系統能夠自動檢測時間序列模式中的事件、traces 和異常。這有助於維運人員更快的找到問題的根本原因。這些異常檢測能力有時被稱為「observability 的第四支柱」。檢測正常運行時間資料、資源利用率、logging 模式中的異常和大多數相關 traces 中的異常是 observability 團隊提出的新需求。

Observability 和 ELK Stack

那麼 Observability 與 Elastic Stack 有什麼關係呢？
ELK Stack 公認是集中操作系統日誌實際的方法， Elasticsearch（一種搜尋引擎）是存放基於文本的日誌( text-based logs）以進行自由正文搜尋(free-text search)的好選擇。事實上，以基於文本的日誌搜尋「error」或根據一組眾所周知的標籤過濾日誌是非常有效的，這也是大多數用戶最一開始的應用。

然而，正如大多數 ELK Stack 用戶所知，Elasticsearch 作為資料儲存提供的不僅僅是倒排索引（inverted index），還包含高效的全文檢索搜尋（full-text search）和簡單的過濾功能。它還包含一個列式儲存，針對密集資料時間序列的儲存和操作進行優化。列式儲存用於儲存從解析的日誌中提取的資料架構，包括字串（string）和數值（numerical）。事實上，將日誌轉換為 metrics 的用例是當初促使我們優化 Elasticsearch 以實現有效儲存和檢索數值的原因。

隨著時間的推移，用戶開始將數值時間序列直接放入 Elasticsearch，以取代舊的時間序列資料庫。在這種需求的推動下，Elastic 最近推出了 Metricbeat，用於自動收集 metrics、自動打包的概念以及資料儲存和 UI 中的其他 metrics-specific 功能。因此，越來越多採用 ELK Stack 進行日誌的用戶也開始將 metric 資料（例如資源利用率）放入 Elastic Stack。除了先前所提的節省營運之外，另一個吸引人的原因是 Elasticsearch 對符合數值聚合條件字段的 cardinality 沒有限制（許多現有的時間序列資料庫常見的問題）。

與 metrics 類似，正常運行時間資料與日誌都是被高度重視的資料類型，是主動監測器的 SLO/SLI 告警的重要來源。通常是在用戶感受到影響之前，正常運行時間資料可以提供相關服務、API 和網站降級的資訊。好處是，就儲存需求而言，正常運行時間資料很少，因此只需很少的額外成本即可獲得價值。

在過去的一年中，Elastic 還引入了 Elastic APM，為堆棧增加應用程式追蹤和分佈式追蹤功能。這對 Elastic 來說是一個自然變化，因為一些開源項目和著名的 APM 供應商已經在使用 Elasticsearch 來儲存和搜尋 trace 資料。傳統 APM 工具的現狀是將 APM trace 資料、logs、metrics 分開，導致營運資料孤島永久存在。 Elastic APM 提供了一組 agents，從支援的語言和架構，以及支援 OpenTracing 收集 trace 資料，並且這些 trace 資料會自動與 metrics 和 logs 相關。

Kubernetes 和 ELK Stack

Observability 的概念在採用 Kubernetes 進行容器編排的用戶中是一個非常活躍的話題。由 Cloud Native Computing Foundation (or CNCF) 推動的「原生雲」用戶，正面臨著獨特的挑戰。他們面臨著建立在或遷移到 Kubernetes 支援的容器編排平台上的應用程式和服務的集中化挑戰。以及將單體式應用程式拆分為「微服務」的趨勢。以往為在此基礎架構上運行的應用程式提供必要視覺化的工具和方法將不再適用。

參考 Observable Kubernetes webinar 和 Distributed Tracing with Elastic APM blog post 以獲得更多資訊。
了解更多請參考歐立威 Elastic 產品介紹