前言 & 淺談 Observability
參賽背景
去年參加第 12 屆的 iT邦幫忙鐵人賽，在飽受煎熬的度過 30 天之後，沒想過會要再參加下一屆，今年在經歷超過 100 次想放棄的念頭之後，在 9/15 最後一天報名截止日，填了報名表單，按下了送出，於是在 9/16 當天開始動筆寫下這篇文章。
(你沒看錯，就是學不會教訓，第二次參賽了還不懂得要先累積一些文章…)
本來少女人妻這次想落跑，今年換我把他推進坑！(不知她是誰的，她是我們上一屆的團長、也是推我入鐵人坑的兇手!)
今年除了我們去年團隊的三個成員，另外多找了三位新成員，總共六人報名，要團體完賽的難度加倍…夥伴們加油！也歡迎大家多鼓勵餵食我們！
什麼是 Observability (可觀察性) ?
最近幾年，特別是 2019~2020 年時，Observability 這個字變得非常的熱門，一方面微服務架構的普及化，傳統的系統服務監控方式開始發現不足以應付這樣複雜的系統，另一方面 DevOps 的理念及各種實踐方法也愈來愈被大家重視，因此如何能有效的掌握系統的運作狀態，也就被受重視。
針對 Observability 字面上可以簡單的解讀為：
透過系統外部所揭露資訊的觀察，能有效的掌握到系統內部的運作狀態
有不少針對 Monitoring (監控) 與 Observability (可觀察性) 進行比較的討論，有人覺得根本是一樣的，這個 observability 只是個 buzzword，而我這邊和大家分享一下我自己對於這兩個字的解讀。
Monitoring，可以比喻像是我們透過心電圖、心跳、血壓…等各種方式來掌握一個人的生命狀態，透過身體本身就會產生的各種訊息，來觀察我們身體的狀態，用來解讀甚至能監控我們身體健康情況，一但有異常就能即時發現，甚至是可以當作生病時找尋病源的參考資訊。
Observability，重點是 Observable (可被觀察的)，如果今天是一個鋼鐵人，身穿盔甲，我們從外部測不到心跳、心電、血壓，這樣也就缺少了可被觀察的能力。
也就是說，讓身體的數據可以被取得、可以被觀察，也就是 Observability，並且因為有這樣的能力，我們也才有辦法做 Monitoring，因此若只是使用一堆 Monitoring 的工具，把系統的資訊給拉成一個個的 Dashboard，這樣並不適合叫做提升 Observability，而透過工具讓本來很不容易取得的資訊，能更容易的被觀察、分析、監控，甚至在服務或應用程式的設計上，將有被觀察意義的資訊給揭露出來，讓負責維護系統的人能有效的掌握系統狀況、盤查問題，這才是有效的提升系統的 Observability。
另外參考 Google Cloud Architecture Center 中 DevOps Guides [1] 對針這兩個詞的定義：
Monitoring is tooling or a technical solution that allows teams to watch and understand the state of their systems. Monitoring is based on gathering predefined sets of metrics or logs.
Observability is tooling or a technical solution that allows teams to actively debug their system. Observability is based on exploring properties and patterns not defined in advance.
有提到一個重點，就是『事先定義』，Observability 也就是擁有能夠探索未事先定義的屬性與模式的能力。
此系列文章的目的
這次會以 Observability 當作主題，主要是喬叔自己在軟體領域 20 多年來，在實務中深感 Observability 的重要，因此希望一方面透過這個主題，能將這方面的經驗與觀念整理出來，另一方面也想透過寫這篇文章時，能再次精煉我自己對於 Elastic Stack 的熟練程度，因此這系列會以 Elastic Stack 來當作提升系統 Observability 的解決方案，另外不會去和其他的競品比較，在這邊要先要解釋一下，Elastic Stack 絕對不會是唯一合適的選擇，而我會選擇他，是因為他提一個整合度、生態圈都蠻完整的整體解決方案，最重要的是能較快速的將好的理念實現出來，能實際幫助到團隊、產品、客戶，盡快產生出實際的價值，希望這系列的文章能幫助到有需要的人。
參考資料
Last updated