在本章中，我們將詳細了解這些指標，并使用 Emojivoto 示例應用程序了解它們的含義。

我們先簡單了解下服務健康黃金指標的經典定義：

• Latency（延遲）
• Error rate（錯誤率）
• Traffic volume（流量）
• Saturation（飽和度）

Linkerd 的價值不僅僅在于它可以提供這些指標，畢竟，我們可以非常簡單地直接檢測應用程序代碼。相反，Linkerd 的價值在于它可以在整個應用程序中以統一的方式提供這些指標，并且不需要更改應用程序代碼。換句話說，無論是誰編寫的，它使用什么框架，它是用什么語言編寫的，以及它做什么，Linkerd 都可以為你的服務提供這些指標。

接下來讓我們來依次檢查下黃金指標，看看 Linkerd 是如何測量它們的。

Latency

延遲是響應請求所需的時間，對于 Linkerd，是通過 Linkerd 代理向應用程序發送請求和接收響應之間經過的時間來進行衡量的，因為它在請求之間可能會有很大差異，所以指定時間段的延遲通常作為統計分布來衡量，并報告為此分布的百分位數。Linkerd 能夠報告常用的延遲指標例如 p50、p95、p99 和 p999，對應于 50、95、99 和 99.9 的百分位數。請求的延遲分布，這些被稱為“尾部延遲”，通常是報告大規模系統行為的重要指標。

Error rate

錯誤率是被視為錯誤響應的百分比，對于 Linkerd，是通過 HTTP 狀態碼來衡量的：2xx? 和 4xx? 響應被認為是成功的，5xx 響應被認為是失敗的，當然反過來我們也可以說 Linkerd 報告的是成功率而不是錯誤率。

需要注意雖然 4xx HTTP 響應碼對應于各種形式的“未找到您請求的資源”，但這些是服務器方面的正確響應，而不是錯誤響應。因此，Linkerd 認為這些請求是成功的，因為服務器按照它的要求做了。

Traffic volume

流量是對系統的需求量度，在 Linkerd 的上下文中，這被測量為請求率，例如每秒請求數 (RPS)。Linkerd 簡單地通過計算它代理到應用程序的請求來計算這一點。

另外也需要注意由于 Linkerd 可以自動重試請求，因此它提供了兩種流量度量：實際（對應請求，包括重試）和有效（對應不重試的請求）。如果客戶端向中間有 Linkerd 的服務器發出請求，則有效計數將是客戶端發出的請求數；實際計數將是服務器收到的請求數。

Saturation

飽和度是對服務可用的總資源消耗的度量，例如 CPU、內存。與其他服務網格一樣，Linkerd 沒有直接的機制來衡量飽和度，但是，延遲通常是一個很好的近似值。谷歌 SRE 書籍說：

延遲增加通常是飽和的主要指標，在某個小窗口（例如一分鐘）內測量你的第 99 個百分位響應時間可以給出非常早期的飽和信號。

所以我們這里主要使用另外三個黃金指標：成功率、請求率和延遲。

最后一點是，雖然 Linkerd 可以代理任何 TCP 流量，但這些黃金指標僅適用于使用 HTTP 或 gRPC 的服務。這是因為這些指標需要第 7 層或協議級別的理解才能計算。一個 HTTP 請求具有成功和不成功請求的概念，任意的 TCP 字節流不會。

Linkerd Dashboard 中查看指標

上面我們了解了這些指標，接下來我們再來看看前面部署的 Emojivoto 應用。

$ kubectl get pods -n emojivoto
NAME                        READY   STATUS    RESTARTS        AGE
emoji-696d9d8f95-5vn9w      2/2     Running   2 (5h11m ago)   41h
vote-bot-6d7677bb68-jvxsg   2/2     Running   2 (5h11m ago)   41h
voting-ff4c54b8d-jjpkm      2/2     Running   2 (5h11m ago)   41h
web-5f86686c4d-58p7k        2/2     Running   2 (5h11m ago)   41h

Emojivoto 應用是一個 gRPC 服務，一共包含三個微服務：

• web：用戶與之交互的前端服務
• emoji：提供表情列表的 API 服務
• voting：提供為表情投票的 API 服務

