Kubernetes Monitoring with Prometheus

AlertManager, Grafana, PushGateway (第二章)

Published in

Orangesys

21 min readFeb 13, 2019

前回第一章「The ultimate guide」紹介の続き、完成した「Prometheusを伴うKubernertesモニタリング」スタックはエンドポイントをスクレ―ピングすることでメトリックを収集する多くのPrometheusサーバーで構成されています。本物のKubernetesとマイクロサービスのモニタリングソリューションをデプロイするために、他にもたくさんのルールやアラート（AlertManager)、グラフィック表示レイヤー(Grafana),長期的なメトリックストレージ、また互換性がありすぐに使えるソフトウェアのための余分なメトリックアダプターなどを含む役立つコンポーネントが必要です。

この第二章では、私たちは簡単にそれらの全ての役に立ちコンポーネントをご紹介します。ただあなたが既に前章でのPrometheusモニタリングサーバーのデプロイの基本をもうご理解いただいているのが前提です。

この章は以下の4つの項目に分けられています。

Prometheusを伴うKubernetesモニタリング、基本的概念と最初のデプロイメント
Prometheusを伴うKubernetesモニタリング: AlertManager, Grafana, PushGateway (今読んでいる章):

AlertManager,KubernetesのためのPrometheusアラート
Grafana, Prometheus Dashboards
エフェメラルな作業のためのPrometheus メトリック — Push Gateway
Prometheus Persistent メトリックストレージ

3. Prometheus operator, Custom Resource Definitions（CRD）, Prometheusのために完全に自動化されたKubernetes デプロイメント, AlertManager と Grafana.

4. Prometheusのパフォーマンスに関する考慮事項、高可用性、外部ストレージ、ディメンション（次元）制限

Prometheus monitoring stack — Architecture overview

Prometheus serversについては第一章で説明しています。このデプロイメントのコアの部分にあります。Prometheusサーバーはwill push alerts to the AlertManager コンポーネントにアラートをプッシュします。 Alertmanager は異なる通知チャンネル、もしくはレシーバーを使って分類したり、特定のルートで送ったり、知らせたりします。
私たちはGrafanaのためにPrometheus データソースをコンフィグしますGrafanaは自身のウェブインターフェイスを通してデータの可視化やDashboardを提示します。
Kubernetes PersistentVolumesを使って私たちは長期的なメトリックストレージをコンフィグします。
私たちはまたエフェメラルなメンテナンス作業、やそれに関連したメトリックのメンテナンスも行います。PushgatewayはPrometheusサーバーが十分にメトリックを収集できる十分な期間を設けてそれらを保存する役割を担っています。

AlertManager, Prometheus alerting for Kubernetes

Prometheusを伴ったアラートは二つのパートに分かれています。

AlertManager はそれらをメタデータ（ラベル）をベースにグループ分けして、必要に応じてレシーバー：receiver (ウェブフック, email, PagerDuty, など…)を使ってそれらをミュートにしたり、知らせたりします。
AlertManagerは水平にスケールされるように設計されています。インスタンスは最小のコンフィギュレーションを提示するその仲間とコミュニケーションすることができます。

それでは基本的なコンポーネントから始めて、次のセクションでは、自分のクラスターの中ですぐに走らせることができる実践的な例をお見せします。

Prometheusのアラートルールの構造をおさらいしましょう。

groups:- name: etcdrules:- alert: NoLeaderexpr: etcd_server_has_leader{job=”kube-etcd”} == 0for: 1mlabels:severity: criticalk8s-component: etcdannotations:description: etcd member {{ $labels.instance }} has no leadersummary: etcd member has no leader

その「expr」キーは定期的に評価され、もしtrueなら発動するPrometheus expressionです。
一時的なアラートや自己修復異常を避けるため最低の評価時間を設定することができます。
Kubernetesコンテキストの中にある多くの他のものと同じように、自分が選んだラベルはグループ化や階層化に深く関係してきます。後でAlertManagerがどのアラートがより優先順位が高いのか、どのようにアラートをグループ分けするのかなどを決定します。それらはすべてラベルがベースになっています。

