指標が実際に流れるPrometheus

このラボは本物のPrometheusで動きます

VMの中でPrometheus・Alertmanager・node-exporterが実際に起動しています。node-exporterが本物の指標を出すので、PromQLが本物のデータを扱い、ルールは実際に評価され、アラートは実際に発火してAlertmanagerまで届きます。

PCAコースの他のラボが動く疑似クラスターには、Prometheus自体がありません。クエリを文章として書く練習までが、すべてでした。

kube-prometheus-stackは使いません。オペレーターが設定を代わりに書いてくれると、prometheus.ymlを触る機会がなくなりますが、PCAが問うのは、まさにそのファイルだからです。

最初の起動には3分ほどかかります。

用意されているもの

Prometheus     http://127.0.0.1:30090   설정은 /etc/prometheus/prometheus.yml
Alertmanager   http://127.0.0.1:30093
규칙           /etc/prometheus/rules/rules.yml
대상           node-exporter(데몬셋) · demo-app · Prometheus 자신
질의 도구      promq 'up'

目標

スクレイプ設定から、アラートがAlertmanagerに届くまでの全経路を自分でつなぎます。

なぜ重要なのか

Prometheusを扱ううえで、最もよく詰まる場所は、文法ではありません。

設定を直したのに反映されません。ConfigMapボリュームはkubeletが定期的に同期するので、すぐには変わりません(約60秒)。伝播する前にreloadを叩くと、古い設定をもう一度読み込み、reloadは200を返します。
アラートが来ません。ルールは発火したのに、alerting.alertmanagersを書いていないために、送る先がない場合がよくあります。
up == 0のアラートがかかりません。ターゲットが消えると、upの時系列自体がなくなります。up == 0は、ターゲットがあるのに応答しないときだけ真です。

最後が特に価値があります。「サービスが死ねばアラートが来るだろう」と信じていたのに、Podが丸ごと消えるデプロイ事故では、アラートは1つも来ません。

ステップ

今何をスクレイプしているかを確認して、記録してください(保存先: /root/pca/targets.txt)。
kubernetes_sd_configsで、Podを自動的に見つけるようにして、結果を記録してください(保存先: /root/pca/sd.txt)。
relabel_configsで、アノテーションが付いたものだけを残し、appラベルを作って、記録してください(保存先: /root/pca/relabel.txt)。
PromQLを書いて、記録してください(保存先: /root/pca/promql.txt)。instant=、range=、rate_result=の3行が必要です。
レコーディングルールを1つ作成し(名前はlevel:metric:operationの慣例)、結果が実際に出ることを記録してください(保存先: /root/pca/recording.txt)。
アラートルールを作成し、ターゲットを実際に故障させてfiringになるまでを記録してください(保存先: /root/pca/alert.txt)。for句も書きます。
PrometheusがAlertmanagerに送るようにして、実際に届いたことを記録してください(保存先: /root/pca/am.txt)。
レポート(/root/pca/report.md)に、up_targets=、alert_fired=yes、recording_rule=の3行と説明を書いてください。

参考

クエリはpromq 'up'で行います。結果はJSONなので、| jqで絞り込んでみてください。
設定ファイルを直したあとは、curl -XPOST http://127.0.0.1:30090/-/reloadを叩いてください。Podがそのディレクトリをhostパスのままで見ているので、直した瞬間に反映されます。
reloadが200でなければ、設定が文法的に間違っています。このときは古い設定がそのまま生きているので、サービスが死ぬことはありません。
ターゲットの状態は、curl -s $P/api/v1/targets | jqで確認します。droppedTargetsには、リラベルで除外されたものが入っています。
ステップ6でup == 0を作るには、ターゲットがあるのに応答しない必要があります。誰も待ち受けていないポートをstatic_configsで指すのが、最も確実です。
よくある間違い1: Podを削除してup == 0を作ろうとすることです。ターゲットが一覧から消えて、時系列自体がなくなります。そのような場合は、absent()で捉える必要があります。
よくある間違い2: レコーディングルール名にコロンを使わないことです。ルールが作った指標と元の指標を、名前だけで区別できなくなります。

今何をスクレイプしているか

今何をスクレイプしているかを確認して、記録してください(保存先: /root/pca/targets.txt)。

/api/v1/targetsと現在のprometheus.ymlを、一緒に見てください。

ターゲットを手で書かない

kubernetes_sd_configsで、Podを自動的に見つけるようにして、結果を記録してください(保存先: /root/pca/sd.txt)。

kubernetes_sd_configsのrole: podを使うと、Podが起動したり消えたりするたびに、一覧が追従します。

何を残して何を捨てるか

relabel_configsで、アノテーションが付いたものだけを残し、appラベルを作って、記録してください(保存先: /root/pca/relabel.txt)。

__meta_で始まるラベルは、リラベルの前にしか存在しません。keepで絞り込み、target_labelで新しいラベルを作ってください。

本物のデータでクエリする

PromQLを書いて、記録してください(保存先: /root/pca/promql.txt)。instant=、range=、rate_result=の3行が必要です。

instant=、range=、rate_result=の3行が必要です。カウンターにはrate()を使います。

あらかじめ計算しておく

レコーディングルールを1つ作成し(名前はlevel:metric:operationの慣例)、結果が実際に出ることを記録してください(保存先: /root/pca/recording.txt)。

名前はlevel:metric:operationの慣例に従ってください。コロンが入っていてこそ、元の指標と区別できます。

アラートを実際に発火させる

アラートルールを作成し、ターゲットを実際に故障させてfiringになるまでを記録してください(保存先: /root/pca/alert.txt)。for句も書きます。

up == 0は、ターゲットがあるのに応答しないときだけ真です。Podを削除すると、時系列自体が消えます。

アラートの行き先が必要

PrometheusがAlertmanagerに送るようにして、実際に届いたことを記録してください(保存先: /root/pca/am.txt)。

alerting.alertmanagersを書かないと、ルールが発火しても、どこにも行きません。

何を学んだのか

レポート(/root/pca/report.md)に、up_targets=、alert_fired=yes、recording_rule=の3行と説明を書いてください。

up_targets=、alert_fired=yes、recording_rule=の3行と説明を書いてください。