我們已經將該應用引入到網格中來了，能夠在 Linkerd 儀表板中查看 Emojivoto? 應用的指標了，當我們打開 Viz 的儀表板的時候，默認會顯示集群的所有命名空間列表，其中有一個非常大的區別是命名空間列表中的 emojivoto? 項目現在在 Meshed 列下顯示為 4/4。

命名空間列表

單擊 emojivoto 鏈接可查看命名空間的詳細信息，包括“章魚”圖，顯示服務如何通過網絡連接相互關聯的。請記住這張圖片，因為我們將使用 CLI 工具查看相同的信息。

章魚圖顯示 Emojivoto 服務之間的連接

此外還可以看到我們上面討論過的黃金指標：p50、p95 和 p99 延遲、服務的成功/錯誤率以及請求量，即每秒請求數(RPS)。從成功率一列可以看出其中一項服務有一些錯誤。

Emojivoto服務黃金指標

該 Deployment 級別信息是處理應用程序請求的所有 Pod 的指標的聚合，我們向下滾動頁面的時候，可以看到每個 Pod 對應的指標。我們可以通過增加 web 服務的副本數來進行驗證。

執行下面的命令將 web 服務增加到兩個副本：

$ kubectl scale deploy/web -n emojivoto --replicas=2

執行此命令后，儀表板將自行更新，Web 應用將在 Meshed 列下顯示為 2/2，此外，你將在 Pod 部分下看到另一個 Web pod。

Emojivoto web 增加到兩個副本

更新 Pods 副本后的 Emojivoto web

通過觀察 Deployments 和 Pods 部分的數據，可以看到 Deployments 中的指標數據的確就是 Pods 的指標聚合數據。最后我們再來看看 Linkerd 提供的 TCP 級別的指標，在 emojivoto 命名空間的頁面底部，會顯示 TCP 連接數以及每個 Pod 讀取和寫入的字節數。

Emojivoto Pods的TCP指標

TCP 的指標比 7 層的指標會更少，例如在任意 TCP 字節流中沒有請求的概念。盡管如此，這些指標在調試應用程序的連接級別問題時仍然很有用。

接下來我們將繼續探索儀表板并查看讓我們實時查看流量的 Tap 功能。

到目前為止，我們已經可以使用儀表板來獲取 Emojivoto? 應用程序中服務的聚合性能指標了。現在讓我們使用儀表板通過 Linkerd 提供的 tap 功能實時查看流量。

在儀表板中，我們可以看到 voting? 服務的成功率低于 100%，讓我們使用 tap 功能來查看對服務的請求，來嘗試弄清楚發生了什么。

voting服務的成功率

單擊 emojivoto? 應用的 voting? 鏈接可以深入了解詳細信息，我們將看到的第一件事是顯示 voting 微服務與應用程序中其他微服務之間關系的圖表。

voting微服務的連接和流量示意圖

在圖表下方，我們可以看到一個 LIVE CALLS? 的選項卡，其中顯示了對 voting 服務的實時調用！每次調用時，表中的行都會更新有關請求的相關信息，包括響應的 HTTP 狀態。

Voting 服務的實時調用

在我們詳細了解這些實時調用之前，我們可以點擊 Route Metrics? 選項卡來查看 voting? 服務的路由表以及每個路由的指標，在我們這里只有一個名為 Default 的路由，它是為每個服務創建的。在后面的章節中我們將介紹服務配置文件以及將它們添加到應用程序后會如何影響此選項卡的顯示。現在，我們只需要知道此選項卡存在就足夠了。

Voting 服務路由指標

現在我們知道了如何在儀表板中查找實時調用，現在我們來嘗試下看看是否可以找到其中一個失敗的調用并使用儀表板中的 tap? 功能。當我們看到對路徑 /emojivoto/v1.VotingService/VoteDoughnut 的請求，請單擊其右側的顯微鏡圖標跳轉到 Tap 頁面。

VoteDoughnut路徑

其實通過查看成功率這一列的數據很容易發現該路徑請求有錯誤。

