作者 Brendan Burns, Eddie Villalba, Dave Strebel and Lachlan Evenson
在本章中，我們討論了在Kubernetes中進行監視和記錄的最佳實踐。我們將深入探討各種監視模式，要收集的重要指標以及根據這些原始指標構建儀表板的細節。然後，我們總結一些爲Kubernetes集羣實施監視的示例。
Metrics Versus Logs
您首先需要了解日誌收集和指標收集之間的區別。它們彼此互補，但具有不同的目的。
Metrics
一段時間內測得的一系列數字
Logs
用於系統的探索性分析
當應用程序性能不佳時，需要同時使用指標和日誌記錄的一個示例。我們對該問題的第一個指示可能是在託管該應用程序的Pod上出現高延遲的警報，但是這些指標可能無法很好地指示該問題。然後，我們可以查看日誌以對應用程序發出的錯誤進行調查。
監控技巧
黑盒監視着重於從應用程序外部進行監視，這是監視系統中的CPU，內存，存儲等組件的傳統方法。黑盒監視對於在基礎架構級別進行監視仍然很有用，但是缺乏對應用程序運行方式的瞭解和上下文。例如，要測試集羣是否健康，我們可以安排一個Pod，如果成功，我們知道調度程序和服務發現在集羣中是健康的，因此我們可以假設集羣組件是健康的。
白盒監視着眼於應用程序狀態上下文中的詳細信息，例如HTTP請求總數，500個錯誤的數量，請求的延遲等等。通過白盒監控，我們可以開始瞭解我們系統狀態的“爲什麼”。它使我們可以問：“爲什麼磁盤已滿？”而不僅僅是“磁盤已滿”。
監控模式
您可能會看着監視說：“這有多難？我們一直在監控我們的系統。”是的，您今天使用的一些典型監控模式也適合您監控Kubernetes的方式。區別在於Kubernetes之類的平臺具有更大的動態性和瞬態性，您將需要改變有關如何監視這些環境的想法。例如，在監視虛擬機（VM）時，您希望VM處於24/7狀態，並保留其所有狀態。在Kubernetes中，Pod可能是非常動態且短暫的，因此您需要在適當的位置進行監視以處理這種動態和短暫的特性。
監視分佈式系統時，有兩種不同的監視模式需要關注。
由Brendan Gregg推廣的USE方法着重於以下方面：
· R—Rate· E—Errors· D—Duration
此方法專注於基礎結構監視，因爲將其用於應用程序級監視存在侷限性。USE方法描述爲“對於每種資源，請檢查利用率，飽和度和錯誤率。”此方法使您可以快速確定系統的資源限制和錯誤率。例如，要檢查羣集中節點的網絡運行狀況，您將需要監視利用率，飽和度和錯誤率，以便能夠輕鬆識別網絡堆棧中的任何網絡瓶頸或錯誤。USE方法是較大工具箱中的工具，不是您將用來監視系統的唯一方法。
Tom Willke推廣了另一種稱爲RED方法的監視方法。RED方法的方法集中在以下方面：
·R-Rate·E-Errors·D-Duration
該理念取自Google的四個黃金信號：
· Latency (服務請求需要多長時間)· Traffic (你的系統有多少需求)· Errors (失敗請求的速率)· Saturation (你的服務利用率如何)
例如，您可以使用此方法監視在Kubernetes中運行的前端服務，以計算以下內容：
·我的前端服務正在處理多少個請求？
·服務的用戶收到多少個500錯誤？
·服務是否被請求過度使用？
從上一個示例中可以看到，此方法更着重於用戶的體驗以及他們對服務的體驗。鑑於USE方法專注於基礎架構組件，而RED方法專注於監視應用程序的最終用戶體驗，因此USE和RED方法是相互補充的。
Kubernetes指標概述
現在我們知道了不同的監視技術和模式，下面讓我們看一下您應該在Kubernetes集羣中監視哪些組件。Kubernetes集羣由控制平面組件和工作節點組件組成。控制平面組件包括API服務器，etcd，調度程序和控制器管理器。工作程序節點由kubelet，容器運行時，kube-proxy，kube-dns和pod組成。您需要監視所有這些組件，以確保羣集和應用程序正常運行。
Kubernetes以多種方式公開這些指標，因此讓我們看一下可用於在集羣中收集指標的不同組件。
cAdvisor
Container Advisor或cAdvisor是一個開源項目，它爲節點上運行的容器收集資源和指標。cAdvisor內置在Kubernetes kubelet中，該kubelet在集羣中的每個節點上運行。它通過Linux控制組（cgroup）樹收集內存和CPU指標。如果您不熟悉cgroup，則它是Linux內核功能，可隔離CPU，磁盤I / O或網絡I / O的資源。cAdvisor還將通過內置在Linux內核中的statfs收集磁盤指標。這些是您無需真正擔心的實施細節，但是您應該瞭解這些指標的顯示方式以及可以收集的信息類型。您應該將cAdvisor視爲所有容器指標的真實來源。
Metrics Server
Kubernetes指標服務器和Metrics Server API替代了已棄用的Heapster。Heapster在實現數據接收器方面存在一些體系結構方面的劣勢，這導致了Heapster核心代碼庫中的許多供應商解決方案。通過在Kubernetes中實現資源和自定義指標API作爲聚合API來解決此問題。這允許在不更改API的情況下切換實現。
在Metrics Server API和Metrics服務器中需要了解兩個方面。
首先，Resource Metrics API的規範實現是指標服務器。指標服務器收集諸如CPU和內存之類的資源指標。它從kubelet的API收集這些指標，然後將它們存儲在內存中。Kubernetes在調度程序，Horizontal Pod Autoscaler（HPA）和Vertical Pod Autoscaler（VPA）中使用這些資源指標。
其次，自定義指標API允許監視系統收集任意指標。這允許監視解決方案構建自定義適配器，從而允許擴展到核心資源指標之外。例如，Prometheus構建了第一個自定義指標適配器，它使您可以基於自定義指標使用HPA。這將根據您的用例提供更好的擴展能力，因爲現在您可以引入基於Kubernetes外部指標的隊列大小和規模之類的指標。
現在有了一個標準化的Metrics API，這爲在普通的舊CPU和內存指標之外擴展提供了許多可能性。
kube-state-metrics
kube-state-metrics是一個Kubernetes插件，用於監視存儲在Kubernetes中的對象。在使用cAdvisor和指標服務器提供有關資源使用情況的詳細指標的情況下，kube-state-metrics專注於識別部署到集羣的Kubernetes對象的條件。
以下是kube-state-metrics可以爲您解答的一些問題：
pods
•集羣中部署了多少個Pod？
•有多少個pods處於掛起狀態？
•是否有足夠的資源來滿足Pod的請求？
Deployments
•有多少個Pod處於運行狀態而不是所需狀態？
•有多少個副本可用？
•已更新哪些部署？
Nodes
•我的工作節點的狀態是什麼？
•我的羣集中可分配的CPU內核是什麼？
•是否有不可計劃的節點？
Jobs
•什麼時候開始工作？
•工作何時完成？
•有多少工作失敗了？
在撰寫本文時，kube-state-metrics跟蹤了22種對象類型。這些總是在擴展，您可以在Github存儲庫中找到文檔。
我要監視哪些指標？
一個簡單的答案是“一切”，但是如果您嘗試監視太多，則會產生過多的噪聲，從而濾除您需要深入洞察的真實信號。當我們考慮在Kubernetes中進行監視時，我們想採取一種考慮以下因素的分層方法：
·物理或虛擬節點
·羣集組件
·羣集附件
·最終用戶應用程序
使用這種分層的監視方法，您可以更輕鬆地在監視系統中識別正確的信號。它使您可以使用更有針對性的方法來解決問題。例如，如果您的Pod處於掛起狀態，則可以從節點的資源利用率開始，如果一切正常，則可以定位集羣級組件。
以下是您要在系統中定位的指標：
·節點
•CPU利用率
•內存利用率
•網絡利用率
•磁盤利用率
·羣集組件
•etcd延遲
·羣集附件
•羣集自動縮放器
•入口控制器
·應用
•容器內存利用率和飽和度
•容器CPU利用率
•容器網絡利用率和錯誤率
•特定於應用程序框架的指標
監控工具
有許多可與Kubernetes集成的監控工具，並且每天都有更多的監控工具，這些工具基於它們的功能集可以更好地與Kubernetes集成。以下是一些與Kubernetes集成的流行工具：
Prometheus
Prometheus是最初在SoundCloud上構建的開源系統監視和警報工具包。自2012年成立以來，許多公司和組織都採用了Prometheus，該項目擁有非常活躍的開發人員和用戶社區。現在，它是一個獨立的開源項目，並且獨立於任何公司進行維護。爲了強調這一點並闡明項目的治理結構，Prometheus加入了Cloud Native，2016年，計算基金會（CNCF）是繼Kubernetes之後的第二個託管項目。
InfluxDB
InfluxDB是一個時序數據庫，旨在處理較高的寫入和查詢負載。它是TICK（Telegraf，InfluxDB，Chronograf和Kapacitor）堆棧的組成部分。InfluxDB旨在用作涉及大量時間戳數據的任何用例的後備存儲，包括DevOps監控，應用程序指標，IoT傳感器數據和實時分析。
Datadog
Datadog爲雲級應用程序提供監視服務，通過基於SaaS的數據分析平臺監視服務器，數據庫，工具和服務。
Sysdig
Sysdig Monitor是一個商業工具，可爲容器本機應用程序提供Docker監視和Kubernetes監視。Sysdig還允許您通過直接Kubernetes集成來收集，關聯和查詢Prometheus指標。
Cloud provider tools
GCP Stackdriver
Stackdriver Kubernetes Engine監視旨在監視Google KubernetesEngine（GKE）羣集。它一起管理監視和日誌記錄服務，並具有一個界面，該界面提供了針對GKE集羣定製的儀表板。Stackdriver Monitoring提供了對基於雲的應用程序的性能，正常運行時間和整體運行狀況的可見性。它從Google Cloud Platform（GCP），Amazon Web Services（AWS），託管正常運行時間探測和應用程序工具收集指標，事件和元數據。
Microsoft Azure Monitor for containers
用於容器的Azure Monitor是一項功能，旨在監視部署到Azure容器實例或託管在Azure Kubernetes Service上的託管Kubernetes羣集的容器工作負載的性能。監視容器至關重要，尤其是在使用多個應用程序大規模運行生產集羣時。通過容器的Azure Monitor，可以通過Metrics API從Kubernetes中可用的控制器，節點和容器收集內存和處理器指標，從而使您可以查看性能。還將收集容器日誌。從Kubernetes羣集啓用監視後，將通過適用於Linux的Log Analytics代理的容器化版本爲您自動收集指標和日誌。
AWS Container Insights
如果您在Amazon EC2上使用Amazon ElasticContainer Service（ECS），AmazonElastic Kubernetes Service或其他Kubernetes平臺，則可以使用CloudWatch Container Insights從容器化的應用程序和微服務中收集，彙總和彙總指標和日誌。這些指標包括對CPU，內存，磁盤和網絡等資源的利用率。Container Insights還提供診斷信息，例如容器重新啓動失敗，以幫助您隔離問題並快速解決問題。
在考慮實施監視指標的工具時，一個重要方面是查看指標的存儲方式。提供具有鍵/值對的時間序列數據庫的工具
使用Prometheus監控Kubernetes
在本節中，我們重點介紹通過Prometheus監控指標，該指標與Kubernetes標籤，服務發現和元數據提供了良好的集成。我們在本章中貫徹的高級概念也將適用於其他監視系統。
Prometheus是由CNCF託管的開源項目。它最初是由SoundCloud開發的，其許多概念都基於Google的內部監控系統BorgMon。它使用鍵對實現了多維數據模型，該鍵對的工作方式與Kubernetes標籤系統的工作方式非常相似。Prometheus以人類可讀的格式公開指標，如以下示例所示：
＃HELP node_cpu_seconds_total每種模式下CPU花費的秒數。
＃TYPE node_cpu_seconds_total計數器
node_cpu_seconds_total {cpu ="0"，mode ="idle"}5144.64node_cpu_seconds_total {cpu ="0"，mode ="iowait"}117.98
爲了收集度量標準，Prometheus使用拉模型，在該模型中，它會刮取度量標準端點以收集度量並將其吸收到Prometheus服務器中。像Kubernetes這樣的系統已經以Prometheus格式公開了它們的指標，從而使收集指標變得簡單。許多其他Kubernetes生態系統項目（NGINX，Traefik，Istio，LinkerD等）
還以Prometheus格式公開其指標。Prometheus還可以使用導出器，該導出器允許您從服務中獲取發出的指標並將其轉換爲Prometheus格式的指標。
Prometheus的架構非常簡化，如圖3-1所示。
圖3-1。普羅米修斯架構
Tip
您可以在羣集內或羣集外安裝Prometheus。最好從“實用程序羣集”監視羣集，以避免生產問題也影響監視系統。有諸如Thanos之類的工具可爲Prometheus提供高可用性，並允許您將指標導出到外部存儲系統。
對Prometheus體系結構的深入探討超出了本書的範圍，您應該參考另一本專門的書在這個主題。Prometheus：Up＆Running（O’Reilly）是一本很好的入門書籍。
因此，讓我們深入研究並在我們的Kubernetes集羣上設置Prometheus。有許多不同的方法來執行此操作，並且部署將取決於您的特定實現。在本章中，我們將安裝Prometheus Operator：
Prometheus Server
拉並存儲從系統收集的指標。
Prometheus Operator
使Prometheus配置Kubernetes本地化，並管理和操作Prometheus和Alertmanager集羣。允許您通過本機Kubernetes資源定義創建，銷燬和配置Prometheus資源。
Node Exporter
從集羣中的Kubernetes節點導出主機指標。
kube--statestate--metrics指標
收集特定於Kubernetes的指標。
Alertmanager
允許您配置警報並將警報轉發到外部系統。
Grafana
提供Prometheus儀表板功能的可視化。
helm install --name prom stable/prometheus-operator
安裝operator後，應該會看到以下pods已部署到羣集：
$ kubectl get pods -n monitoringNAME READY STATUS RESTARTS AGEalertmanager-main-0 2/2 Running 0 5h39malertmanager-main-1 2/2 Running 0 5h39malertmanager-main-2 2/2 Running 0 5h38mgrafana-5d8f767-ct2ws 1/1 Running 0 5h39mkube-state-metrics-7fb8b47448-k6j6g 4/4 Running 0 5h39mnode-exporter-5zk6k 2/2 Running 0 5h39mnode-exporter-874ss 2/2 Running 0 5h39mnode-exporter-9mtgd 2/2 Running 0 5h39mnode-exporter-w6xwt 2/2 Running 0 5h39mprometheus-adapter-66fc7797fd-ddgk5 1/1 Running 0 5h39mprometheus-k8s-0 3/3 Running 1 5h39mprometheus-k8s-1 3/3 Running 1 5h39mprometheus-operator-7cb68545c6-gm84j 1/1 Running 0 5h39m
讓我們看一下Prometheus Server，以瞭解如何運行一些查詢來檢索Kubernetes指標：
kubectl port-forward svc/prom-prometheus-operator-prometheus 9090
這將在端口9090上創建到本地主機的隧道。現在，我們可以打開Web瀏覽器並連接到http://127.0.0.1:9090上的Prometheus服務器。
圖3-2顯示了您是否成功將Prometheus部署到羣集上的屏幕。
現在我們已經部署了Prometheus，讓我們通過PrometheusPromQL查詢語言探索一些Kubernetes指標。有可用的PromQL基礎指南。
我們在本章前面的內容中談到了使用USE方法，因此讓我們收集一些有關CPU利用率和飽和度的節點指標。
在表達式輸入中，輸入以下查詢：
avg(rate(node_cpu_seconds_total[5m]))
這將返回整個羣集的平均CPU利用率。
如果要獲取每個節點的CPU利用率，可以編寫如下查詢：
avg(rate(node_cpu_seconds_total[5m])) by (node_name)
這將返回羣集中每個節點的平均CPU利用率。
因此，既然您已經具備在Prometheus中運行查詢的經驗，讓我們看一下Grafana如何幫助我們爲要跟蹤的這些常見USE方法指標構建儀表板可視化。關於您安裝的Prometheus Operator的妙處在於，它帶有一些可以使用的預先構建的Grafana儀表板。
現在，您需要創建一個通往Grafana pod的端口轉發隧道，以便可以從本地計算機訪問它：
kubectl port-forward svc/prom-grafana 3000:3000
現在，將您的Web瀏覽器指向
http://localhost:3000
並使用以下憑據登錄：
· Username: admin
· Password: admin
在Grafana儀表板下，您會找到一個名爲Kubernetes / USE Method / Cluster的儀表板。該儀表板爲您很好地概述了Kubernetes集羣的利用率和飽和度，這是USE方法的核心。圖3-3給出了一個儀表板示例。
圖3-3。Grafana儀表板
繼續並花一些時間來探索可在Grafana中可視化的不同儀表板和指標。
TIP
避免創建過多的儀表板（又稱“圖形牆”），因爲工程師在故障排除情況下可能難以推理。您可能會認爲，在儀表板中擁有更多信息意味着更好的監視，但是在大多數情況下，它會使查看儀表板的用戶更加困惑。將儀表板設計重點放在結果和解決時間上。
記錄概述
到目前爲止，我們已經討論了很多有關指標和Kubernetes的內容，但是要全面瞭解您的環境，您還需要從Kubernetes羣集和部署到您的羣集的應用程序中收集和集中日誌。
使用日誌記錄時，可能很容易地說“讓我們記錄所有內容”，但這會導致兩個問題：
·噪音太大，無法快速發現問題。
·日誌會消耗大量資源，並且成本很高。
對於確切應該記錄的內容，沒有明確的答案，因爲調試日誌會成爲必然的危害。隨着時間的流逝，您將開始更好地瞭解您的環境，並瞭解可以從日誌記錄系統中消除哪些噪聲。另外，要解決存儲的日誌數量不斷增長的問題，您將需要實施保留和歸檔策略。從最終用戶的經驗來看，擁有30到45天之間的歷史日誌非常適合。這樣可以調查出現在較長時間段內的問題，但同時也減少了存儲日誌所需的資源量。如果出於法規遵從性原因需要長期存儲，則需要將日誌歸檔到更具成本效益的資源中。
在Kubernetes集羣中，有多個要記錄的組件。以下是應從中收集指標的組件列表：
· Node logs· Kubernetes control-plane logs• API server• Controller manager• Scheduler· Kubernetes audit logs· Application container logs
使用節點日誌，您想收集發生在基本節點服務上的事件。例如，您將要從運行在工作節點上的Docker守護程序收集日誌。健康的Docker守護程序對於在工作節點上運行容器至關重要。收集這些日誌將幫助您診斷Docker守護程序可能遇到的任何問題，併爲您提供有關該守護程序的任何潛在問題的信息。您還需要從基礎節點登錄其他基本服務。
Kubernetes控制平面由幾個組件組成，您需要從中收集日誌，以便您更深入地瞭解潛在問題
在它裏面。Kubernetes控制平面是運行狀況良好的羣集的核心，您將希望將其存儲在主機上的日誌聚合到/var/log/kube-APIserver.log、/var/log/kube-scheduler.log和/var/log/kube-controller-manager.log。控制器管理器負責創建最終用戶定義的對象。例如，以用戶身份創建一個類型爲LoadBalancer的Kubernetes服務，該服務只是處於掛起狀態；Kubernetes事件可能無法提供診斷問題的所有詳細信息。如果您在集中式系統中收集日誌，它將爲您提供更多有關潛在問題的詳細信息，併爲調查該問題提供了更快的方法。
您可以將Kubernetes審覈日誌視爲安全監視，因爲它們使您可以瞭解誰在系統中執行了哪些操作。這些日誌可能非常嘈雜，因此您需要針對環境進行調整。在許多情況下，這些日誌在首次初始化時可能會導致日誌系統中的峯值，因此請確保遵循有關審計日誌監視的Kubernetes文檔指南。
應用程序容器日誌使您可以深入瞭解應用程序發出的實際日誌。您可以通過多種方式將這些日誌轉發到中央存儲庫。第一種推薦的方法是將所有應用程序日誌發送到STDOUT，因爲這爲您提供了統一的應用程序日誌記錄方式，並且監視守護程序集可以收集日誌
直接從Docker守護程序。另一種方法是使用Sidecar模式，並在Kubernetes容器中的應用程序容器旁邊運行日誌轉發容器。如果您的應用程序登錄到文件系統，則可能需要使用此模式。
注意
有許多用於管理Kubernetes審覈日誌的選項和配置。這些審覈日誌可能非常嘈雜，並且記錄所有操作的成本可能很高。您應該考慮查看審覈日誌記錄文檔，以便可以針對您的環境微調這些日誌。
記錄工具
就像收集指標一樣，有許多工具可以從Kubernetes和集羣中運行的應用程序收集日誌。您可能已經擁有用於此目的的工具，但是請注意該工具如何實現日誌記錄。該工具應具有作爲Kubernetes DaemonSet運行的能力，還應具有作爲不向STDOUT發送日誌的應用程序的輔助工具運行的解決方案。使用現有工具可能是有利的，因爲您已經對該工具有很多操作知識。
與Kubernetes集成的一些更流行的工具是：
· Elastic Stack· Datadog· Sumo Logic· Sysdig· Cloud provider services (GCP Stackdriver, Azure Monitorfor containers, and Amazon CloudWatch)
在尋找一種用於集中日誌的工具時，託管解決方案可以提供很多價值，因爲它們可以分擔很多運營成本。在第N天，託管您自己的日誌記錄解決方案似乎很棒，但是隨着環境的發展，維護該解決方案可能會非常耗時。
使用EFK堆棧進行記錄
出於本書的目的，我們使用Elasticsearch，Fluentd和Kibana（EFK）堆棧爲集羣設置監控。實施EFK堆棧可能是入門的好方法，但有時您可能會問自己：“管理我自己的日誌記錄平臺真的值得嗎？”通常情況下，這不值得付出努力，因爲自託管日誌記錄解決方案在第一天就很出色，但是到365天，它們變得過於複雜。隨着環境的擴展，自託管日誌記錄解決方案在操作上變得更加複雜。沒有一個正確的答案，因此請評估您的業務需求是否需要您託管自己的解決方案。
還有許多基於EFK堆棧的託管解決方案，因此，如果您選擇不自己託管它，則始終可以輕鬆移動。
您將爲監視堆棧部署以下內容：
·Elasticsearch運算符
·Fluentd（將日誌從我們的Kubernetes環境轉發到Elasticsearch）
·Kibana（可視化工具，用於搜索，查看和與Elasticsearch中存儲的日誌進行交互）
將清單部署到您的Kubernetes 集羣
kubectl get pods -n loggingefk-kibana-854786485-knhl5 1/1 Running 0 4melasticsearch-operator-5647dc6cb-tc2st 1/1 Running 0 5melasticsearch-operator-sysctl-ktvk9 1/1 Running 0 5melasticsearch-operator-sysctl-lf2zs 1/1 Running 0 5melasticsearch-operator-sysctl-r8qhb 1/1 Running 0 5mes-client-efk-cluster-9f4cc859-sdrsl 1/1 Running 0 4mes-data-efk-cluster-default-0 1/1 Running 0 4mes-master-efk-cluster-default-0 1/1 Running 0 4mfluent-bit-4kxdl 1/1 Running 0 4mfluent-bit-tmqjb 1/1 Running 0 4mfluent-bit-w6fs5 1/1 Running 0
在所有Pod都“運行”之後，讓我們繼續，並通過端口轉發到我們的本地主機連接到Kibana：
export POD_NAME=$(kubectl get pods --namespace logging -l"app=kibana,release=efk" -ojsonpath="{.items[0].metadata.name}")kubectl port-forward $POD_NAME 5601:5601
現在，將您的Web瀏覽器指向http：// localhost：5601以打開Kibana儀表板。
要與從我們的Kubernetes集羣轉發的日誌進行交互，您首先需要創建一個索引。
首次啓動Kibana時，將需要導航到“管理”選項卡，併爲Kubernetes日誌創建索引模式。系統將指導您完成所需的步驟。
創建索引後，可以使用Lucene查詢語法搜索日誌，例如：
log:(WARN|INFO|ERROR|FATAL)
這將返回包含警告，信息，錯誤或致命字段的所有日誌。您可以在圖3-4中看到一個示例。
圖3-4。Kibana儀表板
在Kibana中，您可以對日誌執行臨時查詢，還可以構建儀表板以概述環境。
繼續並花一些時間來探索可以在Kibana中可視化的不同日誌。
Alerting
警報是一把雙刃劍，您需要在警報內容和應該監視的內容之間取得平衡。發出過多警報會引起警報疲勞，並且所有噪音都將丟失重要事件。一個示例是在Pod發生故障時隨時生成警報。您可能會問：“我爲什麼不希望監視pod故障？”好吧，Kubernetes的優點在於它提供了自動檢查容器運行狀況並自動重啓容器的功能。您真的想將警報重點放在影響您的服務水平目標（SLO）的事件上。SLO是您可以與服務的最終用戶達成一致的特定可測量特徵，例如可用性，吞吐量，頻率和響應時間。設置SLO可以設置最終用戶的期望值，並可以清晰地說明系統的行爲方式。沒有SLO，用戶可以形成他們的意見，這可能是對該服務的不切實際的期望。在像Kubernetes這樣的系統中發出警報需要一種不同於我們通常習慣的全新方法，並且需要關注最終用戶如何體驗該服務。例如，如果您的前端服務的SLO響應時間爲20毫秒，並且看到的延遲高於平均水平，那麼您希望收到有關此問題的警報。
您需要確定哪些警報是好的，並需要干預。在典型的監視中，您可能習慣於警告CPU使用率高，內存使用率高或進程沒有響應。這些看似警報良好，但可能並不表示有人需要立即採取行動並需要通知值班工程師。嚮應召喚的工程師發出警報應該是需要立即引起人工關注並影響應用程序用戶體驗的問題。如果您曾經遇到過“該問題已自行解決”的情況，那麼這很好地表明瞭該警報不需要聯繫值班工程師。
處理不需要立即採取措施的警報的一種方法是集中精力自動修復原因。例如，當磁盤已滿時，您可以自動刪除日誌以釋放磁盤上的空間。此外，在應用程序部署中使用Kubernetes活躍度探針可以幫助自動修復應用程序中未響應的流程問題。
建立警報時，還需要考慮警報閾值。如果您將閾值設置得太短，則警報可能會導致很多誤報。通常建議將閾值設置爲至少五分鐘，以幫助消除誤報。提出標準閾值可以幫助定義標準，並避免微觀管理
不同的閾值。例如，您可能要遵循5分鐘，10分鐘，30分鐘，1小時等的特定模式。
在爲警報構建通知時，您要確保在通知中提供相關信息，例如，提供指向“劇本”的鏈接，該手冊提供了疑難解答或其他有關解決問題的有用信息。您還應該在通知中包括有關數據中心，區域，應用程序所有者和受影響的系統的信息。提供所有這些信息將使工程師能夠快速確定有關該問題的理論。
您還需要構建通知渠道以路由已觸發的警報。在考慮“觸發警報時應通知誰？”您應該確保不僅將通知發送到通訊組列表或團隊電子郵件中。如果將警報發送給較大的組，則往往會由於將它們視爲噪音而最終被過濾掉。您應該將通知路由給將對此問題負責的用戶。
有了警報，您就不會在第一天就做到完美，而我們可以說它可能永遠都不是完美的。您只想確保逐漸改進警報，以防止警報疲勞，這可能會導致人員倦怠和您的系統出現許多問題。
要進一步瞭解如何在系統上管理警報，請閱讀Rob Ewaschuk撰寫的“My Philosophy on Alerting”，該書基於Rob在Google擔任站點可靠性工程師（SRE）的觀察。
監視，記錄和警報的最佳做法
以下是有關監視，日誌記錄和警報的最佳實踐。
Monitoring
·監視節點和所有Kubernetes組件的利用率，飽和度和錯誤率，並監視應用程序的速率，錯誤和持續時間。
·使用黑盒監視來監視症狀而不是預測系統的運行狀況。
·使用白盒監視來通過儀器檢查系統及其內部。
·實施基於時間序列的指標以獲取高精度指標，這些指標還使您能夠深入瞭解應用程序的行爲。
·利用Prometheus之類的監控系統，這些系統可以爲高維提供關鍵標籤；這將更好地指示問題的症狀。
·使用平均指標可基於事實數據可視化小計和指標。利用總和指標來可視化特定指標的分佈。
Logging
·您應該將日誌記錄與指標監視結合使用，以全面瞭解您的環境如何運行。
·請謹慎保存日誌30至45天以上，如果需要，請使用更便宜的資源進行長期歸檔。
·限制日誌轉發器以sidecar模式使用，因爲它們將使用更多資源。選擇對日誌轉發器使用DaemonSet並將日誌發送到STDOUT。
Alerting
·注意警報疲勞，因爲它可能導致人員和流程中的不良行爲。
·始終注意在警報發生時逐步改進，並接受它並不總是完美的。
·警告會影響您的SLO和客戶的症狀，而不是那些不需要人爲關注的暫時性問題。
摘要
在本章中，我們討論了可用於通過度量標準和日誌收集監視系統的模式，技術和工具。本章最重要的部分是您需要重新考慮如何執行監視並從一開始就進行監視。我們太多次看到這一事實是在事實之後實現的，它可能使您在理解系統方面陷入困境。監視就是要更好地瞭解系統並提供更好的彈性，從而爲您的應用程序提供更好的最終用戶體驗。監視分佈式應用程序和諸如Kubernetes之類的分佈式系統需要進行大量工作，因此您必須在旅途開始時就做好準備。
我的公衆號二維碼，歡迎關注。