Prometheusサーバーが直接ウェブインターフェイス上にロードに成功したそのアラートを表示できます。(Status -> Rules)：

また今ファイアしているものです。(Alerts):

それでは、今AlertManagerに転送する今いくつかのアラート状態とアラートを保持しています。

メトリックのエンドポイントのように、AlertManager機能はまた異なるメソッド（DNS検索、Consul など）を使って自動判別されることもあります。

私たちがKubernetes コンテキストの中のPrometheusモニタリングについて話ているとしたら、私たちは基本的なKubernetesオブストラクション、つまり機能を利用できるということです。

alerting:alertmanagers:- scheme: httpstatic_configs:- targets:- “alertmanager-service:9093”

Prometheusサーバーの観点から見れば、このコンフィギュレーションは単なる静的なネームです。しかしKubernetesサービスは内部で転送している異なるHA/LoadBalancingを動かしています。

そのAlertManager それ自身は洗練されたソフトウェアで、基本のところを押さえています。

AlertManager は自分たちのレベルと紀元をベースとした異なるアラートをグループ分けします。
そのグラフ化と階層化は「ルーティングツリー」という形を作ります。どのアクションを起こせばよいのかを決める決定木です。
例えば、自分のルーティングツリーをコンフィグでき、ラベルk8s-cluster-componentを持つ全てのアラートが「cluster-admin」のメールアドレスにメールされます。
もし他のアラートがなっていたら、Inhibitionルールを使って、アラートもしくはグループのアラートが抑制されることがあります。例えばもし、クラスターがダウンして、完全に届かない状態になったら、個々のマイクロサービスの状態を知らせるポイントがなくなります。
アラートは、「レシーバー」に転送されることも可能です。これは、emailやPagerDuty、ウェブフックのようなお知らせゲートウェイです。

シンプルなAlertManagerコンフィグの例です：

global:resolve_timeout: 5mroute:group_by: [‘alertname’]group_wait: 10sgroup_interval: 10srepeat_interval: 1hreceiver: ‘sysdig-test’receivers:- name: ‘sysdig-test’webhook_configs:- url: ‘https://webhook.site/8ce276c4-40b5-4531-b4cf-5490d6ed83ae'

このルーティングツリーはただルートノードをコンフィギュアしただけです。

この例において、私たちは一般的なJSONウェブフックをレシーバーとして使っていてデプロイする必要はなく、自分の持っているサーバーhttps://webhook.site がテストをするための一定期間のエンドポイントを提示してくれます。（その例にある自分の特定のURLコードは明らかに変わります）

Prometheus monitoring with AlertManager, Try it out!

あなたはただ、そのレポジトリーのクローンを作って、正しい順番でyamlファイルを適用すれさえすればいいのです。

git clone git@github.com:mateobur/prometheus-monitoring-guide.gitcd prometheus-monitoring-guide/alertmanager-example/kubectl create cm prometheus-example-cm — from-file prometheus.ymlkubectl create cm prometheus-rules-general — from-file generalrules.yaml

それでは、https://webhook.site/にアクセスしてalertmanager.ymlファイルや、url: ‘your url here’ パラメーターで取得するランダムURLを配置しましょう。そして、

kubectl create cm alertmanager-config — from-file alertmanager.ymlkubectl create -f prometheus-example.yamlkubectl create -f alertmanager-deployment.yaml

2,3秒後、全てのポッドがRunning state（実行状態）になるはずです。

kubectl get podsNAME READY STATUS RESTARTS AGEalertmanager-deployment-78944d4bfc-rk2sg 1/1 Running 0 27sprometheus-deployment-784594c89f-fjbd6 1/1 Running 0 32sprometheus-deployment-784594c89f-gpvzf 1/1 Running 0 32s

Check the webhook URL, looking for the notification in JSON format:

このコンフィグレーションは「DeadManSwitch」を含みます。これはいつも発動するアラートで、全てのマイクロサービスのPrometheus -> AlertManager -> Notificationチャンネルがちゃんと機能しているかをテストするものです。