Tap 頁面包含一個多個字段的表單，這些字段已根據我們點擊的特定請求的鏈接預先填充了，比如我們這里 Path、Namespace、Resource 等字段都已經被自動填充上了，下面還有一個輸出顯示正在運行的當前 Tap 查詢。

帶有預填充字段和當前Tap查詢的Tap頁面

現在我們點擊 Tap? 頁面頂部的 START? 按鈕，開始對投票服務的 /emojivoto.v1.VotingService/VoteDougNut? 路徑的請求，幾秒鐘后，下方的列表將開始填充 VoteDougNut 路徑的傳入請求。

Tap投票服務的請求集合

我們可以單擊左側的箭頭來查看包含請求信息的對話框。

失敗請求詳情

這就是通過 Linkerd 儀表板中使用 Tap 的方式，我們還可以繼續更改表單字段中的值并使用不同的查詢來查看不同的請求，例如我們可以將 Path? 字段中的 /emojivoto.v1.VotingService/VoteDoughnut? 值刪掉，并將 To Resource? 設置為 Deployment，當我們點擊開始按鈕后，我們將可以看到從 Web 服務發送的所有流量。

現在我們已經知道如何使用 Tap 查看服務的流量指標，接下來讓我們通過查看 Linkerd 的 Grafana 儀表板來了解這些指標是如何使用的。

Grafana 中展示指標

Linkerd 的 Viz 插件內置了 Grafana，Linkerd 使用 Grafana 為部署到 Kubernetes 的應用程序添加了額外的可觀察性數據。在瀏覽儀表板時，你可能已經注意到了 Grafana 圖標，這里我們以 emoji 微服務為例對 Grafana 圖表進行說明。

在 Linkerd 儀表板的 emojivoto? 命名空間中，單擊 emoji? 行最右側列中的 Grafana 圖標，會打開 Grafana 儀表板以顯示 emoji? 微服務的相關圖表，這些頁面上的圖表顯示了 Linkerd 儀表板中顯示的指標的時間序列數據，這里我們看到的就是 emoji 服務隨著時間推移的服務性能變化。

emoji服務的Grafana圖表

Grafana 儀表板上的圖表包括我們的標準黃金指標集：

• Success rate
• Request rate
• Latencies

隨時間查看黃金指標圖表的能力是了解應用程序性能的非常強大的工具。以時間序列的形式查看這些指標可以讓你了解，例如，當流量負載增加時服務的執行情況，或者在進行更新以添加功能或修復錯誤時，服務的一個版本與另一個版本的比較情況。

Grafana 儀表板的優點在于你無需執行任何操作即可創建它們，Linkerd 使用動態模板為每個注入 Linkerd 代理和部分服務網格的 Kubernetes 資源生成儀表板和圖表。我們可以在 Grafana 儀表板的左上角，單擊 Linkerd Deployment 鏈接以打開可用儀表板列表。

可用的Dashboards

比如我們可以點擊 Linkerd Pod? 儀表盤，查看與 emoji 服務相關的一個 Pod 的圖表，儀表板中顯示了單個 Pod 的相同的黃金指標，這與 Deployment 儀表板不同，因為 Deployment 儀表板顯示了與 Deployment 相關的所有 Pod 的匯總指標。

emoji服務關聯Pod的圖表

Linkerd CLI 命令查看指標

Linkerd 儀表板功能很強大，因為它在基于瀏覽器的界面中顯示了大量指標，如果你不想使用瀏覽器的話，那么我們可以使用 Linkerd CLI 命令行工具，CLI 在終端中提供了儀表板相同的功能。

我們可以使用如下所示的命令來顯示 emojivoto? 命名空間中從 Web 服務通過 /emojivoto.v1.VotingService/VoteDoughnut 路徑到投票服務的所有流量：

$ linkerd viz tap deployment/web --namespace emojivoto --to deployment/voting --path /emojivoto.v1.VotingService/VoteDoughnut
req id=3:0 proxy=out src=10.244.2.71:41226 dst=10.244.1.95:8080 tls=true :method=POST :authority=voting-svc.emojivoto:8080 :path=/emojivoto.v1.VotingService/VoteDoughnut
rsp id=3:0 proxy=out src=10.244.2.71:41226 dst=10.244.1.95:8080 tls=true :status=200 latency=1128μs
end id=3:0 proxy=out src=10.244.2.71:41226 dst=10.244.1.95:8080 tls=true grpc-status=Unknown duration=183μs response-length=0B
# ......

