解決 Prometheus 監(jiān)控 Kubernetes Job 誤報的坑

作者：陽明 2022-03-06 09:51:04

云計算

云原生 要想做到監(jiān)控報警準確，其實我們只需要去獲取同一個 CronJob 觸發(fā)的一組 Job 的最后一次任務，只有該 Job 在執(zhí)行失敗的時候才觸發(fā)報警即可。

成都創(chuàng)新互聯(lián)公司一直通過網(wǎng)站建設和網(wǎng)站營銷幫助企業(yè)獲得更多客戶資源。 以"深度挖掘，量身打造，注重實效"的一站式服務，以成都網(wǎng)站設計、成都網(wǎng)站建設、移動互聯(lián)產(chǎn)品、成都全網(wǎng)營銷服務為核心業(yè)務。十余年網(wǎng)站制作的經(jīng)驗，使用新網(wǎng)站建設技術，全新開發(fā)出的標準網(wǎng)站，不但價格便宜而且實用、靈活，特別適合中小公司網(wǎng)站制作。網(wǎng)站管理系統(tǒng)簡單易用，維護方便，您可以完全操作網(wǎng)站資料，是中小公司快速網(wǎng)站建設的選擇。

昨天在 Prometheus 課程輔導群里面有同學提到一個問題，是關于 Prometheus 監(jiān)控 Job 任務誤報的問題(已經(jīng)同步到社區(qū)網(wǎng)站)，大概的意思就 CronJob 控制的 Job，前面執(zhí)行失敗了會觸發(fā)報警，后面生成的新的 Job 可以正常執(zhí)行后，但是還是會收到前面的報警：

這是因為一般在執(zhí)行 Job 任務的時候我們會保留一些歷史記錄方便排查問題，所以如果之前有失敗的 Job 了，即便稍后會變成成功的，那么之前的 Job 也會繼續(xù)存在，而大部分直接使用 kube-prometheus 安裝部署的話使用的默認報警規(guī)則是kube_job_status_failed > 0，這顯然是不準確的，只有我們?nèi)ナ謩觿h除之前這個失敗的 Job 任務才可以消除誤報，當然這種方式是可以解決問題的，但是不夠自動化，一開始沒有想得很深入，想去自動化刪除失敗的 Job 來解決，但是這也會給運維人員帶來問題，就是不方便回頭去排查問題。下面我們來重新整理下思路解決下這個問題。

CronJob 會在計劃的每個執(zhí)行時間創(chuàng)建一個 Job 對象，可以通過 .spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit 屬性來保留多少已完成和失敗的 Job，默認分別為3和1，比如下面聲明一個 CronJob 的資源對象：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  successfulJobsHistoryLimit: 1
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date;
          restartPolicy: OnFailure

根據(jù)上面的資源對象規(guī)范，Kubernetes 將只保留一個失敗的 Job 和一個成功的 Job：

NAME               COMPLETIONS   DURATION   AGE
hello-4111706356   0/1           2m         10d
hello-4111706356   1/1           5s         5s

要解決上面的誤報問題，同樣還是需要使用到 kube-state-metrics 這個服務，它通過監(jiān)聽 Kubernetes APIServer 并生成有關對象狀態(tài)的指標，它并不關注單個 Kubernetes 組件的健康狀況，而是關注內(nèi)部各種對象的健康狀況，例如 Deployment、Node、Job、Pod 等資源對象的狀態(tài)。這里我們將要使用到以下幾個指標：

• kube_job_owner：用來查找 Job 和觸發(fā)它的 CronJob 之間的關系。
• kube_job_status_start_time：獲取 Job 被觸發(fā)的時間。
• kube_job_status_failed：獲取執(zhí)行失敗的任務。
• kube_cronjob_spec_suspend：過濾掉掛起的作業(yè)。

下面是一個指標示例，其中包含 CronJob 觸發(fā)運行的hello 任務生成的標簽：

