法人のお客さま
お問い合わせ
ビジネスブログ

Google Cloud Managed Service for Prometheus（GMP）を使ってみた

劉暁晨

プロダクト技術部
劉暁晨

2023年3月31日掲載

キービジュアル

こんにちは、ソフトバンクの劉暁晨です。

本業として、Google WorkspaceとMicrosoft 365に関する技術全般をサポートすることですが、社内副業制度を利用して、社内副業制度を利用して、AI技術を教える教育サービスAxross Recipeの開発にも同時に携わっています。

Axross Recipeのサービス基盤はKubernetes上で構築されているため、監視システムとしてGoogle Cloudが提供するGoogle Cloud Managed Service for Prometheusの導入を検討しましたので、本記事ではこちらのサービスについての利用方法、考察などについてまとめてみたいと思います。

又、同じく弊社エンジニアによる、AWSが提供するAmazon Managed Service for Prometheusについての記事もありますので、こちらの記事Amazon Managed Service for Prometheusを使ってみたも一緒にお読みいただくと、この2種類のマネージドPrometheusサービスを比較することができると思います。

目次

Prometheusとは

Kubernetesを利用する際に、実質的にスタンダードになったOSS監視ツールPrometheusです。特徴としては：

  •  Exporterを利用して、一般に使われているサービスから汎用的なMetrics（監視データ）を取得してもよし、自由にカスタマイズしたMetricsを出せるように、サービスを開発することもよし

  • 「PromQL」という、フレキシブルなクエリー言語

などが挙げられます。

アーキテクチャ的に、Prometheusは集権的なシステムではなく、複数のコンポーネントに分けられてお互い通信しながら機能するシステムとなっているため、自然的にKubernetesのようなMicro Service前提の環境との相性がいいです。

CKA Logo

Prometheusを構成する重要なコンポーネントとして、以下が挙げられます：

  • Prometheus server： 全ての監視データを収集、処理する中枢部です。

  • Alertmanager：メール、Slackなどに自動的にアラートを送信するコンポーネントです。

  • UI：監視データを可視化するためのダッシュボードサービス。この部分は本家のPrometheus UIより、3rd-partyのGrafanaの方が有名です。

Google Cloud Managed Service for Prometheusとは

Google Cloud Managed Service for Prometheus （以下GMPと略称）とは、Google Cloudが提供するPrometheusのマネージドサービスです。特徴としては、前述のPrometheusを構成する一部コンポーネントを、GCPの一部インフラに変えられたり、カスタマイズされた特殊バージョンを提供されたりして、運用負荷を下げられた形式でPrometheusを利用することができるようになります。

CKA Logo

具体的、以下の2つのコンポーネントに変更がありました：

Prometheus serverからMonarchに

Prometheusの本番運用上、特に大規模なサービス監視で、一番悩みの種となるのはPrometheus serverの部分と言われています。例えば、大量のMetricsデータをストレージに書き読みする際によく発生する性能低下と故障、監視対象の多さによりサーバ処理能力の不足などが挙げられます。

GMPのアプローチは、Prometheus serverの部分を、Google自身のあらゆるサービスを支えている地球規模のモニタリングインフラMonarchに変えました。

この変更によりもたらしたメリットとしては：

  • ストレージ、サーバ処理能力の心配から完全に解放されます。

  • Cloud Monitoringで提供されたGCPインフラに関するMetricsを、設定なしでPrometheusで利用できます。

  • UIコンポーネントを用意しなくても、Cloud MonitoringでPromQLを使ってダッシュボードを作成できます。

  • 必要であれば、Cloud Monitoring本来の機能、例えばMonitoring Query Language（MQL）とアラート設定なども使えます。

Prometheus Alertmanagerからマネージド Alertmanagerに

GMPを利用する際に、GKEクラスタ上マネージド Alertmanagerが自動的にデプロイされます。

