🔰

kube-state-metrics で始める Kubernetes アラート：まず初めに導入したい PromQL クエリ集

に公開
Kubernetes
SRE
monitoring
tech

この記事では、Kubernetes クラスターで導入されることの多い kube-state-metrics を利用して、実際の現場でよく使うアラートルールの PromQL クエリ例をユースケースごとに紹介します。

kube-state-metrics とは

kube-state-metrics は、Kubernetes クラスター上の deployment や pod などのさまざまなオブジェクトの状態を収集し、Prometheus で扱いやすいメトリクスとして公開してくれるサービスです。具体的なメトリクスについては、公式ドキュメントの一覧を見るのが分かりやすいです。

https://github.com/kubernetes/kube-state-metrics/tree/main/docs#exposed-metrics

ただし、これらのメトリクスを網羅的に全て把握・活用しようとするのはかなり大変です。そこで本記事では、現場ユースケースに沿った「まず最初に揃えておきたい」アラートの具体例をピックアップして紹介していきます。

Pod の状態監視

Pod の頻繁な再起動を検出する

Pod が繰り返し再起動している場合、アプリケーションに問題がある可能性が高いです。このような状態を検知するために、コンテナの再起動回数を表す kube_pod_container_status_restarts_total を利用します。

アラート条件の例:

increase(kube_pod_container_status_restarts_total{namespace="my-namespace"}[6h]) >= 6
and on(pod)
increase(kube_pod_container_status_restarts_total{namespace="my-namespace"}[1h]) >= 1

例では、6 時間で 6 回以上の再起動があり、かつ直近 1 時間でも再起動がある Pod がある場合にアラートが発火します。数値の部分は状況に応じて調整するのが良いと思います。継続的な問題を検出するために、異なるウィンドウでの再起動回数の増加数を利用します。

OOMKilled による再起動を検出する

メモリ不足による強制終了 (OOMKilled) が起き続けている場合は、メモリ割り当てを増強する必要があり、通常の再起動とは別で検知したい場合があります。この時、kube_pod_container_status_restarts_total に加えて、Pod の終了理由を表す kube_pod_container_status_last_terminated_reason を利用します。

アラート条件の例:

increase(kube_pod_container_status_restarts_total{namespace="my-namespace"}[1h]) >= 3
and on (uid)
kube_pod_container_status_last_terminated_reason{reason="OOMKilled",namespace="my-namespace"} == 1

例では、1 時間で 3 回以上の再起動があり、かつ最後の終了理由が OOMKilled の Pod がある場合にアラートが発火します。こちらも「1 時間で 3 回以上」の部分は状況に応じて調整するのが良いと思います。

Deployment の状態監視

レプリカが Ready でない状態を検出する

レプリカが期待する数だけ Ready にならない場合、アプリケーションの起動に問題がある可能性があります。このような状態を検知するために、期待するレプリカ数を表す kube_deployment_spec_replicas と Ready 状態のレプリカ数を表す kube_deployment_status_replicas_ready を利用します。

アラート条件の例:

kube_deployment_spec_replicas{namespace="my-namespace"}
- kube_deployment_status_replicas_ready{namespace="my-namespace"} > 0

この例では、Deployment の Ready なレプリカ数が期待値より少ない状態になった場合にアラートが発火します。ただし、ローリングアップデート時など一時的に Ready 数が減るケースでもアラートが発火してしまうため、実際にアラートルールを作る際は for: 10m のようにしばらく状態が続いた場合のみ通知するようにします。

ローリングアップデートが完了しない状態を検出する

Deployment のローリングアップデートが正常に行われない場合、アプリケーションの起動だけでなく停止にも問題がある可能性があります。この時、kube_deployment_spec_replicas に加えて、更新した Deployment 数を表す kube_deployment_status_replicas_updated を利用します。

アラート条件の例:

kube_deployment_status_replicas_updated{namespace="my-namespace"}
!= kube_deployment_spec_replicas{namespace="my-namespace"}

例では、更新されたレプリカ数が期待値と一致しない場合にアラートが発火します。このルールも、ローリングアップデート中など一時的に条件を満たすケースでアラートが発火しうるため、実際にアラートルールを作る際は for: で評価期間を設定します。

CronJob の状態監視

CronJob の実行失敗を検出する

CronJob で登録した定期ジョブが失敗している場合は、何か問題が起きている可能性が高いです。このような状況を検知するために、最後にスケジュールされた時刻を表す kube_cronjob_status_last_schedule_time と最後に成功した時刻を表す kube_cronjob_status_last_successful_time を利用します。

アラート条件の例:

(kube_cronjob_status_last_schedule_time{namespace="my-namespace", cronjob="my-cronjob"} offset 5m)
unless (
  kube_cronjob_status_last_successful_time{namespace="my-namespace", cronjob="my-cronjob"}
  >= (kube_cronjob_status_last_schedule_time{namespace="my-namespace", cronjob="my-cronjob"} offset 5m)
)

この例では、ジョブがスケジュールされてから 5 分以内に正常終了しなかった場合にアラートが発火します。5 分という時間は実際のジョブの処理時間に合わせて調整します。この PromQL は offset に指定した時刻分だけ前にスケジュールされたジョブを取得し、その中でまだ成功していないものだけを抽出するイメージです。

ジョブの失敗回数を表すメトリクスとして kube_job_failed も存在するので、kube_job_failed > 0 のような条件で失敗を検知することもできます。ただし、この方法だと ttlSecondsAfterFinished などで job オブジェクト自体が削除されるケースもあり、「問題が継続しているのにアラートが自動で消えてしまう」といったことがあり得ます。一方で、今回紹介したアラート条件は「最新の成功ジョブが走ればアラートが自動で解消される」ため、運用上もより現実的で効果的だと思っています。

まとめ

この記事では、kube-state-metrics を活用した、現場で役立つアラートルールの PromQL クエリ例を紹介しました。kube-state-metrics には今回取り上げた以外にもさまざまなメトリクスが用意されているため、サービスの運用をしている方は一度見てみるのがおすすめです。

GitHubで編集を提案

Discussion