解決 Prometheus 監(jiān)控 Kubernetes Job 誤報的坑
編輯搜圖
昨天在 Prometheus 課程輔導(dǎo)群里面有同學(xué)提到一個問題，是關(guān)于 Prometheus 監(jiān)控 Job 任務(wù)誤報的問題(已經(jīng)同步到社區(qū)網(wǎng)站)，大概的意思就 CronJob 控制的 Job，前面執(zhí)行失敗了會觸發(fā)報警，后面生成的新的 Job 可以正常執(zhí)行后，但是還是會收到前面的報警：
編輯搜圖
這是因為一般在執(zhí)行 Job 任務(wù)的時候我們會保留一些歷史記錄方便排查問題，所以如果之前有失敗的 Job 了，即便稍后會變成成功的，那么之前的 Job 也會繼續(xù)存在，而大部分直接使用 kube-prometheus 安裝部署的話使用的默認(rèn)報警規(guī)則是kube_job_status_failed > 0，這顯然是不準(zhǔn)確的，只有我們?nèi)ナ謩觿h除之前這個失敗的 Job 任務(wù)才可以消除誤報，當(dāng)然這種方式是可以解決問題的，但是不夠自動化，一開始沒有想得很深入，想去自動化刪除失敗的 Job 來解決，但是這也會給運維人員帶來問題，就是不方便回頭去排查問題。下面我們來重新整理下思路解決下這個問題。
CronJob 會在計劃的每個執(zhí)行時間創(chuàng)建一個 Job 對象，可以通過 .spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit 屬性來保留多少已完成和失敗的 Job，默認(rèn)分別為3和1，比如下面聲明一個 CronJob 的資源對象：
apiVersion: batch/v1kind: CronJobmetadata: name: hellospec: schedule: "*/1 * * * *" successfulJobsHistoryLimit: 1 failedJobsHistoryLimit: 1 jobTemplate: spec: template: spec: containers: - name: hello image: busybox imagePullPolicy: IfNotPresent command: - /bin/sh - -c - date; restartPolicy: OnFailure1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.
根據(jù)上面的資源對象規(guī)范，Kubernetes 將只保留一個失敗的 Job 和一個成功的 Job：
NAME COMPLETIONS DURATION AGEhello-4111706356 0/1 2m 10dhello-4111706356 1/1 5s 5s1.2.3.
要解決上面的誤報問題，同樣還是需要使用到 kube-state-metrics 這個服務(wù)，它通過監(jiān)聽 Kubernetes APIServer 并生成有關(guān)對象狀態(tài)的指標(biāo)，它并不關(guān)注單個 Kubernetes 組件的健康狀況，而是關(guān)注內(nèi)部各種對象的健康狀況，例如 Deployment、Node、Job、Pod 等資源對象的狀態(tài)。這里我們將要使用到以下幾個指標(biāo)：
-
kube_job_owner：用來查找 Job 和觸發(fā)它的 CronJob 之間的關(guān)系。
-
kube_job_status_start_time：獲取 Job 被觸發(fā)的時間。
-
kube_job_status_failed：獲取執(zhí)行失敗的任務(wù)。
-
kube_cronjob_spec_suspend：過濾掉掛起的作業(yè)。
下面是一個指標(biāo)示例，其中包含 CronJob 觸發(fā)運行的hello 任務(wù)生成的標(biāo)簽：
kube_job_owner{job_name="hello-1604875860", namespace="myNamespace", owner_is_controller="true", owner_kind="CronJob", owner_name="hello"} 1kube_job_status_start_time{job_name="hello-1604875860", namespace="myNamespace"} 1604875874kube_job_status_failed{job_name="hello-1604875860", namespace="myNamespace", reason="BackoffLimitExceeded"} 1kube_cronjob_spec_suspend{cronjob="hello",job="kube-state-metrics", namespace="myNamespace"} 01.2.3.4.
要想做到監(jiān)控報警準(zhǔn)確，其實我們只需要去獲取同一個 CronJob 觸發(fā)的一組 Job 的最后一次任務(wù)，只有該 Job 在執(zhí)行失敗的時候才觸發(fā)報警即可。
由于 kube_job_status_failed 和 kube_job_status_start_time 指標(biāo)中并不包含所屬 CronJob 的標(biāo)簽，所以第一步需要加入這個標(biāo)簽，而 kube_job_owner 指標(biāo)中的 owner_name 就是我們需要的，可以用下面的 promql 語句來進(jìn)行合并：
max( kube_job_status_start_time
* ON(job_name, namespace) GROUP_RIGHT() kube_job_owner{owner_name != ""}
)BY (job_name, owner_name, namespace)1.2.3.4.5.6.
這里我們使用 max 函數(shù)是因為我們可能會因為 HA 運行多個 kube-state-metrics，所以用 max 函數(shù)來返回每個 Job 任務(wù)的一個結(jié)果即可。假設(shè)我們的 Job 歷史記錄包含 2 個任務(wù)(一個失敗，另一個成功)，結(jié)果將如下所示：
{job_name="hello-1623578940", namespace="myNamespace", owner_name="hello"} 1623578959{job_name="hello-1617667200", namespace="myNamespace", owner_name="hello"} 16176672041.2.
現(xiàn)在我們知道每個 Job 的所有者了，接著我們需要找出最后執(zhí)行的任務(wù)，我們可以通過按 owner_name 標(biāo)簽聚合結(jié)果來實現(xiàn)這一點：
max( kube_job_status_start_time
* ON(job_name,namespace) GROUP_RIGHT() kube_job_owner{owner_name!=""}
)
BY (owner_name)1.2.3.4.5.6.
上面這條語句會找到每個 owner(也就是 CronJob)最新的任務(wù)開始時間，然后再和上面的語句進(jìn)行合并，保留開始時間相同的記錄即為最新執(zhí)行的 Job 任務(wù)了：
max( kube_job_status_start_time
* ON(job_name,namespace) GROUP_RIGHT() kube_job_owner{owner_name!=""}
)BY (job_name, owner_name, namespace)
== ON(owner_name) GROUP_LEFT()max( kube_job_status_start_time
* ON(job_name,namespace) GROUP_RIGHT() kube_job_owner{owner_name!=""}
)BY (owner_name)1.2.3.4.5.6.7.8.9.10.11.12.13.
結(jié)果將顯示每個 CronJob 最后執(zhí)行的作業(yè)，并且僅顯示最后一個：
{job_name="hello-1623578940", namespace="myNamespace", owner_name="hello"} 16235789591.
為了增加可讀性我們還可以將 job_name、owner_name 標(biāo)簽替換為 job 和 cronjob，這樣更容易看明白：
label_replace( label_replace( max( kube_job_status_start_time
* ON(job_name,namespace) GROUP_RIGHT() kube_job_owner{owner_name!=""}
) BY (job_name, owner_name, namespace)
== ON(owner_name) GROUP_LEFT() max( kube_job_status_start_time
* ON(job_name,namespace) GROUP_RIGHT() kube_job_owner{owner_name!=""}
) BY (owner_name), "job", "$1", "job_name", "(.+)"),"cronjob", "$1", "owner_name", "(.+)")1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.
現(xiàn)在將會看到類似于下面的結(jié)果：
{job="hello-1623578940", cronjob="hello", job_name="hello-1623578940", namespace="myNamespace", owner_name="hello"} 16235789591.
由于上面的查詢語句比較復(fù)雜，如果每次報警評估的時候都去進(jìn)行一次實時計算會對 Prometheus 產(chǎn)生非常大的壓力，這里我們可以借助記錄規(guī)則來實現(xiàn)類離線計算的方式，大大提高效率，創(chuàng)建如下所示的記錄規(guī)則，用來表示獲取每個 CronJob 最后執(zhí)行的作業(yè)記錄：
- record: job:kube_job_status_start_time:max
expr: | label_replace( label_replace( max( kube_job_status_start_time
* ON(job_name,namespace) GROUP_RIGHT() kube_job_owner{owner_name!=""}
) BY (job_name, owner_name, namespace)
== ON(owner_name) GROUP_LEFT() max( kube_job_status_start_time
* ON(job_name,namespace) GROUP_RIGHT() kube_job_owner{owner_name!=""}
) BY (owner_name), "job", "$1", "job_name", "(.+)"), "cronjob", "$1", "owner_name", "(.+)")1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.
現(xiàn)在我們知道了 CronJob 最近開始執(zhí)行的 Job 了，那么想要過濾出失敗的，則再使用 kube_job_status_failed 指標(biāo)就可以了：
- record: job:kube_job_status_failed:sum expr: | clamp_max(job:kube_job_status_start_time:max, 1) * ON(job) GROUP_LEFT() label_replace( (kube_job_status_failed > 0), "job", "$1", "job_name", "(.+)" )1.2.3.4.5.6.7.8.
這里使用 clamp_max 函數(shù)將 job:kube_job_status_start_time:max 的結(jié)果轉(zhuǎn)換為一組上限為 1 的時間序列，使用它來通過乘法過濾失敗的作業(yè)，得到包含一組最近失敗的 Job 任務(wù)，這里我們也添加到名為 kube_job_status_failed:sum 的記錄規(guī)則中。
最后一步就是直接為失敗的 Job 任務(wù)添加報警規(guī)則，如下所示：
- alert: CronJobStatusFailed expr: | job:kube_job_status_failed:sum * ON(cronjob, namespace) GROUP_LEFT() (kube_cronjob_spec_suspend == 0)1.2.3.4.5.
為避免誤報，我們已將掛起的任務(wù)排除在外了。到這里我們就解決了 Prometheus 監(jiān)控 CronJob 的任務(wù)誤報的問題，雖然 kube-prometheus 為我們內(nèi)置了大量的監(jiān)控報警規(guī)則，但是也不能完全迷信，有時候并不一定適合實際的需求。