ウェブフックのURLをチェックしてください。JSONフォーマットの中でのお知らせを探しているものです。

Grafana, Kubernetes Monitoring with Prometheus — Dashboards

Grafana project はあまりよく理解できない分析、またはモニタリングプラットフォームです。Prometheusとは関係ありませんが、Prometheusソリューションを完全なものにする一番人気のアドオンコンポーネントの1つになりました。

私たちは、そのHelm Kubernetes package manager をこのデプロイメントに使います。そうすることで、リピートできるConfigMapsのセットを使うGrafanaをコンフィギュアできるようになります。ConfigMapsはどの手動のポスト・コンフィグレーションも避けます。

helm install — name mygrafana stable/grafana — set sidecar.datasources.enabled=true — set sidecar.dashboards.enabled=true — set sidecar.datasources.label=grafana_datasource — set sidecar.dashboards.label=grafana_dashboard

コンソールによってアウトプットされるhelmのインストラクションに注目してください。特に自分のアドミンパスワードを取得する方法をしっかりと確認してください。

kubectl get secret — namespace default mygrafana -o jsonpath=”{.data.admin-password}” | base64 — decode ; echo

あなたは直接そのgrafanaのサービスポートをインターフェイスにアクセスするために自分のローカルホストに転送することができます。

kubectl port-forward mygrafana-859c68577f-4h6zp 3000:3000

もしインターフェイスを見たいのであれば、自分のブラウザを使ってhttp://localhost:3000 にアクセスしてください。

二つのコンフィグレーションはGrafanaを利用するために必要です。

・データソース、Prometheusサーバー

・選んだメトリックを可視化するためのDashboard

あなたはコンフィグファイルからこの両方を自動コンフィギュアすることができます（可能ならすべきです）

もう一度ここで言いますが、ただ１つのURLを持ついくつかのPrometheusサーバーノードを示すために、私たちはそのサービスオブストラクションを使います。

url: http://prometheus-example-service:9090

そして、GrafanaはPrometheusが収集したメトリックのための可視化（ビジュアライゼーション）とDashboardを表示します。

Prometheus metrics for ephemeral jobs — Push Gateway

全てのプログラムがどんな時でもスクラップできる、継続的に動いているサービスではありません。全てのＩＴデプロイメントはバックアップのための無数のone-offもしくはcronタスク、クリーンアップ、メンテナンス、テストを持っています。

それらのタスクからメトリックを収集したいと思っていると思いますが、Prometheusのターゲット/スクラップモデルはここでは確実に機能しません。

そのためPrometheusプロジェクトはPushgateway serviceを提供してくれるのです。Pushgateway serviceは一時的なバッチジョブのためのプッシュアクセプターです。あなたはpushgatewayにメトリックをプッシュすることが可能です。そして、その情報を保持し、その後スクレープされます。

基本的な役に立つpushgatewayをデプロイすることは物凄くシンプルです。

kubectl create -f prometheus-monitoring-guide/pushgateway/

自分のpushgatewayポッドのサービスポートを転送します。

kubectl port-forward pushgateway-deployment-66478477fb-gmsld 9091:9091

そしてcurlを使ってメトリックをポストしてみてください。それは、基本的に自分のバッチジョブが行います。

echo “some_metric 3.14” | curl — data-binary @- http://localhost:9091/metrics/job/some_job

それでは、オリジナルソースがもう走っていなくても、このメトリックを普通にスクレープしてください。

curl localhost:9091/metrics | grep some_metric# TYPE some_metric untypedsome_metric{instance=””,job=”some_job”} 3.14

あなたはそれらの追加されたメトリックをリカバーするためにPrometheusコンフィギュレーションの中で通常通りのスクレープターゲットのように、ただ、pushgatewayを追加すればいいだけです。

Prometheus Persistent metrics storage

Prometheusサーバーはデフォルトで、ローカルフォルダーに15日間メトリックを保存します。またそのデフォルトのローカルポッドストレージは一時的なもので、そのポッドが何かの理由で置換られたら、すべてのメトリックは消えてしまうということを覚えておいてください。

