Elastic Observability でのネイティブ OpenTelemetry サポート

著者:バーフバリシェティ

OpenTelemetry は、可観測性のための単なるオープン取り込み標準ではありません。Kubernetes と同じくらい多くのコミットを伴う主要な Cloud Native Computing Foundation (CNCF) プロジェクトの 1 つとして、このフレームワークを強化するために主要な ISV やクラウドプロバイダーからのサポートを得ています。金融、保険、テクノロジー、その他の業界の多くのグローバル企業が OpenTelemetry の標準化を始めています。OpenTelemetry を使用すると、DevOps チームはテレメトリデータの収集と取り込みに一貫したアプローチを採用でき、事実上の可観測性標準を提供できます。

Elastic® は、主要なデータ収集アーキテクチャの可観測性とセキュリティを可能にするために、OpenTelemetry を戦略的に標準化しています。さらに、Elastic は、OpenTelemetry が可観測性エコシステムにとって事実上最高のデータ収集インフラストラクチャになるよう支援することに取り組んでいます。最近の Elastic Common Schema (ECS) による OpenTelemetry (OTel) への貢献に加え、Elastic は OpenTelemetry との関係を深めています。

Elastic 7.14 以降、Elastic は OpenTelemetry をネイティブにサポートし、OpenTelemetry Protocol (OTLP) ベースのトレース、メトリクス、ログを直接取り込むことができるようになりました。

このブログでは、Elastic が提供する現在の OpenTelemetry サポートを確認します。これには次のものが含まれます。

Python、NodeJS、Java、Go、.NET で構成された OpenTelemetry プロキシを使用して、アプリケーションの分散トレースとメトリクスを簡単に取得します
OpenTelemetry は、さまざまな構成を使用してレコードの検出と取り込みを行います
ECS オープンログなどのセマンティック規約により、これは OpenTelemetry の一部ではありません。
ネイティブ OTLP テレメトリでは、レイテンシ相関、障害相関、異常検出、ログピーク分析、予測パターン分析、エラスティック AI アシスタントサポートなどの機械学習ベースの AIOps 機能を利用できます。
自分のペースでアプリケーションを OpenTelemetry に移行します。Elastic の APM 機能は、OpenTelemetry や Elastic APM エージェントのハイブリッドサービスを使用している場合でもシームレスに動作します。OpenTelemetry インストルメンテーションと Elastic Agent を組み合わせることもできます。
ビューと分析を、ほとんどの OpenTelemetry アプリケーションが実行される Kubernetes クラスターと統合します。OpenTelemetry ベースのアプリケーションの問題を分析する場合、Elastic は各サービスに関連する特定のポッドとコンテナーを強調表示できます。

OpenTelemetry を Elastic に導入する

OpenTelemetry トレースとメトリクスを Elastic に取り込むのがいかに簡単かを知りたい場合は、このブログで概説されている手順に従ってください。

Elastic が OpenTelemetry データを取り込むために提供する機能の概要を説明します。すべてのオプションは次のとおりです。

OpenTelemetry コレクターの使用

最も一般的な構成オプションである OpenTelemetry Collector を使用する場合、追加する必要があるのは 2 つの主要な変数だけです。

これらの手順では、Elastic 固有の opentelemetry-collector 構成を使用します。基本的に、elastic/opentelemetry-demo で指定された Elastic value.yamlファイルは、次の 2 つの主要な値を使用して Elastic APM サーバーを指すように opentelemetry-collector を構成します。

OTEL_EXPORTER_OTLP_ENDPOINT は Elastic の APM サーバーです
OTEL_EXPORTER_OTLP_HEADERS エラスティックライセンス

これら 2 つの値は、Elastic Cloud の APM 統合手順 (統合 -> APM) の OpenTelemetry セットアップ手順に記載されています。

コードに埋め込まれたネイティブ OpenTelemetry プロキシ

コード内で OpenTelemetry ライブラリを使用することを検討している場合は、ネイティブ OLTP プロトコルをサポートしているため、サービスを Elastic の APM サーバーに指定するだけで済みます。特別な弾性変形は必要ありません。

これを効果的に実証し、OpenTelemetry の使用方法を教育するために、学習用の 2 つのアプリケーションを用意しています。

OpenTelemetry デモの Elastic バージョン: 他のすべての可観測性ベンダーと同様に、当社は OpenTelemetry デモの独自のフォークバージョンを持っています。

