原文發表于kubernetes中文社區，為作者原創翻譯 ，原文地址
更多kubernetes文章，請多關注kubernetes中文社區
目錄
1. 資源和利用率指標
2. 狀態指標
3. 控制平面指標
4. 控制平面健康狀況
etcd集群中是否有leader
API請求延遲
作業佇列延遲
調度程式問題
5. 事件
6. 應用程式指標
總結
Circonus最近對Kubernetes運營商進行的一項調查中，收集哪些健康狀況指標是運營商面臨的最大挑戰之一，考慮到Kubernetes每天可以生成數百萬個指標，這不足為奇，
在本文中，我們將分享哪些健康指標對于Kubernetes運營商最關鍵，
1. 資源和利用率指標
資源和利用率指標來自內置的metrics API，由Kubelets本身提供，大多數時候，我們僅將CPU使用情況用作健康狀況的指標，但是監視記憶體使用情況和網路流量也很重要，
| 指標 | 名稱 | 描述 |
|---|---|---|
| CPU使用率 | usageNanoCores | 節點或Pod每秒使用的CPU核數， |
| CPU容量 | capacity_cpu | 節點上可用的CPU內核數量（不適用于Pod）， |
| 記憶體使用情況 | used{resource:memory,units:bytes} | 節點或Pod使用的記憶體量（以位元組為單位）， |
| 記憶體容量 | capacity_memory{units:bytes} | 節點可用的記憶體容量（不適用于Pod），以位元組為單位， |
| 網路流量 | rx{resource:network,units:bytes} tx{resource:network,units:bytes} | 節點（或Pod）看到的總網路流量（已接收（傳入）流量和已傳輸（傳出）流量），以位元組為單位， |
CPU使用率是重要的健康狀況指標，這是最容易理解的：你應該跟蹤節點正在使用多少CPU，原因有兩個，首先，你不希望耗盡應用程式的處理資源，如果你的應用程式受到CPU的限制，則需要增加CPU分配或向集群添加更多節點，其次，你不希望CPU閑置在那里，
2. 狀態指標
kube-state-metrics是一個組件，可提供有關集群物件（node，pod，DaemonSet，namespaces等）狀態的資料，
| 指標 | 名稱 | 描述 |
|---|---|---|
| 節點狀態 | kube_node_status_condition {status:true,condition:OutOfDisk| MemoryPressure|PIDPressure| DiskPressure|NetworkUnavailable} | 當status為true時，指示該節點當前正在經歷該條件， |
| 回圈崩潰(Crash Loops) | kube_pod_container_status_waiting_reason {reason： CrashLoopBackOff} | 指示pod中的容器是否正在發生回圈崩潰， |
| 任務狀態（失敗） | kube_job_status_failed | 指示任務是否失敗， |
| 持久卷狀態（失敗） | kube_persistentvolume_status _phase {phase：Failed} | 指示持久卷是否失敗， |
| Pod狀態（Pending） | kube_pod_status_phase{phase:Pending} | 指示Pod是否處于掛起狀態， |
| Deployment | kube_deployment_metadata _generation | 代表Deployment的序列號， |
| Deployment | kube_deployment_status_observed_generation | 代表控制器觀察到的當前Deployment生成的序列號， |
| DaemonSet期望的節點數 | kube_daemonset_status_ desired_number_scheduled | DaemonSet期望的節點數， |
| DaemonSet當前的節點數 | kube_daemonset_status_ current_number_scheduled | DaemonSet運行中的節點數， |
| 期望的StatefulSet副本 | kube_statefulset_status_replicas | 每個StatefulSet期望的副本數， |
| 準備就緒的StatefulSet副本 | kube_statefulset_status_replicas _ready | 每個StatefulSet準備好的副本數， |
使用這些度量標準，你應該對以下指標監視并發出警報：崩潰回圈，磁盤壓力，記憶體壓力，PID壓力，網路不可用，任務失敗，持久卷失敗，Pod掛起，Deployment故障，DaemonSets未準備好和StatefulSets未準備好，
3. 控制平面指標
Kubernetes控制平面包含Kubernetes的“系統組件”，可以幫助進行集群管理，在Google或Amazon提供的托管環境中，控制平面由云提供商管理，你通常不必擔心監視這些指標，但是，如果你管理自己的集群，則需要了解如何監視控制平面，
| 指標 | 名稱 | 描述 |
|---|---|---|
| etcd集群是否有leader | etcd_server_has_leader | 指示該成員是否知道其leader是誰， |
| etcd集群中leader變動總數 | etcd_server_leader_changes_ seen_total | etcd集群中leader變更總數， |
| API延遲數 | apiserver_request_latencies_count | API請求總數；用于計算每個請求的平均延遲， |
| API延遲總和 | apiserver_request_latencies_sum | 所有API請求持續時間的總和；用于計算每個請求的平均延遲， |
| 佇列等待時間 | workqueue_queue_duration_ seconds | 每個控制器管理器中的作業佇列等待所花費的總時間， |
| 佇列持續時間 | workqueue_work_duration_ seconds | 每個控制器管理器中的作業佇列處理操作所花費的總時間， |
| 調度失敗Pod的總嘗試次數 | scheduler_schedule_attempts _total {result：unschedulable} | 調度程式嘗試在節點上調度失敗了Pod的總嘗試次數， |
| Pod調度延遲 | scheduler_e2e_scheduling_ delay_microseconds（<v1.14） 或 scheduler_e2e_scheduling_ duration_seconds | 將Pod調度到節點上所花費的總時間， |
4. 控制平面健康狀況
你應該監視控制平面上的以下健康狀況：
etcd集群中是否有leader
etcd集群應始終有一個leader（在更改leader的程序中除外，這種情況很少見），你應該密切注意所有etcd_server_has_leader指標，因為如果很多集群成員沒有leader，那么集群性能將會下降，另外，如果你在etcd_server_leader_changes_seen_total中看到leader變更很多次，則可能表明etcd集群存在連接性或資源問題，
API請求延遲
如果將apiserver_request_latencies_count劃分為apiserver_request_latencies_sum，則將獲得API服務器每個請求的平均延遲，跟蹤隨時間不斷變化的平均請求延遲可以讓你知道服務器何時不堪重負，
作業佇列延遲
作業佇列是由controller manager管理的佇列，用于處理集群中的所有自動化流程，監視workqueue_queue_duration_seconds的增加，將使你知道佇列延遲何時增加，如果發生這種情況，你可能需要深入研究controller manager日志以查看發生了什么，
調度程式問題
調度程式有兩個方面值得關注，首先，你應該監視scheduler_schedule_attempts_total {result：unschedulable}，因為無法調度的Pod的增加可能意味著你的集群存在資源問題，其次，你應該使用上面指示的延遲指標之一來監視調度程式延遲，Pod調度延遲的增加可能會導致其他問題，也可能表明集群中存在資源問題，
5. 事件
除了從Kubernetes集群中收集數值指標外，從集群中收集和跟蹤事件也很有用，集群事件可以幫助你監視Pod生命周期并觀察重大Pod故障，并且監視從集群流出的事件的速率可以是一個很好的預警指標，如果事件發生率突然顯著變化，則可能表明發生了問題，
6. 應用程式指標
與我們上面檢查的指標和事件不同，應用程式指標不是從Kubernetes本身發出的，而是從集群運行的作業負載發出的，從應用程式的角度來看，這種監控可以是你認為重要的任何事情：錯誤回應，請求延遲，處理時間等，
關于如何收集應用程式度量標準，有兩種方式，第一個是，應該將指標資料從應用程式“推送”到收集端點，這意味著必須將像StatsD這樣的客戶端與每個應用程式捆綁在一起，以提供一種將指標標準資料推出該應用程式的機制，該技術需要更多的管理開銷，以確保正確地檢測集群中運行的每個應用程式，因此它在集群管理器中不受歡迎，
第二種是，指標收集原理（正在被越來越廣泛地采用），指標應由收集代理從應用程式中“拉取”，這使應用程式更易于撰寫，因為它們所要做的只是適當地發布了它們的指標標準，但是應用程式不必擔心這些度量標準是如何被提取或洗掉的，這是OpenMetrics的作業方式，也是Kubernetes集群指標收集的方式，當此技術與收集代理的服務發現相結合時，它將創建一種功能強大的方法，用于從集群應用程式中收集你需要的任何型別的指標，
總結
Kubernetes每天可以生成數百萬個新指標，這會帶來兩個大挑戰，首先，許多常規的監視系統無法正確監視Kubernetes集群的大量指標，其次，資料"龐雜"使你難以跟上并知道哪些指標最重要，
你的Kubernetes監視解決方案必須具有處理所有這些資料的能力，并能夠自動分析，圖形化和警告要注意的最關鍵指標，這樣，你就知道自己已經收集了期望的一切，過濾掉了不必要的資料，并自動縮小了相關資料的范圍，因此，你可以節省大量時間，并確保一切都能正常進行，
譯文鏈接：https://thenewstack.io/which-kubernetes-health-metrics-should-be-monitored/
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/247598.html
標籤：AI
上一篇：演算法考試復習