此外我們還通過使用 -o json 標志指定輸出數據為 JSON 格式，以獲取更多詳細信息，如下所示：

$ linkerd viz tap deployment/web --namespace emojivoto --to deployment/voting --path /emojivoto.v1.VotingService/VoteDoughnut -o json
{
  "source": {
    "ip": "10.244.1.108",
    "port": 59370,
    "metadata": {
      "control_plane_ns": "linkerd",
      "deployment": "web",
      "namespace": "emojivoto",
      "pod": "web-5f86686c4d-58p7k",
      "pod_template_hash": "5f86686c4d",
      "serviceaccount": "web",
      "tls": "loopback"
    }
  },
  "destination": {
    "ip": "10.244.1.95",
    "port": 8080,
    "metadata": {
      "control_plane_ns": "linkerd",
      "deployment": "voting",
      "namespace": "emojivoto",
      "pod": "voting-ff4c54b8d-jjpkm",
      "pod_template_hash": "ff4c54b8d",
      "server_id": "voting.emojivoto.serviceaccount.identity.linkerd.cluster.local",
      "service": "voting-svc",
      "serviceaccount": "voting",
      "tls": "true"
    }
  },
  "routeMeta": null,
  "proxyDirection": "OUTBOUND",
  "responseInitEvent": {
    "id": {
      "base": 6,
      "stream": 6
    },
    "sinceRequestInit": {
      "nanos": 686968
    },
    "httpStatus": 200,
    "headers": [
      {
        "name": ":status",
        "valueStr": "200"
      },
      {
        "name": "content-type",
        "valueStr": "application/grpc"
      },
      {
        "name": "grpc-status",
        "valueStr": "2"
      },
      {
        "name": "grpc-message",
        "valueStr": "ERROR"
      },
      {
        "name": "date",
        "valueStr": "Thu, 25 Aug 2022 08:52:05 GMT"
      }
    ]
  }
}
# ......

可以看到 JSON 輸出的信息要詳細得多，因為每個請求都會打印有關的多行信息，包括：

• HTTP 方法
• 流量的方向
• HTTP Header

讓我們再運行一個更粗粒度的 Tap 查詢，就像我們在儀表板中運行的查詢一樣。比如獲取 Web 服務的所有流量：

$ linkerd viz tap deploy/web -n emojivoto
req id=7:13 proxy=out src=10.244.1.108:33416 dst=10.244.1.88:8080 tls=true :method=POST :authority=emoji-svc.emojivoto:8080 :path=/emojivoto.v1.EmojiService/FindByShortcode
rsp id=7:13 proxy=out src=10.244.1.108:33416 dst=10.244.1.88:8080 tls=true :status=200 latency=708μs
end id=7:13 proxy=out src=10.244.1.108:33416 dst=10.244.1.88:8080 tls=true grpc-status=OK duration=35μs response-length=20B
req id=7:14 proxy=out src=10.244.1.108:59370 dst=10.244.1.95:8080 tls=true :method=POST :authority=voting-svc.emojivoto:8080 :path=/emojivoto.v1.VotingService/VoteMan
rsp id=7:14 proxy=out src=10.244.1.108:59370 dst=10.244.1.95:8080 tls=true :status=200 latency=809μs
end id=7:14 proxy=out src=10.244.1.108:59370 dst=10.244.1.95:8080 tls=true grpc-status=OK duration=65μs response-length=5B
# ......

上面的命令我們刪除了 --to? 和 --path? 這些參數，粒度更粗了，整個輸出將顯示所有進出 Web 服務的流量，包括 web? 和 emoji? 服務以及 web? 和 voting 服務之間的流量。

我們可以根據每行輸出中的 src? 和 dst? 字段查看流量的方向，我們也可以嘗試使用 -o json 標志再次運行查詢以查看 JSON 格式的輸出，并查看是否可以發現給定請求的流量方向。