マネージド Alertmanagerの特徴として、SlackのAPIトークンなどが書かれているAlermanagerの設定ファイルを、平文ではなく、Kubernetes Secret形式で利用するところです。若干安全性が向上するかもしれません。

注意点として、マネージド Alertmanagerは筆者が本文を作成する時点で、pre-GA状態になります（安定版ではありません）。また、従来通りに自分でPreometheus Alertmanagerをデプロイすることも可能です。

デプロイ手順

それでは、簡単にデータ収集からGrafana上でMetrics可視化、アラートルール作成まで、大まかな流れを簡単に説明したいと思います。

デプロイの前提として、GKE上でクラスタが事前に作成されていたことです。

また、今回の手順では、アプリからMetricsを取ることではなく、設定なしでも本来GCPが裏で常に取っているCloud MonitoringのMetricsをGMPで参照することを目標として設定します。

事前準備

gcloud config set project project1

  • GKEクラスタへの接続情報を取得：（asia-northeast1-a上、cluster1というクラスタが存在すると仮定）

gcloud container clusters get-credentials cluster1 --zone asia-northeast1-a

  • Kubectlのコンテキスト（接続情報）を見る：

kubectl config get-contexts

すると、接続可能なクラスタ情報一覧が表示されます。複数のKubernetesクラスタを扱う場合、複数の項目が見えます。

  • 正しいクラスタを指定：（get-contextsで見えた利用したい接続先の名前はgke_project1_asia-northeast1-a_cluster1と仮定）

kubectl config set-context gke_project1_asia-northeast1-a_cluster1

データ収集コンポーネントをデプロイ

このステップには2種類の方法があります。

従来、Kubernetes上のprometheusを構築するには、kube-prometheusなどprometheus-operatorベースのソリューションを使うことが一般的だと思いますが、既存のソリューションをほぼそのままGMPに移行することが可能です。しかしこの方法ではコンポーネントのマネジメントが必要となります。

今回は、もう1つの方法で、ゼロから完全マネージドなデータ収集コンポーネントのデプロイ手順を紹介します。

デプロイ

デプロイ自体は非常に簡単です。コマンド1行だけです。

gcloud container clusters update cluster1 --enable-managed-prometheus --zone asia-northeast1

モニタリング用Namespaceを作成

次は、後ほどGrafanaなどをデプロイするためのnamespaceを作成します。（名前はmonitoringと仮定）

kubectl create ns monitoring

モニタリング用Service accountを作成

GMPがCloud MonitoringからMetricsを取得できるための権限設定が必要です。以下のコマンドではgmp-test-saという名前のService accountを作成し、kubernetesクラスタ上のmonitoringというnamespaceのデフォルトService accountとして設定されます。

gcloud config set project project1 \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:project1.svc.id.goog[monitoring/default]" \
  gmp-test-sa@project1.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace monitoring \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@project1.iam.gserviceaccount.com

以後、このNamespaceで作成されたリソースは、デフォルトでこのgmp-test-saアカウントを利用することになる。

次に、gmp-test-saにモニタリング用の権限を付与します。

gcloud projects add-iam-policy-binding project1 \
  --member=serviceAccount:gmp-test-sa@project1.iam.gserviceaccount.com \
  --role=roles/monitoring.viewer

本番環境では、monitoring.viewerより絞られた権限の付与をお勧めします。

Grafanaをデプロイする

GKEのセキュリティ仕様上、Grafanaは直接GMPをデータソースに追加することができません。そのため、GMPとGrafanaの仲介役として、まずPrometheus UIを先にデプロイすることが必要です。

Prometheus UIをデプロイ

Googleが用意したYAMLファイルで簡単にデプロイできる。

curl https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.5.0/examples/frontend.yaml |
sed 's/\$PROJECT_ID/project1/' |
kubectl apply -n monitoring -f -

Grafanaをデプロイする

こちらも簡単にテスト用Grafanaをデプロイすることができる

kubectl -n monitoring apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.5.0/examples/grafana.yaml

