我們將向您展示如何完成基本的Kubernetes可觀察性任務:從運行在Kubernetes集群上的應用程序獲得黃金指標或黃金信號。我們不需要修改任何代碼，也不需要進行任何配置，只要安裝Linkerd(一個開源的超輕服務網格)就可以做到這一點。我們將介紹什么是服務網格，術語可觀察性是什么意思，以及這兩者在Kubernetes上下文中是如何關聯的。

用服務網格監控Kubernetes應用程序

如果你們剛剛適應了Kubernetes。恭喜你!但是現在你需要干什么?任何Kubernetes使用者者的第一個可觀察性任務之一是監視，您需要知道什么時候出現了問題，以便您可以快速地修復它們。

Kubernetes可觀察性是一個非常廣泛的話題，網上有很多關于可觀察性與監控、分布式跟蹤與日志記錄等之間的細微差別的討論。在本文中，我們將重點討論一個基本問題:在不更改任何代碼的情況下，從運行在集群上的應用程序獲得黃金指標或黃金信號。我們將安裝一個Linkerd，一個開源的超輕量級服務網格。與大多數服務網格不同，Linkerd只需要在集群上安裝幾分鐘，不需要配置。

雖然簡單，但Linkerd包含了一個非常強大的度量管道。一旦安裝完畢，它將通過觀察集群上運行的所有組件之間的HTTP(或gRPC)和TCP通信，自動檢測并報告成功率、流量級別和響應延遲。

linkd可以自動為服務報告度量標準通常被引用為服務的黃金度量標準。

什么是黃金度量標準?為什么它們很重要?

如果您已經知道黃金參數是什么，請跳過這一節!

黃金指標或黃金信號是您需要了解應用程序是否按預期啟動和運行的首要指標。這些度量為您提供了有關服務運行狀況的粗略信號，而不需要知道服務的實際功能。

Cindy Sridharan在她的關于監控和可觀察性的博文中寫道:當不直接驅動報警時，監控數據應該被優化，以提供系統整體健康狀況的鳥瞰圖。

谷歌SRE書定義的黃金指標為：

• 延遲——一種衡量服務速度快慢的方法。它是服務請求所花費的時間，通常以百分比來度量。第99百分位延遲為5ms意味著99%的請求在5ms或更短的時間內得到服務。
• 流量——讓你知道某項服務有多忙或需求有多復雜。通常用每秒對服務的請求數來衡量。
• 錯誤-請求失敗的數量。通常與總流量相結合來生成一個成功率——成功請求與遇到錯誤請求的比率。
• 飽和-衡量你的系統的負載

通過觀察服務的流量，Linkerd可以簡單地提供延遲、流量和錯誤的測量——樂觀地說，Linkerd以成功率的形式提供了這些數據。(第四個指標，飽和度，在監控討論中經常被忽略，因為它需要了解服務的內部情況，通常跟蹤其他指標，如流量和延遲。)

有時這些指標也被稱為服務的RED指標:

• Rate——您的服務每秒正在處理的請求數。
• Errors—每秒失敗的請求數。
• Duration——每個請求所花費時間的分布

不管你怎么稱呼它們，Linkerd的美妙之處在于，它不僅記錄這些指標的流量，而且匯總和報告它們，這樣我們就可以輕松地使用它們。(我們將在下面看到。)這使我們能夠監控我們的應用程序。一旦我們能夠監控我們的應用程序，我們就可以在出錯時收到報警;研究其長期性能;并對其可靠性和性能進行測試和改進。

黃金指標:最簡單的方法

安裝:訪問Kubernetes集群并安裝Linkerd CLI

我們假設您有一個正常運行的Kubernetes集群和一個指向它的kubectl命令。在本節中，我們將帶您瀏覽linkd入門指南的縮寫版本，以便在這個集群上安裝Linkerd和一個演示應用程序(我們將獲得最佳指標的應用程序)。