上面我們了解了如何在終端中使用 tap? 命令實時顯示流量，我們還可以使用另外一個 linkerd viz top? 命令，該命令和 tap? 命令提供相同的信息，但格式與基于 Unix 的 top? 命令相同。換句話說，linkerd viz top 顯示了按最受歡迎的路徑排序的流量路線，我們來執行如下所示的命令進行查看：

$ linkerd viz top deploy/web -n emojivoto

viz top命令

同樣現在我們想在終端中查看儀表板中看到的延遲、成功/錯誤率和每秒請求數指標，又應該怎么操作呢？同樣 Linkerd CLI 提供了一個 stat? 命令可以幫助我們來執行該操作。讓我們通過獲取 emojivoto 命名空間中所有服務的指標來嘗試一下，如下所示：

$ linkerd viz stat deploy -n emojivoto
NAME       MESHED   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
emoji         1/1   100.00%   2.3rps           1ms           1ms           1ms          4
vote-bot      1/1   100.00%   0.3rps           1ms           1ms           1ms          1
voting        1/1    89.74%   1.3rps           1ms           1ms           1ms          4
web           2/2    93.51%   2.6rps           1ms           7ms           9ms          6

linkerd viz stat? 命令可以獲取到應用服務性能的最新指標數據，如果你想要獲取更多數據，可以添加 -o wide 標志來獲取這些 TCP 級別的詳細信息。

任何時候您想要獲得應用程序中服務性能的最新快照，您都可以使用 linkerd viz stat 來獲取這些指標。如果您想更深入地獲取寫入和讀取的字節數，可以添加 -o Wide 標志來獲取這些 TCP 級別的詳細信息。無論是否使用 -o wide 標志，都將始終顯示 TCP 連接。

$ linkerd viz stat deploy -n emojivoto -o wide
NAME       MESHED   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN   READ_BYTES/SEC   WRITE_BYTES/SEC
emoji         1/1   100.00%   2.3rps           1ms           1ms           1ms          4         229.0B/s         2680.8B/s
vote-bot      1/1   100.00%   0.3rps           1ms           3ms           3ms          1          24.3B/s          585.0B/s
voting        1/1    89.74%   1.3rps           1ms           1ms           1ms          4         121.4B/s          481.0B/s
web           2/2    92.95%   2.6rps           1ms           4ms           4ms          6         205.0B/s         5949.4B/s

同樣 stat? 命令也可以通過 --to? 參數來縮小查詢范圍，比如我們想要查詢從 web? 服務到 voting 服務的流量，可以使用如下所示的命令：

$ linkerd viz stat -n emojivoto deploy/web --to deploy/voting
NAME   MESHED   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
web       2/2    86.67%   1.0rps           1ms           4ms           4ms          2

可以看到輸出的數據和前面一樣，只是只有一行數據輸出，其中最值得注意的是，成功率這一列低于 100% 了。從這個輸出中，我們可以推斷出，當我們查看 emojivoto? 命名空間中的所有服務時，web? 服務的成功率是來自 voting? 和 emoji? 服務響應的總和。為了驗證這個假設，讓我們再運行一  個查詢，以僅查看從 web 服務到命名空間中所有其他服務的流量。

$ linkerd viz stat -n emojivoto deploy --from deploy/web
NAME     MESHED   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
emoji       1/1   100.00%   1.9rps           1ms           1ms           2ms          2
voting      1/1    83.05%   1.0rps           1ms           1ms           2ms          2

在這里我們可以看到，實際上，voting? 服務存在錯誤，而 emoji 服務則沒有。

stat? 命令是一個功能強大的工具，具有許多配置選項。我們可以運行 linkerd viz stat -h? 以查看可以運行 stat 的所有可用方式。

上面我們介紹了幾種不同的方式來查看被 Linkerd 網格化的應用的黃金指標數據。接下來我們將學習如何使用服務配置文件獲取每個路由的指標，通過為 Kubernetes 服務創建 ServiceProfile? 對象，我們可以指定服務可用的路由并為每個路由收集單獨的指標。到目前為止，我們只能看到 default? 路由上對服務的所有請求的指標。為 emojivoto? 服務配置 ServiceProfiles 后，我們將能夠看到每條路由的指標！