Elastic 的 Observability 解決方案
Last updated
Last updated
了解 Elastic 針對 observability 的觀點
初探 Elastic Observability 的解決方案
前一篇我稍微淺談了自己對 Observability 的解讀，至於 Elastic 針對 Observability 的觀點，我蠻推薦 Elastic Observability 的 Product VP - Tanya Bragin 在 Observability with the Elastic Stack [1] 的這篇文章，裡面有提到二個看待 Observability 的面向，分別是：
檢測服務品質的管理面向：透過定義好的 SLIs (Service Level Indicators) 及 SLOs (Service Level Objectives) 來當作服務品質指標的標準，例如一般會使用系統的 uptime (正常運行的時間) 當作 SLI 的這個指標，進而定義可能是 6 個 9 (99.9999%) 的 SLO 這個目標，並且可以將這兩個定義轉換成為 SLAs (Service Level Agreements) 提供給客戶當作服務的保障範圍的依據，這通常會是 observability 的起步，其實也就是以終為始的重要的目的 - 提升客戶的滿意度，而執行的方式其實就是大家都已經有在做的 Monitoring。
提升解決問題效率的方法：如何讓開發、運維的人員，在遇到系統發生問題時，能因為系統具有良好的 Observability，能更有效率的快速發現原因及解決問題，甚至在異常的徵兆發生時，就能觀察到異狀並且避免更大災情的發生。
針對 Observability 的三個主要的重點支柱，就是 Logs、Metrics、Traces，這個在所有談 Observability 的討論上，已經都成熟的歸納成這三個面向的資訊了，Elastic Observability 也就直接針對這三個面項定義在產品的功能之中。
日誌是掌握系統內部發生什麼事情最重要的資訊，而日誌的重點，是從一開始程式開發時日誌如何撰寫，就已經事關一半的成敗，如果源頭的資訊不夠詳細，後續就只能用猜測、或是災情發生後再去埋 Log，這樣就又錯過了救援的黃金時刻，再來就會是如何收集散落各地、各種格式的日誌，以及如何將這麼大量的資料進行有效的分析及使用，最後是如何管理這些資料的生命週期。
Metrics 是以數字化的方式來有效率的解讀系統運作狀態的重要資訊，舉凡 CPU loading, Memory, Disk I/O, Disk free space, Network bandwidth, DB metrics, ... 等各種數字化的指標資訊，透過這些指標能做到最基本的異常的判斷，而這些 Metrics 也會是資料量極多的資訊，如何更有效的保留這些資料也會是管理上的重點。
一個交易在系統處理時，經過了哪些環節、哪些子系統、當中做了什麼事、在哪個地方會產生效能的瓶頸、在哪個服務元件之中有發生異常，能夠在複雜的系統架構中協助開發運維的人員一目瞭然的掌握交易運作的細節。
各種裝置、系統、服務的 Metrics 資料如何輕鬆且有效的收集？
隨著時間不斷增長的資料，如何在能保留使用價值的情況下，能在儲存效率、使用時的運算效率上，能被最佳化？
各種格式的日誌與資料，如何能更容易的分析及解讀？災情發生時有效的減少 MTTR (Mean Time To Recovery)？
避免沒有收集到足夠能分析問題的資訊，又要避免收集太多的資訊而造成這些資訊被破碎化的解讀，無法有效的分析及使用。
分析後的資料，如何能有效的透過視覺化的方式呈現，協助有價值的資訊能有效的被吸收。
主動發現異常的狀態，提早發現問題及減少災情的影響範圍。
首先因為『Elasticsearch』，整體 observability 的資料應該要能聚集在同一個地方，在分析及使用上才容易發揮最大效益，舉例來說 Traces 的資料要能進一步和 Logs 串接，追查問題時能一路接起來，甚至在透過 Machine Learning 分析時，能夠將各種資料一併來學習，絕對會比分散在各種不同系統的效果要來得好。
另外要針對巨量非結構化資料進行搜尋，這不只是使用 Apache Lucene 或建個 inverted index 就能處理掉全文檢索的工作，Elasticsearch 使用 Columnar store 方式儲存文字類型的資料、透過 BKD tree, document store, term vectors…等不斷優化 metrics 及 logs 資料分析及彙總的運算能力，資料生命週期的管理機制、分散式架構的擴展能力…這些 Elasticsearch 核心的能力，已經是目前日誌儲存分析的首選工具。
最後是統一的環境，Elastic Stack 產品之間本身的高度整合，這樣高度整合完成的生態圈會讓許多後續維護上較於便利，學習門檻也降低，這部份會是很大的一個好處。
Elasticsearch: 是個 NoSQL DB + 搜尋引擎 + Time-series DB，整體資料分析與運算處理的核心。
Kibana: 整體方案統一的 UI，不論是 APM, Logs, Metrics, 以及這些 Stack 的管理功能，都可以透過這個入口來進行操作。
APM: 負責收集 Traces 的資料，包含交易的追縱、分散式架構資訊的追縱、也包含透過網頁端收集 User experience data。
Beats: 協助收集各種 Logs data, Metrics data, Uptime data, Synthetic data。
Elastic Agent: 新一代將取代 Beats 收集 Logs, Metrics 的工具。
並透過以上的這些產品及工具，能夠建構出如下圖 Elastic Observability 所提供整體的服務。