首先，安裝Linkerd命令行(或者，直接從Linkerd release頁面下載。):

curl -sL https://run.linkerd.io/install | sh
export PATH=$PATH:$HOME/.linkerd2/bin

驗證Kubernetes集群是否能夠處理linkd;安裝Linkerd;并驗證安裝:

linkerd check --pre
linkerd install | kubectl apply -f -
linkerd check

最后，安裝Emojivoto演示應用程序，這是我們希望獲得黃金指標的應用程序。如果仔細觀察下面的命令，您將看到我們實際上是在向應用程序添加linkerd(我們稱之為注入)，然后將應用程序部署到Kubernetes。(如果您想知道這是如何工作的，請查看我們的文檔https://linkerd.io/2/tasks/adding-your-service/)。

curl -sL https://run.linkerd.io/emojivoto.yml \
| linkerd inject - \
| kubectl apply -f -

嗯，就是這樣。這就是您需要的所有工具，您的應用程序，并能夠訪問您的黃金指標!現在讓我們來看看他們。

在Grafana查看度量

想要看到所有這些有用的圖表和儀表板嗎?沒有問題!運行linkd dashboard -show grafana并打開命令輸出的鏈接。您將看到Linkerd的頂層儀表盤，其中包含它所收集的指標的總體和每個名稱空間的細分。向下滾動到我們應用程序的命名空間(ns/emojivoto)，觀察以下圖表:

通過linkd CLI查看指標

我們還可以使用linkd stat命令查看應用程序的指標。

所有這些數據也可以在Linkerd's dashboard中找到，你可以通過運行Linkerd dashboard來訪問:

 

看看Grafana圖表(或linkd儀表盤)，你可以立即看到voting服務做得不是很好-它的成功率相當低!向我們的應用程序中添加黃金指標可以立即讓我們看到應用程序中可能出現的問題。

真的這么簡單嗎?答案是肯定的!我們所需要做的就是安裝Linkerd并將其注入到我們的應用程序中。在底層，當linkd被添加到一個服務時，它會自動檢測與服務的pod之間的任何HTTP和gRPC調用。由于它能夠解析這些協議，它可以記錄這些調用的響應類和延遲，并將它們聚合在一起，在這種情況下，將它們合并到一個名為Prometheus的時間序列數據庫的小型內部實例中。當您通過Linkerd的儀表板和CLI查看黃金指標時，Linkerd會從這個內部的Prometheus實例中獲取它們，在不修改應用程序代碼的情況下為您提供所有這些指標。

Linkerd還能做什么?

我們已經看到了如何使用Linkerd來獲得黃金指標，這是獲得系統可觀察性的第一步，也就是說，獲得復雜應用程序中正在發生的事情的高級視圖。但指標只是個開始。當您繼續您的監視和可觀察性旅程時，您一定會遇到另外兩個常用的工具:日志和分布式鏈路跟蹤。

分布式跟蹤涉及到檢測應用程序，以便測量請求在服務中花費的時間長度。當我們的應用程序使用許多相互通信的微服務時，跟蹤是一個很好的工具，可以用來調試緩慢的請求，并找出哪個服務是瓶頸。Linkerd可以幫助分布式跟蹤，盡管一個服務網格在分布式跟蹤方面做的不多。

類似于分布式跟蹤，Linkerd也提供了一個強大的動態請求跟蹤工具tap。tap命令類似于用于微服務的tcpdump:它允許您查看發送到或來自特定服務的實時請求(示例)。Tap是在生產中調試Kubernetes服務的強大工具。

最后，應用程序日志當然是開發人員在懷疑某個特定進程不正常時首先要做的事情之一。當運行一個服務網格時，有時候查看網格內部發生了什么是很有用的。雖然Linkerd不能為你提供應用程序日志，但Linkerd logs命令提供了一種簡單的方法，至少可以查看Linkerd內部發生了什么。