kube_job_owner{job_name="hello-1604875860", namespace="myNamespace", owner_is_controller="true", owner_kind="CronJob", owner_name="hello"} 1
kube_job_status_start_time{job_name="hello-1604875860", namespace="myNamespace"} 1604875874
kube_job_status_failed{job_name="hello-1604875860", namespace="myNamespace", reason="BackoffLimitExceeded"} 1
kube_cronjob_spec_suspend{cronjob="hello",job="kube-state-metrics", namespace="myNamespace"} 0

要想做到監(jiān)控報警準確，其實我們只需要去獲取同一個 CronJob 觸發(fā)的一組 Job 的最后一次任務，只有該 Job 在執(zhí)行失敗的時候才觸發(fā)報警即可。

由于 kube_job_status_failed 和 kube_job_status_start_time 指標中并不包含所屬 CronJob 的標簽，所以第一步需要加入這個標簽，而 kube_job_owner 指標中的 owner_name 就是我們需要的，可以用下面的 promql 語句來進行合并：

max(
  kube_job_status_start_time
  * ON(job_name, namespace) GROUP_RIGHT()
  kube_job_owner{owner_name != ""}
  )
BY (job_name, owner_name, namespace)

這里我們使用 max 函數(shù)是因為我們可能會因為 HA 運行多個 kube-state-metrics，所以用 max 函數(shù)來返回每個 Job 任務的一個結果即可。假設我們的 Job 歷史記錄包含 2 個任務(一個失敗，另一個成功)，結果將如下所示：

{job_name="hello-1623578940", namespace="myNamespace", owner_name="hello"} 1623578959
{job_name="hello-1617667200", namespace="myNamespace", owner_name="hello"} 1617667204

現(xiàn)在我們知道每個 Job 的所有者了，接著我們需要找出最后執(zhí)行的任務，我們可以通過按 owner_name 標簽聚合結果來實現(xiàn)這一點：

max(
  kube_job_status_start_time
  * ON(job_name,namespace) GROUP_RIGHT()
  kube_job_owner{owner_name!=""}
) 
BY (owner_name)

上面這條語句會找到每個 owner(也就是 CronJob)最新的任務開始時間，然后再和上面的語句進行合并，保留開始時間相同的記錄即為最新執(zhí)行的 Job 任務了：

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)

結果將顯示每個 CronJob 最后執(zhí)行的作業(yè)，并且僅顯示最后一個：

{job_name="hello-1623578940", namespace="myNamespace", owner_name="hello"} 1623578959

為了增加可讀性我們還可以將 job_name、owner_name 標簽替換為 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", "(.+)")

現(xiàn)在將會看到類似于下面的結果：

{job="hello-1623578940", cronjob="hello", job_name="hello-1623578940", namespace="myNamespace", owner_name="hello"} 1623578959

由于上面的查詢語句比較復雜，如果每次報警評估的時候都去進行一次實時計算會對 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", "(.+)")

現(xiàn)在我們知道了 CronJob 最近開始執(zhí)行的 Job 了，那么想要過濾出失敗的，則再使用 kube_job_status_failed 指標就可以了：

- 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", "(.+)"
      )

這里使用 clamp_max 函數(shù)將 job:kube_job_status_start_time:max 的結果轉(zhuǎn)換為一組上限為 1 的時間序列，使用它來通過乘法過濾失敗的作業(yè)，得到包含一組最近失敗的 Job 任務，這里我們也添加到名為 kube_job_status_failed:sum 的記錄規(guī)則中。

最后一步就是直接為失敗的 Job 任務添加報警規(guī)則，如下所示：

- alert: CronJobStatusFailed
  expr: |
    job:kube_job_status_failed:sum
    * ON(cronjob, namespace) GROUP_LEFT()
    (kube_cronjob_spec_suspend == 0)

為避免誤報，我們已將掛起的任務排除在外了。到這里我們就解決了 Prometheus 監(jiān)控 CronJob 的任務誤報的問題，雖然 kube-prometheus 為我們內(nèi)置了大量的監(jiān)控報警規(guī)則，但是也不能完全迷信，有時候并不一定適合實際的需求。

本文標題：解決Prometheus監(jiān)控KubernetesJob誤報的坑
本文URL：http://www.5511xx.com/article/djojoih.html