※ このブログは、Independence with OpenTelemetry on Elastic を日本語訳し加筆等したものです。
より速く、よりスケーラブルなサービスを求める動きが活発化しています。私たちの日常生活は、お気に入りの食事を届けてもらうフードデリバリーアプリ、口座を管理するバンキングアプリ、さらには医者の予約を取るためのアプリなど、アプリに依存しています。これらのアプリは、機能面だけでなく、ユーザーのキャパシティの面でも成長できることが必要です。このような需要の高いクラウドアプリケーションは、その規模やグローバル展開の必要性から、ますます複雑化しています。
需要に対応するために、これらのオンラインアプリやサービス（例えば、モバイルアプリケーション、Web ページ、SaaS）のほとんどは、分散マイクロサービスベースのアーキテクチャと Kubernetes に移行しています。アプリをクラウドに移行した後、サービスの生産性、スケール、可用性をどのように管理・監視すればよいのでしょうか。OpenTelemetry は、Kubernetes アプリケーションのインスツルメンテーションとアプリケーションのテレメトリーデータ収集のためのデファクトスタンダードに急速になりつつあります。
OpenTelemetry (OTel) は、ソフトウェアのパフォーマンスと動作を理解するためのテレメトリーデータ（メトリクス、ログ、トレース）の生成、収集、エクスポートに使用できるツール、API、SDK のコレクションを提供するオープンソースプロジェクトである。OpenTelemetry は最近 CNCF のインキュベートプロジェクトとなり、コミュニティとベンダーのサポートが大幅に増加しています。
OTel は、標準的な遠隔測定フォーマットでアプリケーションを測定する標準的な方法を提供しますが、バックエンドや分析コンポーネントは提供しません。したがって、アプリケーション、インフラストラクチャ、およびユーザー体験のモニタリングに OTel ライブラリを使用することで、適切な観測ツールを柔軟に選択することができます。アプリケーションパフォーマンスモニタリング（APM）には、もはやベンダーロックインは存在しません。
Elastic Observability は OpenTelemetry とその OpenTelemetry プロトコル（OTLP）をネイティブにサポートし、トレース、メトリクス、ログをインジェストします。Elastic Observability の APM 機能はすべて OTel データで利用可能です。したがって、以下の機能（およびその他）が OTel データで利用可能です。
• サービスマップ
• サービスの詳細（レイテンシー、スループット、失敗したトランザクション）
• サービス間の依存関係
• トランザクション（トレース）
• ML相関（特にレイテンシーについて）
• サービスログ
ElasticのAPMとテレメトリーデータの統一ビューに加え、Elasticの強力な機械学習機能による解析、アラート機能によるMTTRの短縮が可能になります。
オープンソースの伝統から、Elastic は Prometheus、Fluentd、FluentBit、Istio、Kubernetes（K8S） など、他の CNCF ベースのプロジェクトもサポートしています。
このブログで紹介するのは、人気のOTelインスツルメンテッド・デモ・アプリ（HipsterShop）を Elastic Cloud に取り込むために設定する方法を、いくつかの簡単なステップで紹介します。
OTel データに関する Elastic APMの機能と特徴、そして Elastic に取り込まれたデータで何ができるかを説明します。
今後のブログでは、OTel のテレメトリ・データを使って Elastic の機械学習を行う方法、特定の言語向けの OTel アプリケーション・メトリクスをインストルメントする方法、OTel コレクタを使った Prometheus インジェストをサポートする方法などについて詳しく説明する予定です。ご期待ください。
前提条件と構成
このブログをご覧になる予定の方は、構成要素と設定に使用した詳細をご紹介します。
• Elastic Cloud のアカウントとデプロイ済みスタックがあることを確認します（こちらの手順を参照してください）。
• 私たちは、人気の高い HipsterShop のデモ・アプリケーションを使用しました。これはもともと Google によって書かれたもので、OpenTelemetry Demo App のような、多数のバリエーションが利用可能な Kubernetes を紹介するためのものです。このアプリを使用するには、ここに行き、指示に従ってデプロイしてください。
• さらに、私たちは、アプリケーションの OTel 手動インストルメンテーション・バージョンを使用しています。このブログの構成では、OTel の自動インスツルメンテーションは使用していません。
• 私たちのクラスタの場所 Google Kubernetes Engine (GKE) を使用しましたが、お好みの Kubernetes プラットフォームを使用することができます。
• Elastic は OTel で計測されたサービスから直接テレメトリーを取り込むことができますが、ここでは OpenTelemetry Collector を使用した、より伝統的なデプロイメントに焦点を当てます。
• Prometheus と FluentD/FluentBit は、伝統的にすべての Kubernetes データを引き出すために使用されていますが、ここではKubernetes Agent に対して使用されていません。フォローアップのブログで紹介します。
このブログでセットアップする構成は以下の通りです。
このブログで使用する OpenTelemetry データを取り込むための構成
すべての設定
これから数ステップにわたって、説明していきます。
• Elastic Cloud のアカウントを取得する
• GKE クラスタの立ち上げ
• アプリケーションを立ち上げる
• Kubernetes OTel Collector の configmap が Elastic Cloud を指すように設定する
• Elastic Observability APM と OTel データの併用による可視性の向上
ステップ 0: Elastic Cloud でアカウントを作成する
指示に従って、Elastic Cloud を開始します。
ステップ 1: K8S クラスターを起動する
今回は Google Kubernetes Engine（GKE） を使用しましたが、お好きな Kubernetes プラットフォームを使用することができます。Kubernetes クラスタから OpenTelemetry データを収集するために、Elastic に特別な要件はありません。GKE、EKS、AKS、Kubernetes 準拠のクラスター（セルフデプロイ、マネージド）であれば、通常の Kubernetes クラスターであれば動作します。
ステップ 2: HipsterShop アプリケーションをクラスターにロードする
選択したクラウドサービスまたはローカルのKubernetesプラットフォームで、アプリケーションをKubernetesクラスタに乗せましょう。私が使っているアプリケーションはこちらで公開しています。
Kubernetes上にアプリケーションが立ち上がると、デフォルトの名前空間上で以下のPod（またはその変種）が動作するようになります。
kubectl get pods -n default
以下のような出力になるはずです。
NAME READY STATUS RESTARTS AGE
adservice-f9bf94d56-5kt89 1/1 Running 0 41h
cartservice-54d5955c59-7lrk9 1/1 Running 0 41h
checkoutservice-57b95c78bb-qqcqv 1/1 Running 0 41h
currencyservice-6869479db8-7tsnj 1/1 Running 0 43h
emailservice-7c95b8766b-mp5vn 1/1 Running 0 41h
frontend-5f54bcb7cf-kxwmf 1/1 Running 0 41h
loadgenerator-bfb5944b6-2qhnw 1/1 Running 0 43h
paymentservice-5bc8f549c8-hkxks 1/1 Running 0 40h
productcatalogservice-665f6879d6-kv29f 1/1 Running 0 43h
recommendationservice-89bf4bfc5-ztcrr 1/1 Running 0 41h
redis-cart-5b569cd47-6wt59 1/1 Running 0 43h
shippingservice-768b94fb8d-8hf9c 1/1 Running 0 41h
このバージョンでは、すべてのサービスと loadgenerator のみを起動しました。OpenTelemetry Collector がまだ立ち上がっていないことに気づくでしょう。(次のステップを参照してください)。
個々のサービスの yamls を見てみると、ポート 4317 で OpenTelemetry コレクターを指していることがわかります。
- name: OTEL_EXPORTER_OTLP_ENDPOINT
value: "http://otelcollector:4317"
ポート 4317 は、OpenTelemetry がサービスからのテレメトリーをリッスンするデフォルトのポートです。 したがって、すべてのサービスが OTel コレクターを指すようにする必要があります。
ステップ 3: Elastic を指す OpenTelemetry Collector を起動する
otelcollector.yaml ファイルの /deeploy-with-collector-k8s にあるように、configmap セクションで設定が必要な特定の変数が 2 つあります。
exporters:
otlphttp/elastic:
endpoint: OTEL_EXPORTER_OTLP_ENDPOINT
headers:
Authorization: OTEL_EXPORTER_OTLP_HEADERS
Elastic の Observability の UI で APM の下に+データを追加、次の画面が表示されます。
OpenTelemetry の下に移動します。
OTEL_EXPORTER_OTLP_ENDPOINT は Elastic の APM サーバです。
OTEL_EXPORTER_OTLP_ENDPOINT はお客様の認可を提供します。
変数の詳細については、OTel コレクター設定に関する Elastic のドキュメントを参照してください。
これらの値はどこで取得するのでしょう？
ElasticのObservabilityのUIの「APM」の「+add data」で、以下の画面が表示されます。
OpenTelemetryの下に移動してください。
変数 OTEL_EXPORTER_OTLP_ENDPOINT（あなたの Elastic の APM Server のエンドポイント）と OTEL_EXPORTER_OTLP_HEADERS からの認証に値が表示されます。
Elastic の APM Server エンドポイントで OTel Collector を設定する場合、gRPC と http の2つのオプションがあります。
こちらの otelcollector.yaml では、exporter は http で設定されています。
APM サーバに gRPC のポートで送信したい場合は、そのように exporter を修正する必要があります。
exporters:
otlp/elastic:
endpoint: OTEL_EXPORTER_OTLP_ENDPOINT
headers:
Authorization: OTEL_EXPORTER_OTLP_HEADERS
otlphttp から otlp への変更に注意してください。上記のように必要な変更を行ったら、otelcollector を作成します。
kubectl create -f otelcollector.yaml
正常に稼働していることを確認します。
mycomputer% kubectl get pods | grep otelcollector
otelcollector-5b87f4f484-4wbwn 1/1 Running 0 18d
ステップ 4: Kibana を開き、APM Service Map を使用して OTel インストルメント化されたサービスを表示します
Elastic Observability UI の APM で、servicemap を選択すると、サービスが表示されます。
これが表示されていれば、OpenTelemetry Collector が Elastic にデータを送信していることになります。
おめでとうございます！ HipsterShop デモアプリケーションのサービスを OpenTelemetry でインスツルメンテーションし、Elastic にテレメトリーデータを取り込むことに成功しました！これで、HipsterShop デモアプリケーションをトレースできるようになります。
特定の環境を構成する方法
Elastic APM では、複数のアプリケーションを取り込むことができ、環境に応じてフィルタリングすることができます。したがって、開発チーム1と開発チーム2が共に UI を使用している場合、環境変数を適切に設定する必要があります。
このアプリケーションの環境変数の設定は、サービスの yamls にある deployment.environment 変数によって行われます。
これを変更したい場合は、このブログのアプリケーションの git にある各 service yaml の OTEL_RESOURCE_ATTRIBUTES を変更する必要があります。
下記の内容を：
- name: OTEL_RESOURCE_ATTRIBUTES
Value: "service.name=recommendationservice,service.version=
1.0.0,deployment.environment=MY-DEMO"
このように変更します：
- name: OTEL_RESOURCE_ATTRIBUTES
Value: "service.name=recommendationservice,service.version=
1.0.0,deployment.environment=XXX"
すべてのサービスでこれを行うには、次を実行します。
sed -i `s/MY-DEMO/XXX/g` *.yaml
ステップ5：Elastic は何を見せてくれるのか？
OpenTelemetry のデータが Elastic に取り込まれたところで、何ができるのでしょうか？
まず、APM サービスマップを見ることができます（前のステップで示したとおり）。これにより、すべてのサービスとサービス間のトランザクションフローを完全に見ることができます。
次に、個々のサービスや収集されたトランザクションを確認することができます。
ご覧の通り、フロントエンドの詳細が記載されています。下記の全てです。
• 平均サービス遅延
• スループット
• メイントランザクション
• 失敗したトラクション率
• エラー数
• 依存関係
トレースに取り掛かりましょう。トランザクションタブでは、フロントエンドサービスに関連するすべてのタイプのトランザクションを確認することができます。
/cart/checkout のトランザクションを選択すると、すべてのスパンを含む完全なトレースが表示されます。
このトランザクションの平均待ち時間、スループット、あらゆる障害、そしてもちろんトレース情報!
トレースを確認するだけでなく、/chart/checkout のレイテンシーが通常より高いことに何が関係しているのかを分析することができます。
Elastic は機械学習を利用して、トレースからサービス全体のレイテンシーに関する潜在的な問題を特定することができます。「レイテンシー相関」タブを選択し、相関を実行するだけの簡単な作業です。
これは、クライアント 10.8.0.16 からのトランザクションが、このトランザクションに対して異常なレイテンシーを持つ可能性があることを示しています。
トレースビューから直接ログをドリルダウンし、トレースに関連するログを確認することで、潜在的な問題を特定し、ピンポイントで解決することができます。
Elastic の機械学習（ML）でデータを分析する
OpenTelemetry のメトリクスを Elastic に取り込んだら、Elastic の ML 機能を使ってデータ分析を始めましょう。
これらの機能に関する素晴らしいレビューはこちらでご覧いただけます ： APM テレメトリを関連付けて、トランザクションの根本原因を特定する。
また、Elastic のブログには他にもたくさんのビデオやブログがあります。
Elastic の機械学習機能を OpenTelemetry データに活用するためのブログも追加していきます。
まとめ
Elastic Observability が、Elastic の APM 機能を使って OpenTelemetry のデータを取り込み、分析するのに役立つことをご理解いただけたかと思います。
簡単な要約と、より具体的に学んだこと:
• 人気の OTel インスツルメンテッド・デモアプリ （HipsterShop） を Elastic Cloud に取り込むように設定する方法を、いくつかの簡単なステップで説明します。
• OTel データに関する Elastic APM の機能と特徴、そして Elastic に取り込まれたデータを使って何ができるかを紹介します。
さあ、始めましょう。Elastic Cloud にサインアップし、上記で紹介した機能を試して、OpenTelemetry データの価値と可視性を最大限に引き出してください。
Elastic Technical Product Marketing Manager/Evangelist
鈴木章太郎