Elastiflix : このデモアプリケーションは、さまざまな言語とテレメトリ信号で検出を実行する方法を学習するのに役立つ例です。

OpenTelemetry での Elastiflix アプリケーションとインストルメンテーションの使用に関するブログをご覧ください。

Elastiflix アプリケーション、OpenTelemetry を使用してさまざまな言語を検出するためのガイド
Python:自動検出、手動検出
Java:自動検出、手動検出
Node.js:自動検出、手動検出
.NET:自動検出、手動検出

次のトピックに関する YouTube ビデオも作成しました。

Elastic と OpenTelemetry の大規模なユーザーベースを考慮すると、これらは OpenTelemetry インストルメンテーションの複雑さを学ぼうとする人にとって豊富な教育リソースを提供します。

OpenTelemetry をサポートするエラスティックプロキシ

すでに OpenTelemetry を実装している場合は、引き続き OpenTelemetry で使用できます。現在、Elastic APM エージェントは、トレースの一部として OpenTelemetry スパンを送信できるようになりました。これは、OpenTelemetry スコープを発行するコンポーネントがアプリケーションにある場合、それが Elastic APM エージェントによってキャプチャされたトレースの一部になることを意味します。

OpenTelemetry Elastic へのログイン

OpenTelemetry のドキュメントを見ると、多くの言語ライブラリがまだ実験段階であるか、まだ実装されていないことがわかります。ドキュメントによると、Java は安定した状態にあります。サービスの言語や冒険心の強さに応じて、サービスやアプリケーションからログをエクスポートし、可観測性バックエンドでそれらを結合するためのさまざまなオプションがあります。

前回のブログでは、Elastic for Java にデータを正しく記録するための 3 つの異なる構成について説明しました。このブログでは、OpenTelemetry ログの最新テクノロジーを調査し、次のテナントに利用可能な方法に関するガイダンスを提供します。

サービスログを OTel によって生成されたトレースと関連付けます (該当する場合)
例外を正しくキャッチする
トレース、メトリック、ロギングにわたる共通のコンテキスト
slf4j キーと値のペア (「構造化ログ」) のサポート
OTel 手荷物を通じてサービス間で運ばれるメタデータを自動的に添付します
Elastic Observability バックエンドの使用
アプローチに関係なく、Elastic ではデータの忠実性が一貫しています。

現在、アプリケーションまたはサービスのログを Elastic に送信し、それらを OTel トレースおよびバゲッジと関連付けるための 3 つのモデルがブログで説明されています。

埋め込み OpenTelemetry Instrumentation ライブラリを使用して、OTLP プロトコル経由でサービスから Elastic にログ (およびトレースとメトリクス) を出力します。
サービス内のログを OpenTelemetry Collector によってキャプチャされたファイルに書き込み、OTLP プロトコルを通じて Elastic に転送します。
サービスから Elastic Agent (または Filebeat) によってキャプチャされたファイルにログを書き込み、Elastic によって定義されたプロトコルを介して Elastic に転送します。

(2) および (3) とは対照的に、(1) では Elastic に取り込む前にサービスログをファイルに書き込む必要がないことに注意してください。

OpenTelemetry は Elastic の優先モードです

Elastic は最近、Elastic Common Schema (ECS) を OpenTelemetry (OTel) プロジェクトに提供し、OTel セマンティック規約フレームワーク内でセキュリティおよび可観測性データの統一データ仕様を可能にしました。

ECS は、Elastic ユーザーコミュニティのサポートを受けて開発されたオープンソース仕様で、Elasticsearch® にイベントデータを保存するときに使用する共通のフィールドセットを定義します。ECS は、データの重複によって発生する管理コストとストレージコストを削減し、運用効率を向上させます。

同様に、OTel の意味規則 (SemConv) でも、さまざまな操作とデータの共通名が指定されています。OTel SemConv を使用する利点は、コードベース、ライブラリ、および OTel ユーザーのプラットフォーム全体で標準化できる共通の命名スキームに従っていることです。

ECS と OTel SemConv の合併は、OTel の採用と可観測性とセキュリティの継続的な成長と統合を推進するのに役立ちます。

Elastic Observability APM と機械学習機能

Elastic Observability のすべての APM 機能は、OTel データで利用できます (これについて詳しくは、ブログ「Independent with OpenTelemetry」を参照してください)。

