查看grafana版本_使用 Prometheus 与 Grafana 为 Kubernetes 集群建立监控与警报机制
IT 團隊已經明確意識到對基礎設施進行監控的必要性。目前市面上存在著大量適用于傳統基礎設施且歷史悠久的解決方案：Nagios、Zabbix 等工具都是其中的代表。
但這些工具并不足以解決 Kubernetes 生態系統在多層級抽象與故障排查方面的實際需求。不少 DevOps 工程師一次又一次被以下問題所困擾：
調度失敗，找不到與以下所有謂詞相匹配的節點：：CPU 不足
集群資源監控對于實時跟蹤而言至關重要。與傳統基礎設施相比，集群資源一直在不斷擴展和變化。我們永遠無法知曉自己的 Pod 在集群中的啟動位置。出于這些考慮，我們需要監控集群的底層資源以及內部集群的運行狀態。
更重要的是，如果不配合警報機制，單純進行監控還遠遠不夠。因為很明顯，運營工程師不可能整晚對著關鍵生產集群的儀表板等待。
1 為什么要選擇 Prometheus 與 Grafana？即使擁有廣泛的警報與監控工具可供選擇，我們為什么要專門點名 Prometheus 與 Grafana？
PrometheusPrometheus 是一款開源監控工具。它最初在 Soundcloud 上開發完成，但如今已經轉化為獨立的開源項目，從 2016 年開始成為云原生計算基金會(CNCF)的一部分，并成為繼 Kubernetes 本身之后的第二個項目。也正因為如此，這兩款組件通常會緊密關聯在一起。
除此之外，Prometheus 不同于其他眾多監控工具的一大核心，在于其基本架構始終以 pull 為基礎。它不斷從受到監控的組件當中抓取指標。
最后，從架構本身來看，Prometheus 使用到多維數據模型，此模型與 Kubernetes 通過標簽組織數據的方式非常相似。與點數據模型相反，點數據模型中的每項指標都是唯一的，而每個不同的參數都將對應不同的指標；而使用 Prometheus，所有數據都將按時間序列存儲為鍵 - 值對：
<metric name>{<label name>=<label value>, …}Prometheus 架構包含三大主要組件：
Prometheus 服務器本身，用于收集指標并通過 API 應答查詢。
Pushgateway，公布關于臨時及短期作業的指標。
Alertmanager：按照名稱提示啟用警報發布。
Prometheus 架構與生態系統組件
我們還將把 prometheusnode_exporter 與 kube_state_metrics 相結合，用以發布關于集群的各項指標。
GrafanaGrafana 是一款頗為流行的 Prometheus 開源(Apache 2.0 許可)可視化層，支持以開箱即用的方式按時間查詢 Prometheus 數據。實際上，從 Grafana 2.5.0 (2015–10–28) 版本開始就已經把 Prometheus 納入為 Grafana 數據源。
最重要的是，它非常易于使用，其中提供的模板功能可幫助您輕松創建可實時編輯的動態儀表板。
最后，Grafana 提供良好的說明文檔以及廣泛的社區共享體系，包括各類公共儀表板。在本文中，我們將使用兩套專為 Kubernetes 設計的公共儀表板。
理論到此結束，下面開始動手環節！
2 安裝的先決條件完成演練項目的唯一要求，就是擁有一套有效的 Kubernetes 集群。為了簡單起見，本文將在 AWS EC2 上使用 minikube 完成安裝。
Minikube 是一種便捷方法，能夠快速高效地安裝一套非生產、主要用于實驗室及測試場景的單節點 Kubernetes 集群。由于對資源需求不高，而且支持多種現成 K8s 功能，大家可以借此在單一計算機上輕松獲取 Kubernetes 集群。
只要使用虛擬機管理程序在機器上創建本地計算機，系統即可正常工作。但這里我們使用 AWS 虛擬機，并在演示中使用 Minikube 的 vm-driver=none 模式。
3 使用 Helm 安裝 Prometheus 與 Grafana接下來就是安裝這兩款產品了。這里我們使用 Helm, 這款 Kubernetes 軟件包管理器已經在 2019 年 11 月正式更新為 3.0 版本。
從歷史來看，此次更新非常重要，因為開發社區對 Helm 進行深度重寫，借此適應 RBAC 與自定義角色定義等 Kubernetes 發展成果。新版本較以往版本更適合生產要求。以往，由于固有安全模型以及高度依賴于存在爭議的 Tiller 組件(現已從 3.0 版本中刪除)，不少 IT 專家都不愿意將 Helm 應用于生產級集群。
我們還將使用穩定版 Helmrepo 中的 charts(Helm 打包格式)對 Kubernetes 集群組件及系統指標進行監控。
安裝 Helm將穩定版 repo 添加至您的 Helm 安裝：
$ helm repo add stable[https://kubernetes-charts.storage.googleapis.com/](https://kubernetes-charts.storage.googleapis.com/)$ helm repo update接下來，我們在 K8s 集群上創建一個自定義命名空間，用以管理所有監控棧：
$kubectlcreate ns monitoring安裝 Prometheus現在，我們可以在新創建的監控命名空間中安裝 Prometheuschart 了：
$ helm installprometheusstable/prometheus--namespace monitoringNAME:prometheusLAST DEPLOYED: Tue Apr 14 09:22:27 2020NAMESPACE: monitoringSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:The Prometheus server can be accessed via port 80 on the following DNS name from within your cluster:prometheus-server.monitoring.svc.cluster.local[...]接下來，我們可以使用 K8s 的本地指令命令創建一個 NodePort，借此從集群外部直接與 Pod 通信。請注意，如果您不打算在未安裝 Grafana 的前提下查詢 Prometheus，也可以直接跳過此步驟。
我們可以看到，端口 30568 被自動分配并映射至指向該 Pod 的端口 9090.
現在，我們可以使用公共 DNS 及瀏覽器中的 30568 端口訪問 Prometheus 端點。
接下來，我們可以使用以下命令直接查詢 Prometheus 以獲取各類指標，例如命名空間的 CPU 消耗量：
sum(rate(container_cpu_usage_seconds_total{container_name!=”POD”,namespace!=””}[5m])) by (namespace)4 安裝 Grafana現在，Prometheus 已經安裝完成。相較于單獨查詢各項指標，我們可以使用 Grafana 以聚合方式通過統一的儀表板快速查看多項指標。
我們再次使用 helm 將 grafana 安裝在監控命名空間當中：
$ helm installgrafanastable/grafana--namespace monitoring可以看到，grafanaPod 開始配合 Prometheus 組件運行：
這里，我們再創建一個 NodePort 服務，從集群外部訪問 Grafana(此步驟為強制要求)：
$kubectl-n monitoring expose pod grafana-5b74c499c6-kt4bw --typeNodePort--namegrafana-npservice/grafana-np exposed而后將外部端口映射至 Grafana 的偵聽端口 3000：(這里為 31399)
$kubectl-n monitoringgetsvcgrafana-npNAMETYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEgrafana-npNodePort10.111.59.2??80:30368/TCP,3000:31399/TCP?3h8m在瀏覽器中輸入：yourPublicDNS:yourPort 與 tada!
Grafana 提供用戶管理功能，在默認情況下您需要使用 admin 用戶方可接入。
要獲取 admin 密碼，請輸入以下命令：
kubectlget secret — namespace monitoringgrafana-ojsonpath=”{.data.admin-password}” | base64 — decode ;echoADMINPASSWORD現在即可開始正式連接。
第一步是使用 Kubernetes 的內部 DNS 結構將 Prometheus 配置為數據源：
http://prometheusServiceName.namespace.svc.cluster.local:port在本示例中為：
http://prometheus-server.monitoring.svc.cluster.local(:80 可選)現在數據已經添加完成，我們將導入兩套社區儀表板，用于監控我們的工作負載與集群運行情況。這些儀表板應該可以開箱即用。
點擊 import 按鈕并輸入 Grafana 儀表板 ID：
首先安裝 1860，而后安裝 8685：
現在，我們已經擁有了兩套工作儀表板：
我們已經可以輕松監控系統指標與集群配置了！
5 通過 Slack 頻道發布警報現在，我們已經擁有了一套高效的監控解決方案，第二步就是激活警報。很明顯，如果沒有警報機制的支持，運營團隊不可能整天盯著生產環境中的眾多儀表板。
我們可以通過兩種方式在監控棧中實施警報。首先是使用 PrometheusAlertManager 組件(由 helm chart 安裝)，其次是使用 Garfana 的內置警報功能。這里我們選擇后一種方式，因為其更易于現實。
Grafana 能夠通過 Slack、電子郵件、webhook 或者其他通信渠道發布警報。由于我個人經常使用 Slack，而且不少企業也在使用 Slack 作為內部通信平臺，因此本示例就以 Slack 為警報通道。
創建 Slack 通知頻道第一步是將 Slack 添加為通知頻道。在 Grafana 當中，單擊左側的鈴鐺圖標，選擇通知頻道菜單，而后創建一個新頻道。
您將在這里看到多種與 Grafana 相兼容的警報工具。
選擇 Slack，而后輸入您的 Slack webhook URL(其他字段為可選項)。
如果您還沒有 webhook URL，請參閱此教程進行創建:
https://api.slack.com/messaging/webhooks
如此一來，您將擁有一個端點，用于將消息發送至 Slack 服務器上的特定頻道。
創建并測試自定義警報現在，頻道已經設置完畢，接下來使用“K8s Cluster Summary”儀表板，而后單擊“Cluster Pod Capacity”標題以編輯面板。
我們將設置一項警報來監控 Pod 容量，在默認情況下，每個節點上的 Kubernetes 限制為 110 個。此上限總體屬于可靠上限。如果集群中的節點數量受到限制，而且已經達到 110 個這一硬上限，則剩余的 Pod 將進入掛起狀態。而這會在高業務活動強度期間給生產集群擴展造成巨大問題。
我們將警報設置為 90 個 Pod：
回到我們的集群，創建一個包含 100 個 nginx 副本的任意部署：
$kubectlcreate nsloadtestnamespaceloadtestcreated$kubectlcreate deploymentnginx--image=nginx-nloadtestdeployment.apps/nginxcreated$kubectl-nloadtestscale deploymentnginx--replicas=100deployment.apps/nginxscaled可以看到，由于集群中已經包含 15 個初始 Pod，且 Pod 容量迅速增加到 115 個：
這比許可的 Pod 上限 110 個還多了 5 個。實際上，我們可以在儀表板中看到 5 個 Pod 處于待處理狀態。
5 分鐘之后，警報進入 ALERTING 狀態，并在 Slack 頻道上發送帶有自定義消息及當前值的通知。
我們可以將部署縮減至 1 個 Pod：
$kubectl-nloadtestscale deploymentnginx— replicas=1deployment.apps/nginxscaledPod Capacity 已經冷卻：
警報會向 Slack 發送返回正常狀態的通知。
這項小小的演練非常有趣，因為它不僅實施起來相當簡單，而且足以反映真實的運營場景。
關于 Grafana 警報功能，還有其他一些注意事項。我們的兩套儀表板都使用被稱為模板變量的函數。變量是您可以在主機、集群或者命名空間等儀表板之上進行更改的值。根據設計，Grafana 不可根據模板變量發出警報，原因很多。如果嘗試在儀表板的某些面板上放置一些警報，則有可能因此而出錯。解決方案是為各項警報指定一個特定的主機、集群或者節點，而非使用變量進行監控。
6 總結在與 Prometheus 與 Grafana 打過一番交道之后，希望大家喜歡這篇文章，并感受到監控對于 Kubernetes 生態系統的重要意義。
原文鏈接
https://gregoiredayet.medium.com/monitoring-and-alerting-on-your-kubernetes-cluster-with-prometheus-and-grafana-55e4b427b22d
今日推薦文章對話Ruby on Rails之父DHH：我們需要重新審視軟件開發
點個在看少個 bug??
總結
以上是生活随笔為你收集整理的查看grafana版本_使用 Prometheus 与 Grafana 为 Kubernetes 集群建立监控与警报机制的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 小企业文件打印服务器,小企业云服务器方案
- 下一篇： 鸽主姓名查询成绩_鸽主姓名