Prometheus での GKE のホワイトボックスアプリのモニタリング

この記事では、Prometheus と Stackdriver を使用して、多数の Google Kubernetes Engine（GKE）名前空間、クラスタ、Google Cloud Platform（GCP）プロジェクトに広がる大規模で複雑なアプリのホワイトボックスモニタリングを行う方法について説明します。

多数のマイクロサービスが存在する大規模な本番環境を運用するのは困難です。この課題に対処するため、サイト信頼性エンジニア（SRE）は、さまざまな詳細レベルの複数のソースからのデータを利用します。このデータを使用してサービスを改善することで、ユーザーエクスペリエンスの向上を実現できます。また、こうしたデータを使用して、サービスにおいて発生する可能性のある問題（コードのデプロイのデバッグなど）を診断することもできます。GKE はマイクロサービスアーキテクチャのデプロイに役立ちますが、こうしたマイクロサービスを効率的かつ確実に運用するには、スケーラブルでダイナミックなモニタリングシステムが必要です。

Stackdriver Kubernetes Monitoring を使用すると、1 つのツールでブラックボックスとホワイトボックスの両方のモニタリングが可能になります。アプリのホワイトボックスモニタリングでは、現在のメモリ使用量やリクエストのレイテンシなど、アプリ内の指標やシグナルを使用して、問題を検出したり予測したりします。ブラックボックスモニタリングでは、外部から見える動作（たとえば、ページの読み込み時間）をシグナルとして使用します。

Prometheus

Prometheus は、Google の内部モニタリングシステムである Borgmon の影響を受けたモニタリングとアラートのためのオープンソースのツールキットです。Borg が Kubernetes のオープンソースプロジェクトに影響を与え、Borgmon が Prometheus に影響を与えました。ツールは互いにうまく機能します。

Prometheus を使用すると、構成可能な間隔で行われるクエリ（つまり取得）の対象となる取得ターゲットを構成して、多数のマシンを調べてそこに存在する指標を検出して pull できます。取得ターゲットは通常、アプリケーションから公開される HTTP エンドポイントで、1 行に 1 つの指標がある明確な表示形式を使用します。取得ターゲットのデフォルトの転送メカニズムとして HTTP を使用すると、さまざまな言語とエンドポイントの指標を公開できます。

一般的なプログラミング言語用のクライアントライブラリが用意されているので、指標のエンドポイントを既存のアプリにすばやく追加できます。Istio や etcd などの多くのクラウドネイティブツールは、Prometheus の指標を公開しています。さらに、Consul、MySQL、Redis などの一般的なアプリケーションやフレームワークに対して Prometheus の指標を公開する Prometheus のエクスポータが数多く存在します。

以下のアーキテクチャ図では、取得ターゲットから収集された指標が Prometheus の時系列データベースに格納されています。

時系列データベースに指標を格納する

このデータベースは、大規模システムで一般的な高カーディナリティで高スループットの指標のユースケースに最適化されています。指標が格納されたら、豊富なクエリ言語を使用して、指標を便利な形式で操作できます。言語の構文では、基本的な演算子と複雑な関数をネイティブな方法で使用できます。

Prometheus による GKE のモニタリング

GKE では、アプリがポッドと呼ばれるコンテナのグループに配置されます。各ポッドは複数のポートを公開でき、Kubernetes サービスを使用して、これらのポッドをグループ化して負荷分散を行えます。

アプリで Prometheus 互換のライブラリを使用すると、ライブラリは追加のポートとエンドポイント（デフォルトでは 9090 と /metrics）を公開します。Kubernetes SD 取得構成を設定することで、GKE 内のアプリケーションを自動的に検出するように Prometheus を構成できます。この構成により、Prometheus で Kubernetes API に対してクエリを実行し、追加の構成なしで新しい取得ターゲットを検出できます。ただし、以下の複数の取得ターゲット検出メカニズムを構成できます。

ポッド: 各ポッドのターゲット。
サービス: 各サービス IP とポートの組み合わせのターゲット。
エンドポイント: 各エンドポイントリソースのターゲット。
ノード: 各 GKE ノードのターゲット。
Ingress: Ingress 仕様の各ホストのターゲット。

