OpenTelemetry Operator による GKE での簡単なテレメトリー計測
Google Cloud Japan Team
※この投稿は米国時間 2022 年 10 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。
近年、アプリケーションのモニタリング活動は、計測ライブラリ、SDK、ストレージと可視化用のバックエンドが登場して急増しています。しかし、これらのライブラリによりアプリケーションを計測するために必要な投資は今でも重大な障壁です。また、ライブラリは多くの場合、少数のテレメトリー バックエンドに関連付けられています。
OpenTelemetry プロジェクトでは、テレメトリー データのオープン標準、多言語計測ライブラリ、コード変更が不要なアプリケーションの「自動計測」でこれらの課題に取り組んできました。コミュニティではこれらのソリューションをコンテナ化された環境で自動化する Kubernetes Operator も開発しています。
OpenTelemetry Operator は、コードを変更せずに新規および既存のアプリケーションでトレースと指標をエクスポートするための自動計測を行うことを目的としています。また、OpenTelemetry Collector のデプロイも自動化され、ベンダーに依存しないモニタリング パイプラインが実現します。これら 2 つの機能により、新規ユーザーのオンボーディング プロセスと、完全に計測されるアプリケーションのモニタリングをするための日常業務の負荷が簡素化されます。
このようなユースケースの中で、OpenTelemetry Operator を使用することで簡単に解決できる一般的な問題がいくつか見つかりました。これらを 1 つの GitHub リポジトリ（https://github.com/GoogleCloudPlatform/opentelemetry-operator-sample）にまとめて、Operator のインストールと操作のサンプルセットとチュートリアルを提供できるようにしました。この投稿では、OpenTelemetry Operator の利点と使用方法を紹介します。
OpenTelemetry Operator を使ってみる
Operator の主な機能として、OpenTelemetry Collector の管理と自動計測アプリケーションの管理の 2 つがあります。これらの Collector と計測はカスタム リソースで構成できます（この投稿で後述します）。
GKE クラスタがプロビジョニングされていれば、Operator のインストールは非常にシンプルです。前提条件は cert-manager のインストールのみです。Operator はこれを使用して Webhook 証明書を管理します。GKE Autopilot の場合、これを行うための最も簡単な方法は Helm を使用することです（これにより、Autopilot の操作に使用する追加の引数を渡せるようになります。詳しくはリポジトリのドキュメントをご覧ください）。
最終的に、Operator は次のように 1 回の
kubectl コマンドでインストールされます。その後、Operator は opentelemetry-operator-system 名前空間で実行され、テレメトリーに使えるようになります。ただし、そのためには Collector の設定が必要です。
Collector のデプロイと構成
Operator の 1 番目の主要機能は、OpenTelemetry Collector のインスタンスのインストール、管理、構成です。補足情報として、Collector は各種のプラグインと連携してテレメトリー データの処理とエクスポートを行います。このデータは、レシーバーにより各種のソースから取り込まれ、プロセッサにより送信中に変更ができ、エクスポータによりいくつかの一般的なテレメトリー バックエンド サービスにレポートすることができます。つまり、柔軟でベンダーに依存せず、計測にも依存しないオブザーバビリティを実現するためのルーティング ソリューションが提供されます。
Operator で Collector を設定するには、
OpenTelemetryCollector オブジェクトを作成します。これは名前空間付きのカスタム リソースなので、Collector を実行するのと同じ Namespace で作成されます。以下に例を示します。OpenTelemetryCollector オブジェクトには、Collector のデプロイを制御するための設定が数多くあります。たとえば、次のように mode: sidecar を設定すると、サイドカー コンテナとしてデプロイできます。
Operator は Collector サイドカーを sidecar.opentelemetry.io/inject: “true” というアノテーションがある Pod に挿入します。これはサイドカー Collector をリソース検出により実行するための一般的なパターンで、それぞれがテレメトリーをロード バランシングされた Collector サービスに転送し、ここからデータがエクスポートされます。この設定により、サイドカー Collector は Pod の正確なリソース情報を検出でき、サービス Collector は処理とエクスポートを 1 か所で行うことができます。
また、OpenTelemetryCollector オブジェクトを使用すると、Collector で使用する特定のコンテナ イメージを簡単に設定できます。これはカスタム Collector を扱う場合に非常に便利です。たとえば、Collector builder ツールでビルドされたものなどがこれに該当します（Collector ビルダーで作業するためのサンプル リポジトリが https://github.com/GoogleCloudPlatform/opentelemetry-collector-builder-sample にあります）。Collector をカスタム作成すると、Collector のビルドおよびデプロイ パイプラインの完全な制御が可能になり、Collector を必要なコンポーネントのみに分解できます。この結果得られるイメージは容量が小さくなり、セキュリティ上のリスクとなる依存関係領域も小さくなります。
たとえば、次の構成変更によりカスタム Collector イメージを実行します。
Collector がデプロイされると、Operator がそれをモニタリングし、アクティブであることと、設定との整合性を保つために調整されていることを確認します。これはたとえば、Collector の構成を変更する場合や、サイドカー アノテーションがある Pod を新規作成する場合などです。Collector のデプロイは Operator の機能の一つにすぎません。もう一つの主要機能は、アプリケーションの自動計測の管理です。
自動計測を Pod と Deployment に追加する
Operator の 2 番目の主要機能は、テレメトリーの自動計測を簡単にすることです。Collector でテレメトリーを取り込んで転送する準備ができていたとしても、一部のデータをレポートするためにアプリケーションを計測する必要はあります。一般的に、計測は手動または自動で実行できます。手動計測では OpenTelemetry SDK を使用するようアプリケーション コードを変更しますが、自動計測の場合は OpenTelemetry エージェントを使用して実行時に計測をプログラムに挿入します。
アプリケーションの自動計測は、手動計測に比べてエンジニアリングへの投資が明らかに少なくなります。そのため、OpenTelemetry にすみやかにオンボーディングするには最適な手法で、現在は Java、NodeJS、Python、.NET で作成されたアプリケーションで使用できます。また、複数の言語の自動計測を組み合わせることもできるため、多言語マイクロサービスを使用するシステム設計では便利です。
OpenTelemetry Operator ではこの自動計測は変更用 Webhook により行われ、サイドカー コンテナがアプリケーション Pod の仕様に組み込まれます。このサイドカー コンテナは計測エージェント コードを提供し、Pod のメインコンテナとファイルシステムを共有して、トレースをアプリケーションに組み込めるようにします。最も重要なことは、これらのどの処理でも、コードを作成する必要がないという点です。
自動計測を始めるには、まず計測オブジェクトを作成して、目的の計測設定（サンプルなど）を定義します。
OpenTelemetryCollector オブジェクトと同様に、Instrumentation も名前空間付きのカスタム リソースです。この場合、名前空間を設定することにより、アプリケーションのさまざまな部分に渡される自動計測設定を微調整できます（ただし、Pod も Namespace にまたがって Instrumentation を参照できます）。
Operator はこれらの設定を対応するアプリケーション Pod のアノテーションにマッピングします。このアノテーションは「instrumentation.opentelemetry.io/inject-<LANGUAGE>」という形式になります。これは自動計測で Pod をどう指定するかを表します。たとえば、Java アプリケーションを実行している Pod を自動計測するには、次のアノテーションを Pod のメタデータに追加します。
|
my-instrumentation の値は、以前に作成した Instrumentation オブジェクトの名前を参照します。これは別の名前空間の Instrumentation オブジェクトに設定することもできます。また、true に設定すると現在の名前空間からデフォルトの Instrumentation を選択し、false に設定すると Pod を自動計測から明示的に除外します。これらのオプションにより、さまざまなサービスのさまざまな構成を参照して、システム内のさまざまな計測構成を組み合わせることができます。使用できるすべてのアノテーションのリストは Operator の GitHub にあります。
Pod にアノテーションを付けると、Operator は自動的に変更を抽出し、Pod の仕様を更新して、自動計測サイドカー コンテナが含まれるようにします。同じ種類のアノテーションを Deployment（または CronJob や ReplicaSet などのあらゆる種類のレプリカ コントローラ）内の Pod で使用できます。アノテーションは Deployment で定義された Pod テンプレートのメタデータで設定するだけです。たとえば、Python アプリケーションを計測するには、アノテーションを以下の太字部分のように Deployment に追加します。
このアノテーションは Deployment ではなく Pod テンプレートのメタデータにあることに注意してください。また、アノテーションを Namespace のメタデータに追加して、参照されている計測構成を Namespace 内のすべての Pod に適用することもできます。たとえば、NodeJS の自動計測を次のコマンドで my-node-app Namespace のすべての Pod に組み込みます。
|
このように Namespace 全体にアノテーションを付けると、チャーンレートが高いクラスタ（サーバーレス アプリケーションなど）やマルチテナンシー設定にとって効果が高く、テナント プロジェクトにオブザーバビリティ設定を強制適用できます。その両方で、自動計測は実験だけではなく大規模な本番環境ワークロードにとっても有効なことが示されます。
GKE ユーザー向けのソリューション リポジトリ
Operator を使用すると、OpenTelemetry の収集と自動計測の設定が他の手動プロセスよりはるかに簡単になります。しかし、簡単なデモで試してみたいと考えている新規ユーザー向けに簡略化の余地がある手順はまだ残っていて、ドキュメントに記録すべき一般的な設定もまだあります。このために、Operator の使いやすさの向上を目的とした新しい GitHub リポジトリを https://github.com/GoogleCloudPlatform/opentelemetry-operator-sample に用意しました。
サンプルアプリ
このリポジトリには、すぐに使用できる構成ファイル、Operator のデプロイと操作のための簡略化されたコマンド、さまざまな言語で作成されたサンプルアプリが収録されています。これらのサンプルでは、Operator の設定、Collector の構成、各種のユースケースに対する自動計測の追加のエンドツーエンドのデモンストレーションが提供されます。
サンプルの中には、コードの変更を伴わない自動計測を紹介するための基本的なクライアント サーバー式 NodeJS アプリがあります。このアプリを自分でビルドして Operator とあわせて実行し、自動計測を試し、実際の動作を理解してから、既存のワークロードに追加するようにしてください。
このサンプルアプリは自分の本番環境用 NodeJS アプリケーションに置き換えてください。手順はまったく同じ（アノテーションを追加するだけ）です。
サンプルアプリで実験する場合でも、すでに本番環境ワークロードを自動計測している場合でも、このリポジトリで示されているレシピを活用すると、テレメトリーの取り込みパイプラインを構成するための次のステップが簡単にわかります。
構成レシピ
Operator のさまざまなユースケースのデモンストレーションができるように、Operator の各種の構成を網羅した一連のレシピを用意しました。各レシピをサンプルアプリとあわせて使うと高度なデモを実施できますが、本番環境での利用も可能で、実験の手順とデプロイの手順に違いはありません。
たとえば、Cloud Trace インテグレーション レシピは Collector 構成を更新し、GCP トレース バックエンドへのレポートができるようにします。これは本番環境のアプリケーションの場合と同じ構成で、すでに Operator で Collector を設定してある場合は次のコマンドで有効にできます。
|
今後もさまざまなユースケースに対応する構成をリポジトリに追加していく予定です。これらのレシピはすぐに利用が可能で、GKE で使いやすいように調整されていて、Cloud Build や Cloud Trace などの他の GCP プロダクトとの併用に最適になっています。
このリポジトリが、OpenTelemetry のオンボーディングと、Operator の本番環境への導入の両方でソースとして活用されることを期待しています。このリポジトリはオープンソースであり、投稿を受け付けています。リクエストや報告すべき問題があれば、ご遠慮なく GitHub でお問い合わせください。
- ソフトウェア エンジニア Mike Dame
