在本文中，咱們將向您展現如何完成基本的Kubernetes可觀察性任務:從運行在Kubernetes集羣上的應用程序得到黃金指標或黃金信號。咱們不須要修改任何代碼，也不須要進行任何配置，只要安裝Linkerd(一個開源的超輕服務網格)就能夠作到這一點。咱們將介紹什麼是服務網格，術語可觀察性是什麼意思，以及這二者在Kubernetes上下文中是如何關聯的。java
用服務網格監控Kubernetes應用程序
若是大家剛剛適應了Kubernetes。恭喜你!可是如今你須要幹什麼?任何Kubernetes使用者者的第一個可觀察性任務之一是監視，您須要知道何時出現了問題，以便您能夠快速地修復它們。web
Kubernetes可觀察性是一個很是普遍的話題，網上有不少關於可觀察性與監控、分佈式跟蹤與日誌記錄等之間的細微差異的討論。在本文中，咱們將重點討論一個基本問題:在不更改任何代碼的狀況下，從運行在集羣上的應用程序得到黃金指標或黃金信號。咱們將安裝一個Linkerd，一個開源的超輕量級服務網格。與大多數服務網格不一樣，Linkerd只須要在集羣上安裝幾分鐘，不須要配置。數據庫
雖然簡單，但Linkerd包含了一個很是強大的度量管道。一旦安裝完畢，它將經過觀察集羣上運行的全部組件之間的HTTP(或gRPC)和TCP通訊，自動檢測並報告成功率、流量級別和響應延遲。微信
linkd能夠自動爲服務報告度量標準一般被引用爲服務的黃金度量標準。app
什麼是黃金度量標準?爲何它們很重要?
若是您已經知道黃金參數是什麼，請跳過這一節!curl
黃金指標或黃金信號是您須要瞭解應用程序是否按預期啓動和運行的首要指標。這些度量爲您提供了有關服務運行情況的粗略信號，而不須要知道服務的實際功能。tcp
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內部發生了什麼。
最後
在這篇博文中，咱們討論瞭如何輕鬆得到運行在Kubernetes集羣上的應用程序和服務的最佳指標。這是你進行服務可觀察之旅的第一步。但願這篇博文中的信息可以幫助您啓動並可靠的運行Kubernetes服務。
推薦
本文分享自微信公衆號 - 雲原生技術愛好者社區（programmer_java）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。