リリース可能などのデプロイメントでも過去のメトリックデータと生き残ったポッドの再スタートを維持することができる持続性のあるストレージインターフェイスをコンフィギュアする必要があります。

もう一度言いますが、Kubernetesは既にこの役目を果たすオブストラクションを提供してくれています。PersistentVolumeです。

しかしながら、今お話したようにPersistentVolumeはただのdata volumeのためのオブストラクションです。そのため、あなたは実際のdata volumeを提供してくれるハードウェア/ソフトウェアが必要です。

その為にはいくつかの方法があります。

・メジャーなクラウドプロバイダーは通常すぐに使えるvolume orchestratorをエクスポーズしています。なので、ソフトウェアを追加してインストールする必要はありません。

・もし自分自身のホストを使っていて、まだストレージプロバイダーを持っていないのであれば、オープンソースがあります。Rook のようなCNCFが承認したソリューションもあります。

またもし、早く走らせたいと思っているのであれば、RookをインストールするためにHelm を使うのもいいでしょう。

・NetAppのようないくつかの商用ストレージでもまたKubernetesのpersistent（持続性のある）volumeのための互換性のあるレイヤーを使えます。

もしあなたが、ステートフルなストレージを使おうと思っているのであれば、デプロイメントするよりもKubernetes StatefulSetsを使う方がよいでしょう。全てのポッドは明確に別々になっているPersistentVolumeにくっつけられます。そのためポッドをキル、もしくは作ることができ、自動的に適切なvolumeに取りつけられます。

そのデプロイメントを壊すこともできますし、StatefulSetsを使って同じようなサービスを作ることもできます。

kubectl delete -f prometheus-monitoring-guide/alertmanager-example/prometheus-example.yamlkubectl create -f prometheus-monitoring-guide/storage/prometheus-example.yaml

全てのポッドはそれ自身のPersistentVolumeを作ります。

kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEpvc-b5a4aaa1–9584–11e8–97c9–42010a800278 50Gi RWO Delete Bound default/prometheus-metrics-db-prometheus-deployment-0 standard 4hpvc-f4ee61e4–9584–11e8–97c9–42010a800278 50Gi RWO Delete Bound default/prometheus-metrics-db-prometheus-deployment-1 standard 4h

以前に私たちが使っていたデプロイメントの間にも３つの異なるキーが存在します。そしてこのステートフルなセットは：

APIオブジェクトのタイプ：

kind: StatefulSet

そのセットの中でそれぞれのポッドのために作られるべきストレージを設定するVolumeClaim：

volumeClaimTemplates:- metadata:name: prometheus-metrics-dbspec:accessModes:- ReadWriteOnceresources:requests:storage: 50Gi

直接データを設定するPrometheusサーバーパラメーターと保存期間

containers:- args:- — storage.tsdb.path=/data- — storage.tsdb.retention=400d

平均では、Prometheusはサンプルごとに約1～2バイトしか使いません。このようにPrometheusサーバーのキャパシティーを計画するときには,大まかなフォーミュラを使ってください。

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

Prometheusサーバーはまた通常メトリックをリモートエンドポイントへ転送します。そして、ローカルでリーディングの最新のコミットされていないチャンクだけを保存します。Cortexや Thanosのようないくつかのクラウド・スケール/マルチサイトなPrometheusソリューションは、この特徴を利用しています。これについては最後にお話します。

Conclusions

この説明の最初の部分では、Prometheusサービスの基本的なことをお話しました。典型的なクラウド・スケールのデプロイメントにおいてのKubernetes orchestratorと異なるマイクロサービスの統合です。e Prometheusサーバーの一番コアなアラート、dashboards、長期的なストレージについての話をこの第二章でしました。私たちは実行可能なモニタリングソリューションにどんどん詳しくなってきています。

次の章では、私たちはどのようにprometheus operatorのKubernetesバージョンを使うかをご説明します。もっと自動的にスケーラブル、デクレラティブな方法で完全なスタックをより早くデプロイメントする方法です。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。