Kubernetes叢集的監控報警策略最佳實踐
本文為Kubernetes監控系列的第二篇文章。系列資料夾例如以下：
Kubernetes叢集的監控報警策略最佳實踐（本篇）
Kubernetes中的服務發現與故障排除（敬請期待）
Docker與Kubernetes在WayBlazer的使用案例（敬請期待）
監控是每一個優質基礎設施的基礎，是達到可靠性層次的基礎。
監控有助於降低對突發事件的響應時間，實現對系統問題的檢測、故障排除和除錯。
在基礎設施高度動態的雲時代。監控也是容量規劃的基礎。
有效的警報是監控策略的基石。當你轉向容器和Kubernetes編排環境，你的警報策略也須要演進。正是由於下面幾個核心原因。當中很多我們在"怎樣監視Kubernetes"中進行了講述：
可見性：容器是一個黑盒。
傳統工具僅僅能針對公共監控端點進行檢查。假設想深入監控相關服務，則須要採取不一樣的方法。
新的基礎架構層：如今服務和主機之間有一個新的層：容器和容器編排服務。
這些是你須要監控的新內部服務，你的監控系統須要瞭解這些服務。
動態重排程：容器沒有像之前那樣的服務節點。所以傳統的監控不能有效地工作。沒有獲取服務度量標準的靜態端點，沒有執行服務例項的靜態數量（設想一個金絲雀公佈或自己主動伸縮設定）。在某節點中一個程序被kill是正常的。由於它有非常大的機會被又一次排程到基礎設施的其它節點。
元資料和標籤：隨著服務跨多個容器，為全部這些服務加入系統級別的監控以及服務特定的度量標準，再加上Kubernetes帶來的全部新服務。怎樣讓全部這些資訊對我們有所幫助？有時你希望看到分佈在不同節點容器中的服務的網路請求度量，有時你希望看到特定節點中全部容器的同樣度量。而不關心它們屬於哪個服務。這就須要一個多維度量系統，須要從不同的角度來看待這些指標。假設通過Kubernetes中存在的不同標籤自己主動標記度量標準，而且監控系統能夠了解Kubernetes元資料，那麼僅僅須要在每種情況下依照須要聚合和切割度量標準就能夠實現多維度度量。
考慮到這些問題。讓我們建立一組對Kubernetes環境至關重要的報警策略。
我們的Kubernetes報警策略教程將涵蓋：
應用程式層度量標準的報警
Kubernetes上執行的服務的報警
Kubernetes基礎設施的報警
在主機/節點層上的報警
最後我們還將通過檢測系統呼叫問題來了解怎樣通過報警加速故障排除。
下面演示樣例是一個公共REST API端點監控警報，監控prod命令空間中的名為javaapp的deployment，在10分鐘內假設延遲超過1秒則報警。
全部這些報警高度依賴於應用程式、工作負載模式等等，但真正的問題是怎樣在全部服務中一致性地獲取資料。
在理想環境中，除了核心監控工具之外。無需再購買綜合監控服務就可以獲得這一套關鍵指標。
這個類別中常常出現的一些指標和報警是：
服務對應時間
服務可用性
SLA合規性
每秒請求的成功/失敗數
沒錯。假設想知道服務的全域性執行和執行情況，就須要利用監視工具功能依據容器元資料將度量標準進行聚合和分段。
如 第一篇文章所述。Kubernetes將容器標記為一個deployment或者通過一個service進行暴露，在定義報警時就須要考慮這些因素。比如針對生產環境的報警（可能通過名稱空間進行定義）。
下面是Cassandra叢集的演示樣例：
假設我們在Kubernetes、AWS EC2或OpenStack中執行Cassandra。則衡量指標cassandra.compactions.pending存在每一個例項上，可是如今我們要檢視在prod名稱空間內的cassandra複製控制器中聚合的指標。這兩個標籤都來自Kubernetes，但我們也能夠更改範圍，包含來自AWS或其它雲提供商的標籤，比如可用區域。
這個類別中常常出現的一些指標和警報是：
HTTP請求數
資料庫連線數、副本數
執行緒數、檔案描寫敘述符數、連線數
中介軟體特定指標：Python uwsgi worker數量。JVM堆大小等
另外，假設正在使用外部託管服務。則非常可能須要從這些提供程式匯入度量標準。由於它們可能還有須要做出反應的事件。
由Kubernetes處理的服務
1.1 是否有足夠的Pod/Container給每一個應用程式執行？
Kubernetes能夠通過Deployments、Replica Sets和Replication Controllers來處理具有多個Pod的應用程式。它們之間差別比較小。能夠使用它們來維護執行同樣應用程式的多個例項。執行例項的數量能夠動態地進行伸縮，甚至能夠通過自己主動縮放來實現自己主動化。
執行容器數量可能發生變化的原因有多種：由於節點失敗或資源不足將容器又一次排程到不同主機或者進行新版本號的滾動部署等。假設在延長的時間段內執行的副本數或例項的數量低於我們所需的副本數，則表示某些元件工作不正常（缺少足夠的節點或資源、Kubernetes或Docker Engine故障、Docker映象損壞等等）。
在Kubernetes部署服務中。跨多個服務進行例如以下報警策略對照是非常有必要的：
timeAvg(kubernetes.replicaSet.replicas.running) < timeAvg(kubernetes.replicaSet.replicas.desired)
正如之前所說，在又一次排程與遷移過程執行中的例項副本數少於預期是可接受的。所以對每一個容器須要關注配置項 .spec.minReadySeconds （表示容器從啟動到可用狀態的時間）。你可能也須要檢查 .spec.strategy.rollingUpdate.maxUnavailable 配置項，它定義了在滾動部署期間有多少容器能夠處於不可用狀態。
下面是上述報警策略的一個演示樣例，在 wordpress 名稱空間中叢集 kubernetes-dev 的一個deployment wordpress-wordpress。
1.2 是否有給定應用程式的不論什麼Pod/Container？
與之前的警報相似。但具有更高的優先順序（比如，這個應用程式是半夜獲取頁面的備選物件）。將提醒是否沒有為給定應用程式執行容器。
下面演示樣例，在同樣的deployment中新增警報，但不同的是1分鐘內執行Pod <1時觸發：
1.3 重新啟動迴圈中是否有不論什麼Pod/Container？
在部署新版本號時。假設沒有足夠的可用資源，或者僅僅是某些需求或依賴關係不存在，容器或Pod終於可能會在迴圈中持續又一次啟動。這樣的情況稱為“CrashLoopBackOff”。發生這樣的情況時，Pod永遠不會進入就緒狀態，從而被視為不可用，而且不會處於執行狀態，因此，這樣的場景已被報警覆蓋。雖然如此。筆者仍希望設定一個警報，以便在整個基礎架構中捕捉到這樣的行為。馬上了解詳細問題。這不是那種中斷睡眠的報警，但會有不少實用的資訊。
這是在整個基礎架構中應用的一個演示樣例，在過去的2分鐘內檢測到4次以上的又一次啟動：
監控Kubernetes系統服務
除了確保Kubernetes能正常完畢其工作之外。我們還希望監測Kubernetes的內部健康狀況。這將取決於Kubernetes叢集安裝的不同元件。由於這些可能會依據不同部署選擇而改變，但有一些基本元件是同樣的。
2.1 etcd是否正常執行？
etcd是Kubernetes的分散式服務發現、通訊、命令通道。監控etcd能夠像監控不論什麼分散式鍵值資料庫一樣深入，但會使事情變得簡單。
我們能夠進一步去監控設定命令失敗或者節點數，可是我們將會把它留給未來的etcd監控文章來描寫敘述。
2.2 叢集中有足夠的節點嗎？
節點故障在Kubernetes中不是問題。排程程式將在其它可用節點中生成容器。
可是，假設我們耗盡節點呢？或者已部署的應用程式的資源需求超過了現有節點？或者我們達到配額限制？
在這樣的情況下發出警報並不easy，由於這取決於你想要在待機狀態下有多少個節點，或者你想要在現有節點上推送多少超額配置。能夠使用監控度量值kube_node_status_ready和kube_node_spec_unschedulable進行節點狀態警報。
假設要進行容量級別報警，則必須將每一個已排程Pod請求的CPU和memory進行累加。然後檢查是否會覆蓋每一個節點，使用監控度量值kube_node_status_capacity_cpu_cores和kube_node_status_capacity_memory_bytes。
在主機/節點層上的報警
主要差別是如今警報的嚴重程度。
在此之前。系統服務宕機可能意味著你的應用程式停止執行而且要緊急處理事故（禁止有效的高可用性）。而對於Kubernetes來說當服務發生異常，服務能夠在主機之間移動。主機警報不應該不受重視。
讓我們看看我們應該考慮的幾個方面：
1. 主機宕機
假設主機停機或無法訪問，我們希望收到通知。
我們將在整個基礎架構中應用此單一警報。我們打算給它一個5分鐘的等待時間。由於我們不想看到網路連線問題上的嘈雜警報。
你可能希望將其降低到1或2分鐘，詳細取決於你希望接收通知的速度。
2. 磁碟利用率
這是略微複雜一些的警報。我們在整個基礎架構的全部檔案系統中應用此警報。我們將範圍設定為 everywhere，並針對每一個 fs.mountDir 設定單獨的評估/警報。
下面是超過80％使用率的通用警報。但你可能須要不同的策略。如具有更高閾值（95％）或不同閾值的更高優先順序警報（詳細取決於檔案系統）。
假設要為不同的服務或主機建立不同的閾值。僅僅需更改要應用特定閾值的範圍。
3. 一些其它資源
此類別中的常見資源是有關負載、CPU使用率、記憶體和交換空間使用情況的警報。假設在一定的時間內這些資料中的不論什麼一個顯著提升，可能就須要警報提醒您。
我們須要在閾值、等待時間以及怎樣判定噪聲警報之間進行折中。
假設您想為這些資源設定指標。請參考下面指標：
負載：load.average.1m, load.average.5m 和 load.average.15m
CPU：cpu.used.percent
memory：memory.used.percent 或 memory.bytes.used
swap：memory.swap.used.percent 或 memory.swap.bytes.used
一些人同樣使用這個類別監控他們部分基礎架構所在雲服務提供商的資源。
這可能是雲提供商的一個事件，但希望Kubernetes正在處理這個問題，而且僅僅須要花費一些時間來應對負載。
可是假設一些更棘手的問題出如今我們面前。我們能夠看到我們擁有的全部武器：提供者狀態頁面、日誌（希望來自中心位置）、不論什麼形式的APM或分散式追蹤（假設開發者安裝了程式碼或者外部綜合監測）。然後，我們祈禱這一事件在這些地方留下了一些線索。以便我們能夠追溯到問題出現的多種來源原因。
我們怎麼能夠在警報被解除時自己主動dump全部系統呼叫？系統呼叫是所發生事情的真實來源，並將包含我們能夠獲得的全部資訊。通過系統呼叫有可能發現觸發警報的根本問題所在。Sysdig Monitor同意在警報觸發時自己主動開始捕獲全部系統呼叫。
比如，能夠配置CrashLoopBackOff場景：
僅僅有當你安裝程式碼後。Sysdig Monitor代理才幹從系統呼叫攔截中計算出來對應的指標。
考慮HTTP響應時間或SQL響應時間。Sysdig Monitor代理程式在套接字上捕獲read()和write()系統呼叫。解碼應用程式協議並計算轉發到我們時間序列資料庫中的指標。這樣做的優點是能夠在不觸及開發者程式碼的情況下獲得儀表盤資料和警報：
能夠利用Kubernetes和雲服務提供商的元資料資訊來彙總和細分監控指標和警報將成為多層次有效監控的必要條件。我們已經看到怎樣使用標籤來更新我們已有的警報或建立Kubernetes上所需的新警報。
接下來，讓我們看看在Kubernetes編排環境中的典型服務發現故障排除的挑戰。
原文連結：https://sysdig.com/blog/alerting-kubernetes/
深入淺出Kubernetes及企業AI平臺落地實踐培訓
4月20日正式上課，點選閱讀原文連結就可以報名。