CPU使用率
我們從計算每個CPU模式的每秒速率開始。PromQL有一個名為irate的函數，用於計算距離向量中時間序列的每秒瞬時增長率。讓我們在``node_cpu_seconds_total`度量上使用irate函數。在查詢框中輸入:
irate(node_cpu_seconds_total{job="node"}[5m])
avg(irate(node_cpu_seconds_total{job="node"}[5m])) by (instance)
現在，我們將irate函數封裝在avg聚合中，並添加了一個by子句，該子句通過實例標簽聚合。這將產生三個新的指標，使用來自所有CPU和所有模式的值來平均主機的CPU使用情況。
avg (irate(node_cpu_seconds_total{job="node",mode="idle"}[5m])) by (instance) * 100
在這里，我們查詢中添加了一個值為idle的mode標簽。這只查詢空閑數據。我們通過實例求出結果的平均值，並將其乘以100。現在我們在每台主機上都有5分鍾內空閑使用的平均百分比。我們可以把這個變成百分數用這個值減去100，就像這樣:
100 - avg (irate(node_cpu_seconds_total{job="node",mode="idle"}[5m])) by (instance) * 100
現在我們有三個指標，每個主機一個指標，顯示5分鍾窗口內使用的平均CPU百分比。
這里就演示最后一個
CPU Saturation(飽和度)
獲取主機上CPU飽和的一種方法是跟蹤負載平均，即考慮主機上的CPU數量，在一段時間內平均運行隊列長度。平均少於cpu的數量通常是正常的;
要查看主機的平均負載，我們可以使用node_load*指標來實現這些功能。它們顯示平均負荷超過1分鍾，5分鍾和15分鍾。我們將使用一分鍾的平均負載:node_load1。
我們還需要計算主機上的cpu數量。我們可以這樣使用count聚合:count by (instance)(node_cpu_seconds_total{mode="idle"})
內存使用
以node_memory為前綴的指標列表中找到它們。
我們將關注node_memory度量的一個子集，以提供我們的利用率度量:
• node_memory_MemTotal_bytes - 主機上的總內存
• node_memory_MemFree_bytes - 主機上的空閑內存
• node_memory_Buffers_bytes_bytes - 緩沖區緩存中的內存
• node_memory_Cached_bytes_bytes - 頁面緩存中的內存。
所有這些指標都以字節表示。
(node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Cached_bytes + node_memory_Buffers_bytes)) / node_memory_MemTotal_bytes * 100
磁盤使用率
對於磁盤，我們只測量磁盤使用情況而不是使用率、飽和度或錯誤。這是因為在大多數情況下，它是對可視化和警報最有用的數據。Node Exporter的磁盤使用指標位於以node_filesystem為前綴的指標列表
例如，node_filesystem_size_bytes指標顯示了被監控的每個文件系統掛載的大小。我們可以使用與內存指標類似的查詢來生成在主機上使用的磁盤空間的百分比。但是，與內存指標不同，我們在每個主機上的每個掛載點都有文件系統指標。所以我們添加了mountpoint標簽，特別是根文件系統“/”掛載。這將在每台主機上返回該文件系統的磁盤使用指標。
(node_filesystem_size_bytes{mountpoint="/"} - node_filesystem_free_bytes{mountpoint="/"}) / node_filesystem_size_bytes{mountpoint="/"} * 100
如果我們想要或者需要，我們現在可以為配置的特定掛載點添加額外的查詢。要監視一個稱為/data的掛載點，我們
將使用:
(node_filesystem_size_bytes{mountpoint="/data"} - node_filesystem_free_bytes{mountpoint="/data"}) / node_filesystem_size_bytes{mountpoint="/data"} * 100
或者我們可以使用正則表達式來匹配多個掛載點。
(node_filesystem_size_bytes{mountpoint=~"/|/run"} - node_filesystem_free_bytes{mountpoint=~"/|/run"}) /node_filesystem_size_bytes{mountpoint=~"/|/run"} * 100
可以看到，我們已經更新了掛載點標簽，將操作符從=改為=~，這告訴Prometheus右手邊的值將是一個正則表達式。然后我們匹配了/run和/ 文件系統。
注意：
（1）不能使用匹配空字符串的正則表達式。
（2）對於不匹配的正則表達式，還有一個!~運算符。
預計多長時間磁盤爆滿
predict_linear(node_filesystem_free_bytes{mountpoint="/"}[1h], 4*3600) < 0
predict_linear(node_filesystem_free_bytes{job="node"}[1h], 4*3600) < 0
監控服務狀態
systemd收集器的數據，我們這里只收集了Docker SSH 和 Rsyslog
node_systemd_unit_state{name=“docker.service”} // 只查詢 docker服務
node_systemd_unit_state{name=“docker.service”,state=“active”} // 返回活動狀態
node_systemd_unit_state{name=“docker.service”} == 1 // 返回當前服務的狀態
注：比較二進制運算符:==。這將檢索所有值為1、名稱標簽為docker.service的指標。
持久查詢
到目前為止，我們只是在表達式瀏覽器中運行查詢。雖然查看該查詢的輸出很有趣，但結果被卡在普羅米修斯服務器上，是暫時的。有三種方法可以使我們的持久查詢（不用每次都要輸入查詢規則）:
• 記錄規則 — 從查詢中創建新的指標。
• 警報規則 - 從查詢生成警報。
• 可視化 —使用像Grafana這樣的儀表盤來可視化查詢。
（1）記錄規則
記錄規則是一種計算新時間序列的方法，特別是從輸入的時間序列中聚合的時間序列。我們可以這樣做:
• 跨多個時間序列生成聚合。
• 預計算昂貴的查詢，即消耗大量時間或計算能力的查詢。
• 生成一個時間序列，我們可以用它來生成警報。
（2）配置記錄規則
記錄規則存儲在Prometheus服務器上，存儲在Prometheus服務器加載的文件中。規則是自動計算的，頻率由prometheus.yml 全局塊中的evaluation_interval參數控制。
[root@localhost docker]# cat /wgr/prometheus/rules/node_rules.yml
groups:
- name: node_rules
rules:
- record: instance:node_cpu:avg_rate1m
expr: 100 - avg(irate(node_cpu_seconds_total{mode="idle"}[1m])) by (instance) * 100
labels:
metric_type: aggregation
[root@localhost docker]#
注意：我這里用的是docker的，一開始創建容器的時候是掛載的yml文件，導致容器里面node_rules.yml,找了一會原因。
可視化
需要注意的是，普羅米修斯一般不用於長期數據保留——默認值是15天的時間序列。這意味着，普羅米修斯關注的是更直接的監控問題，而不是可視化和儀表板更重要的其他系統。使用表達式瀏覽器、繪制Prometheus用戶界面內部的圖形以及構建相應的警報，這些方法往往比構建廣泛的儀表盤更能體現普羅米修斯時間序列數據的實用性。Grafana支持在Linux、Microsoft Windows和Mac OS x上運行。
確實可以直接導入模板的，更好看點。