Prometheus がターゲットを検出すると、それらを取得して生の指標データを取得します。データを保存する前に、Prometheus は GKE API から受け取った情報に基づいて指標にラベルを追加します。たとえば、ポッドが実行されている名前空間を格納するラベル、ポッドの名前、ポッドに追加した任意のラベルを追加することで、ポッドから取得した指標を拡充できます。

Prometheus に GKE クラスタに関する情報を構成した後、Prometheus がサービス、ポッド、Ingress などの取得を開始するように、Kubernetes リソース定義に注釈を追加する必要があります。Prometheus は、サービスにこの注釈が付いている場合に、取得ターゲット（エンドポイント、ポッド）を検出できます。通常、prometheus.io/scrape: "true" が使用されますが、任意のキーを構成できます。

たとえば、次のサービスではデフォルトのポート（9090）を取得し、カスタムパス（/stats）を取得します。

apiVersion: v1
kind: Service
metadata:
 annotations:
   prometheus.io/scrape: 'true'
   prometheus.io/path: '/stats'
 labels:
   app: demo
 name: demo
spec:
 ports:
 - port: 8080
   protocol: TCP
   targetPort: 8080
 - port: 9090
   protocol: TCP
   targetPort: 9090
 selector:
   app: demo

GKE を取得するように構成された Prometheus の別の例をご覧ください。

次の図では、Prometheus がポッドとサービスの両方を取得するように構成されています。

ポッドとサービスを取得するように構成された Prometheus

OpenCensus でアプリをインストゥルメント化する

前述のように、Prometheus を使用してアプリをモニタリングするには、アプリが HTTP エンドポイントでデータを正しい形式で公開している必要があります。Prometheus ヘルパーライブラリでは、こうしたエンドポイントを効率的かつ慣用的に追加できます。

OpenCensus はベンダーに依存しないライブラリのセットで、アプリから指標やトレースをエクスポートできます。OpenCensus には Java、Go、Node.js、Python のライブラリが存在し、Prometheus をはじめとして、さまざまなバックエンドに指標とトレースを提供する手段をアプリに装備できます。OpenCensus でインストゥルメント化するメリットは、使用しているエクスポータに関係なく、サーバーから直接サーバープロセスの指標を一目で把握できるように、アプリで zPages を公開できることです。zPages は、開発中や、本番環境で問題が発生したときに特定のプロセスを分析するために役立ちます。

指標のみの公開に焦点を当てる場合は、Prometheus クライアントライブラリの機能を使用できます。

Stackdriver と Prometheus のペア設定

Prometheus サーバーをクラスタにデプロイするには、Prometheus をサポートする Stackdriver Kubernetes Monitoring を使用できます。このサーバーは、指標を外部指標として Stackdriver に送信します。この機能を、複数のプロジェクト間の指標の集計を行う Stackdriver の機能と組み合わせることで、複数のクラスタとプロジェクトを管理できます。

新しいアプリと指標が作成されると、Stackdriver に自動転送され、データ保持ポリシーに従って保持されます。Stackdriver の組み込み機能を使用してアラートと稼働時間チェックを一元的に構成すると、データを相互に関連付けたり、クラスタやリージョンに広がる問題の通知を受けたりできます。

次のアーキテクチャ図では、Prometheus が各クラスタで実行され、Stackdriver で集計された指標が表示されています。

各クラスタで、Stackdriver で集計された指標を表示できるようにする Prometheus が実行されていることを示すアーキテクチャ

既存のシステムのブリッジ

ほとんどのお客様と同様に、稼働中のシステムの関連データを保存するために既存のモニタリングシステムがあるとします。インストゥルメンテーションコードの量とアプリの数が増えるにつれて、アプリのインストゥルメンテーションを新しい指標形式または時系列データベースに移行するコストが増加します。Stackdriver への移行の複雑さを軽減するために、Prometheus エクスポータを Graphite や StatsD などの他のモニタリングシステムに使用できます。次に、そのエクスポータを使用して、既存のシステムから、Prometheus が取得して Stackdriver に送信できる中間エクスポータプロセスに指標を送信します。

次の図は、Prometheus 経由で一連の Compute Engine インスタンスから Stackdriver に送信される Graphite 指標の例を示しています。

一連の Compute Engine インスタンスから Stackdriver に送信される Graphite 指標

次のステップ

Stackdriver の Prometheus との統合について読む。
Stackdriver Kubernetes Monitoring について学習する。
Google Cloud Platform のその他の機能を試す。チュートリアルをご覧ください。