昨天的 Grafana 圖是別人畫好的，今天要跳過圖表，直接去問 Prometheus

練查詢我覺得用 Prometheus 自己的介面比較好，它會直接給你原始的資料列，看得比較清楚

kubectl port-forward -n monitoring service/monitoring-kube-prometheus-prometheus 9090:9090

上面那個輸入框就是寫查詢的地方，語言叫 PromQL

先講資料長什麼樣子。Prometheus 存的每一筆資料有四個部分，指標名稱、一組標籤、一個數值、一個時間戳。標籤這個設計跟 Day 7 的 Label 是同一個思路，用來區分同名的不同對象

最簡單的查詢就是打一個指標名稱

up

up 是 Prometheus 內建的，代表它去抓資料的每個目標現在通不通，1 是通、0 是不通。每一列後面那串大括號裡的東西就是標籤，用來說明這個 1 是誰的 1

用大括號加條件來篩選

kube_pod_status_phase{namespace="ithome-lab"}

這個指標的設計一開始讓我愣了一下。它不是給你一個字串說這個 Pod 是 Running，而是把每種可能的 phase 都列出來，是的那個給 1、其他給 0。因為 Prometheus 只能存數字，狀態這種東西就只能用這種方式表達

再看重啟次數

kube_pod_container_status_restarts_total{namespace="ithome-lab"}

名字結尾的 total 是個慣例，代表這是一個累計值，只會往上加不會下降，這種指標叫 counter。它跟 Day 13 那種當下用量的指標不一樣，後者叫 gauge，會上下浮動

counter 直接看意義不大，因為它是從 Pod 出生開始算的總數。一個 Pod 重啟過 50 次但那是三天前的事，跟它剛剛重啟 3 次，前者的數字大但後者才是現在的問題

所以 counter 要包一層函式來看變化

increase(kube_pod_container_status_restarts_total{namespace="ithome-lab"}[10m])

increase 的意思是這個數字在括號那段時間內增加了多少。中括號裡的 10m 叫時間範圍，可以改成 5m 或 1h

還有一個常一起出現的是 rate，它算的是每秒平均增加多少。兩者的關係大致上是 increase 等於 rate 乘上時間長度。我覺得重啟次數這種事件用 increase 比較直觀，畢竟每秒零點零零幾次重啟不好想像；而請求量那種高頻的東西用 rate 比較合理

kube_pod_container_status_last_terminated_reason{namespace="ithome-lab"}

這個指標把 Day 21 在 describe 裡面看到的那個 Last State Reason 變成了可查詢的資料。想抓 OOMKilled 就在後面加條件

kube_pod_container_status_last_terminated_reason{reason="OOMKilled"}

kube_ 開頭的來自 kube-state-metrics，講的是 K8s 物件的狀態，這類指標基本上就是把 kubectl get 看到的東西數字化

container_ 開頭的來自 cAdvisor，講的是容器實際用掉多少資源，昨天 Grafana 上那些 CPU 跟記憶體曲線就是從這裡來的

node_ 開頭的來自 node-exporter，講的是機器本身

看到一個陌生的指標名，先看前綴就大概知道它在講哪一層的事。另外 Prometheus 的輸入框有自動完成，打幾個字它會列出所有符合的指標

明天見 :D