本番環境であれば、Ingressなどを作ってServiceを公開する必要があると思いますが、今回はテスト目的のため、Port forwardを使って一時的にGrafanaのサイトを自分の端末上に転送することで利用できます。

kubectl -n monitoring port-forward svc/grafana 3000

これで自分の端末上のブラウザでhttp://localhost:3000からGrafanaを見えます。ちなみに初期usernameとpassword両方どちらでもadminです。

データ可視化

データソースを追加

具体的な手順は、こちらの公式ドキュメントを参照してください。

1つだけ注意点として、データソースを追加する際に使うURLです。もし上記の手順を踏まえてGrafanaをデプロイした場合、URLは公式よりさらに短縮できます：

公式：http://frontend.monitoringi.svc:9090

短縮：http://frontend:9090

これは、GrafanaとPrometheus UIが同じnamespaceにデプロイされたため、URLのnamespaceの部分が省略できます。

接続テスト

以下のテストPromQLを使って、Cloud MonitoringからMetricsを取得できるかどうかをためします（GKS上NodeのCPU利用率を調べるクエリー）：

rate(kubernetes_io:node_cpu_core_usage_time[1m]) * 100

もし全ての設定が正しければ、以下のようなグラフが見えるはず。

注意点としては、公式ドキュメント上記載されたのテスト用Query：

sum without(instance) (up)

は、結果を返せないはずです。これは本記事ではテスト用の監視対象Podのデプロイ手順をスキップしたためです。本記事の目的はあくまでCloud Monitoring上のデータを可視化することなので、Kubernetes上の監視については今回割愛させていただきます。

ダッシュボード作成

テストが成功したら、次は自分好みでダッシュボードを作成できます。

PromQLを使って、全てのCloud Monitoring Metricsを取得できますが、Metricsの名前をPromQL用に名前の変換が必要です。変換ルールはこちらの公式ドキュメントを参考にしてください。

変換が必要とはいえ、PromeQLを入力時は変換後の名前を自動補完してくれますので、心配する必要がありません。

また、全て利用可能なCloud Monitoring指標（Metrics）をまとめた公式ドキュメントはこちらになります。Kubernetes指標、Google Cloud指標辺りは一番利用頻度が高いと思います。

筆者が以下の簡単なダッシュボードを作成しました：

