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

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

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

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

State of DevOps で、ソフトウェア デリバリーのパフォーマンスを向上させると認められた機能が報告されています。この記事では、次の機能について説明します。

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 では、アプリがポッドと呼ばれるコンテナのグループに配置されます。各 Pod は複数のポートを公開でき、Kubernetes Service を使用して、これらの Pod をグループ化して負荷分散を行えます。

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

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

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

Prometheus に GKE クラスタに関する情報を構成した後、Prometheus がサービス、ポッド、Ingress などの取得を開始するように、Kubernetes リソース定義に注釈を追加する必要があります。Prometheus は、Service にこの注釈が付いている場合に、取得ターゲット（エンドポイント、Pod）を検出できます。通常は 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 が Pod と Service の両方を取得するように構成されています。

Pod と Service を取得するように構成された Prometheus

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

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

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

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

GKE の Cloud オペレーションと Prometheus のペア設定

Prometheus サーバーをクラスタにデプロイするには、Prometheus に対応した GKE の Cloud オペレーションを使用します。このサーバーは、指標を外部指標として Cloud Monitoring に送信します。この機能を、複数のプロジェクト間の指標の集計を行う Monitoring の機能と組み合わせることで、複数のクラスタとプロジェクトを管理できます。

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

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

各クラスタで実行されている Prometheus を示すアーキテクチャ。Cloud Monitoring で集計された指標を表示できます。

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

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

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

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

次のステップ