サービスマップ
サービスの詳細 (遅延、スループット、失敗したトランザクション)
サービス間の依存関係
トランザクション (追跡)
ML の依存関係 (特にレイテンシー)
サービスログ

Elastic の APM およびテレメトリデータの統合ビューに加えて、Elastic の強力な機械学習機能を使用して分析を削減し、アラートを生成して MTTR を削減できるようになりました。弊社が提供する ML ベースの AIOps 機能の一部を以下に示します。

異常検出: オンにすると (ドキュメントを参照)、Elastic Observability は OpenTelemetry データの通常の動作 (学習傾向、周期性など) を継続的にモデル化することにより、異常を自動的に検出します。
ログ分類: Elastic は OpenTelemetry ログイベントのパターンを迅速に特定することもできるため、より迅速にアクションを実行できます。
高レイテンシまたはエラーのあるトランザクション: Elastic Observability の APM 機能は、どのプロパティがトランザクションレイテンシの増加を引き起こしているのかを発見し、トランザクションの失敗と成功の区別に最も大きな影響を与えるプロパティを判断するのに役立ちます。
Log Spike Detector は、 OpenTelemetry ログレートの増加の原因を特定するのに役立ちます。分析ワークフロービューを使用すると、異常なスパイクの原因を簡単に見つけて調査できます。
ログパターン分析を使用すると、非構造化ログメッセージのパターンを見つけることができ、データの調査が容易になります。

Elastic を使用すると、計画的に OTel に移行できます

OpenTelemetry は複数のプログラミング言語をサポートしていますが、その主要な機能コンポーネント (メトリクス、トレース、ロギング) のステータスはまださまざまな段階にあります。したがって、Java、Python、JavaScript で書かれたアプリケーションを移行することは、メトリクス、トレース、ログ (Java の場合) が安定しているため、良い選択肢となります。

まだサポートされていない他の言語については、Elastic Agent を使用して簡単に検出でき、可観測性プラットフォームをハイブリッドモード (Elastic Agent と OpenTelemetry エージェント) で実行できます。

簡単な例を次に示します。

上の図は、標準の Elastic Agent アプリケーションの簡単なバリエーションを示しています。ここでは、1 つのサービスが OTel (ニュースレター-otel サービス) に切り替えられています。ただし、開発リソースが許せば、必要に応じてこれらのサービスを OTel に簡単に変換できます。

したがって、特定の言語が安定した状態に達したら、必要なものを Elastic を使用して OpenTelemetry に移行し、その後 OpenTelemetry エージェントへの移行を続けることができます。

Elastic に統合された Kubernetes ビューと OpenTelemetry ビュー

Elastic は、OpenTelemetry アプリケーションを実行している Kubernetes クラスターで使用できる Elastic Agent を使用して Kubernetes クラスターを管理します。したがって、アプリケーションで OpenTelemetry を使用できるだけでなく、Elastic は対応する Kubernetes クラスターを監視することもできます。

Kubernetes には 2 つの構成があります。

1) Elastic Agent デーモンセットを kubernetes クラスターにデプロイするだけです。これについては、「 Managing Kubernetes Clusters with Elastic Observability 」というタイトルの記事で概説しています。これにより、Kubernetes メトリクスとログのみが Elastic にプッシュされます。

2) Elastic Agent のデプロイには、Kubernetes デーモンセットが含まれるだけでなく、より包括的な Kubernetes クラスターの可観測性を提供するための Elastic の APM 統合、Defend (セキュリティ) 統合、およびネットワークパケットキャプチャ統合も含まれます。この構成については、記事「Elastic と OpenTelemetry を使用した Kubernetes の最新の可観測性とセキュリティ」で概説しています。

どちらの構成例も OpenTelemetry を使用して実証されており、Elastic では Kubernetes 情報をアプリケーションに結び付けているため、APM のトレースから Kubernetes 情報を表示できます。これにより、トラブルシューティングの際に、より統合されたアプローチが提供されます。

一般化する

Elastic の取り組みの中核は、OpenTelemetry のサポートだけにとどまりません。当社は、お客様が OpenTelemetry を採用するだけでなく、OpenTelemetry とともに成長できるようにすることに尽力しています。当社のソリューション、専門知識、リソースを通じて、あらゆる企業の可観測性への取り組みを強化し、データを成長とイノベーションを促進する実用的な洞察に変換することを目指しています。

翻訳：Elastic Observability でのネイティブ OpenTelemetry サポート | エラスティックブログ