使用したPromeQLは：

  • ノードごとのCPU利用率：rate(kubernetes_io:node_cpu_core_usage_time[1m]) * 100

  • ノードごとのメモリ利用率：kubernetes_io:node_memory_allocatable_utilization{memory_type=\"non-evictable\"} * 100

  • 上位5個CPU利用率が高いPod：topk(5, rate(kubernetes_io:container_cpu_core_usage_time[1m]) * 100)

  • 上位5個メモリ利用率が高いPod：topk(5, kubernetes_io:container_memory_used_bytes / 1024 /1024)

PromeQLに詳しくない方は、公式ドキュメントを参照するか、紹介記事を検索してください。

ルール・アラート設定

ルール・アラート定義

ルール・アラートの定義は、Googleが定義したKubernetesリソースを使って設定します。

Rules、ClusterRules、GlobalRules、3種類が存在します。違いは名前の通り、適用範囲による違いなどがあります。

RulesとClusterRulesではCloud MonitoringのMetricsを参照できないため、今回はGlobalRulesを使ってルール・アラートを設定します。

例えば、以下のようなYAMLファイルを作成してください：

apiVersion: monitoring.googleapis.com/v1
kind: GlobalRules
metadata:
  name: global-rules
spec:
  groups:
    - name: test-alert
      interval: 30s
      rules:
        - alert: NodeHighCpuUsage
          expr: rate(kubernetes_io:node_cpu_core_usage_time[1m]) > 1.5
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: Node {{ $labels.node_name }} has a cpu usage higher than 150%.
        - alert: TestAlwaysFiringAlert
          expr: vector(1)

この設定ファイルで2つのアラートを設定しました。

  1. NodeのCPU利用率が150%以上になる場合、criticalレベルのアラートを発報する。

  2. テスト用のアラートを常時発報する。

以上のように、Kubernetesのリソースとは言え、spec:以下の内容は、本来のprometheusのルール・アラート設定と全く同じであるため、既存のprometheusルールの移行も容易になります。作成されたYAMLファイルをkuberctl apply -fコマンドで適用することで、ルール設定が反映されます。

マネージドAlertmanager

アラートを作成するだけでは、まだ実際にアラートをSlack通知などに出すことができません。本来では、Prometheus Alertmanagerを構築する必要がありますが、今回はGMPが提供するマネージドAlertmanagerを利用します。

マネージドAlertmanagerを利用するため、従来通りのPrometheus Alertmanagerの設定ファイルを用意し、特定の名前のkubernetes secretとして登録する必要があります。

まずは、alertmanager.yamlという名前のファイルを作成してください（ファイル名を変更しないでください）：

global:
  slack_api_url: '<slack_webhook_url>' # SlackのWebhook

route:
  receiver: "fall-back-receiver"
  group_by: [alertname]
  routes:
    - receiver: "slack-notifications"
      matchers:
        - severity="critical"

receivers:
  - name: "slack-notifications"
    slack_configs:
    - channel: '#alert' # アラート用Slackチャンネル名
  - name: "fall-back-receiver"

以上の例の設定ファイルでは、criticalレベルのアラートをSlackチャンネルに送信する設定となります。Slackへ送信に必要なWebhook URLの作成方法についてはこちらのドキュメントを参考にしてください。

マネジメントAlertmanagerのUI

Slackに送信される前に、AlertはまずマネジメントAlertmanagerに集約され、Group化、Silences設定などによって送信するかを判断するステップがありますが、残念ながらGMPの公式ドキュメントではマネジメントAlertmanagerのUIを参照する方法についての記述がありません。

しかし、GKE環境を軽く調査したところ、GKE上gmp-systemというnamespaceに自動デプロイされたAlertmanagerを見つけました。よって、以下のPort ForwardコマンドでAlertmanagerのUIを見ることができます：

kubectl -n gmp-system port-forward svc/alertmanager 9093

すると、ブラウザでhttp://localhost:9093を訪問するとAlertmanagerのWeb UIが見えるはず：

このUIを通して、発報中のアラート一覧、Silencesの設定などが便利にできると思います。

まとめ

今回はGoogle Cloud Managed Service for Prometheus（GMP）について紹介しました。一番の特徴としては、やはりGoogle自身が利用する地球規模の監視インフラを使っているところの安心感と、設定なしでCloud Monitor上のMetricsを利用できるところです。

利用したことがありませんが、同じく弊社のエンジニアによるAmazon Managed Service for Prometheus（AMP）の紹介を拝読したところ、GMPの方はAMPと比べ、より高度の機能を提供している一方、設定面は独自のカストマイズが必要となるところが多いという印象がありました。

また、今回は簡略化のため、同じプロジェクトのGKEで、Cloud MonitorのMetricsの利用のみ、シナリオを絞って書きましたが、GMPは任意のKubernetesのクラスタからの接続、Exporter、App自身によるMetricsの利用もサポートしています。

Prometheusの運用負荷に課題を感じている方、是非一度GMPの利用を検討することをお勧めします。

 ＼ 業務課題をデジタルで支援 ／

デジタルツールの選定から導入の手引きまで、中小規模のお客さまへわかりやすくお伝えします。

中小規模のお客さま向けサイトをみる

メールマガジン登録（無料）
ビジネスに役立つ記事やウェビナー情報をお届けします。

おすすめの記事

条件に該当するページがございません

法人のお客さま向け イベント

イベント・セミナー

ビジネスに役立つ 資料ダウンロード

資料ダウンロード

「今」と「未来」を発信 ソフトバンクのビジネスブログ

ビジネスブログ

クラウドテクノロジーブログ

クラウドテクノロジーブログ