在認識了 Kubernetes 的基本概念，跟現代自然語言處理（Natural Language Processing, NLP）技術以及大型語言模型（Large Language Models, LLM）和檢索增強生成（Retrieval-Augmented Generation, RAG）之後。

接著要來介紹一下，近期才接觸的一個新領域，雖然這個領域已經出現了好一陣子，不過因為看到Opentelemetry所以接觸到這個新領域。這個領域就是「可觀測性」，這個詞聽起來新鮮，過去我們常講「監控」，難道我們在可觀測性就不監控了嗎？

那倒不是，在深入聊到可觀測性之前，先來說說為什麼會有可觀測性的出現，因為在過去我們採用的軟體架構多為單體式架構，也就是將所有業務邏輯功能都寫在一個應用程式中。我們可以透過監控的方式，使用Prometheus搭配上Exporter觀測CPU、記憶體使用量或者是查看log，來判斷這個應用程式是否正常。單體式架構雖然簡單，但是發生故障時，則會造成整個應用程式都無法使用，想要單獨維修故障的地方也沒辦法。

因此既然這樣何不將一個應用程式拆成一個個負責特定業務邏輯的服務就好了呢？誰壞了就修誰，應用程式其他的部分依然可以繼續運作(聽起來挺好的？)。
這時候隨著雲端技術與容器化技術的發展，因為容器的輕量化與資源隔離特性，能夠將應用程式打包在一個輕量且資源獨立的容器中，也就能夠更好達成上述提到的將一個應用程式拆成多個負責特定業務邏輯的服務，此外這些微服務能夠透過API互相呼叫或者其他方式來溝通，後續這些容器我會稱作「微服務」。

從這時候也就慢慢從單體式架構慢慢走向了微服務架構的世界了，但是俗話說的好，人沒有十全十美，魚與熊掌不可兼得，何況是軟體架構的問題，如果有一種萬用的架構，能夠應對所有的情況就太好了。隨著應用程式越來越龐大，微服務也越來越多，原本你在單體式架構底下就充其量就是一個應用程式，無論是環境或者是應用程式本身，相較於微服務架構，只是因為沒有高可用、彈性也比較不好，但是單體式架構單純。

現在把應用程式拆成一堆微服務，有了彈性、也有了高可用，卻也搞得更複雜了，無法像過去一樣只單純監控一個應用程式可能就能解決問題。所以我們希望有一種方法不只是只有知道CPU跟記憶體的使用量、日誌的回饋，我還希望可以知道程式跑到哪裡可能是造成問題的元兇，舉例來說可能是因為A微服務的處理資料過久成為瓶頸，導致整個系統看起來好像沒問題，可是他老哥在拖，又或者是A微服務在呼叫B微服務的過程中發生什麼事情，而這個方法也就是「可觀測性」。

過去監控的能力我要有，我還要有能夠可以觀測到整個系統更詳細的地方，最好是一眼可以看出來問題點，簡單來說就是我全都要

我們來看看維基百科是如何定義可觀測性

可觀測性（observability）是指系統可以由其外部輸出推斷其其內部狀態的程度。

看到這邊，是不是跟黑白箱也有點類似呢？在過去我們不需要知道內部的細節，單純靠輸出去推測應用程式發生什麼問題，我從結果去推測箱子裡面發生什麼事情。可是到了今日我們需要的已經不只是這樣，我們想要透過輸出了解更多箱子內部的細節，就像我能直接看到箱子內部的狀況。

介紹完可觀測性，接下來就是要來介紹常見的可觀測性工具Opentelemetry。