OpenTelemetryログ：完全ガイド

リクエストのタイミングアウトやエラーメッセージがあちこちにあり、本番環境の動作が不安定になっている。 伝統的なロギング・ソリューションでは、根本的な原因を特定するのに-特に分散アプリケーションでは-通常、長くて手間のかかるプロセスを必要とします。OpenTelemetry のロギングは、トラブルシューティングとデバッグを容易にし、スピードアップすることで、この問題に対処します。

分散システムからすべてのログを一箇所で取得します。

無料で始める

OpenTelemetryロギングとは何か、OpenTelemetryログの収集方法、分散システムにおけるログ管理の課題に取り組むためにミドルウェアを活用する方法を理解するために、この先をお読みください。

OpenTelemetryとは？

OpenTelemetry はオープンソースでベンダーニュートラルな観測可能性フレームワークであり、最新のアプリケーションで遠隔測定データを取り込むための標準的で統一されたアプローチを提供します。 メトリックス、トレース、ログを含む遠隔測定データを収集するためのAPI、計測ライブラリ、SDK、統合のセットを提供します。

OpenTelemetryは、3つのコア・コンポーネント（計測、収集、エクスポート）を中心に構築・設計されています。 インスツルメンテーション・コンポーネントにより、テレメトリー収集のためのコードをアプリに追加することができます。

アプリがインスツルメンテーションされると、OpenTelemetry Collectorは実行時にスタック内の様々なソースからテレメトリーを収集し、更なる分析のために処理します。 そして、OpenTelemetry は、収集したテレメトリを、観測可能なプラットフォーム、ロギングシステム、モニタリングツールなどの様々なバックエンドにエクスポートします。

OpenTelemetry ログとは何ですか？

OpenTelemetry ログとは、イベントやアクティビティのタイムスタンプ付きテキスト記録とメタデータのことです。 イベントやスパンなど、OpenTelemetry の分散トレースやメトリックの一部ではないデータは、ログの一種であり、ログに添付されます。

ログは、エラー、警告、その他の重要なイベントなど、アプリの健全性に関する詳細な情報を提供します。 ログはデバッグを容易にし、アプリ改善のための情報に基づいた意思決定を可能にします。 OpenTelemetry を使えば、事前に設定された特定のログパターンやキーワードトリガーが検出されたときに通知するアラートシステムを統合することができます。

OpenTelemetry のログは、メトリクスやトレースとは異なるアプローチで収集されます。 メトリクスとトレースに対して、OpenTelemetryは新しいAPIと様々な言語での実装を提供します。

しかし、ログには豊かな収集と使用の歴史があります。一般的なプログラミング言語は、伝統的にロギング機能やライブラリをフレームワークに組み込んできました。 このように、OpenTelemetry は、既存のロギング・ライブラリをサポートし、同時に、それらの機能を改善し、それらの統合性の課題を抽象化します。

要するに、OpenTelemetryの “Logs Bridge API “を使えば、プログラミング言語に関係なく、既存のロギング・ライブラリをスタックに組み込んで、ログ・データを収集することができる。

さらに、OpenTelemetry は、ログをトレースやメトリクスに接続し、より簡単なトラブルシューティングのための豊富な遠隔測定を提供します。 また、ログを簡単に解釈できるように、コンテキストを提供するスパン・イベントも捕捉します。 OpenTelemetry のログとスパンを簡単に比較してみましょう。

ログの収集と監視を一箇所で – Middleware.

無料で始める

ログとスパンイベントの比較

ログは、アプリ内で発生した重要なイベント、エラー、警告、およびそれらの発生時間の記録です。 実行中のアプリの動作を包括的に記録し、リアルタイムのモニタリングを容易にします。

一方、Span イベントは、異なるコンポーネント間のタイミングや因果関係を含む、アプリ内の操作のコンテキストをキャプチャします。OpenTelemetry は、実行時間、実行コンテキスト、リソースコンテキストを経由して、ログを他の観測可能データと相関させます。

スパンIDは、LogRecordsに含まれている場合、同じ実行コンテキストに対応するトレースとログを関連付けるためのリソースを提供します。

スパンには通常、メタデータ、開始時刻、終了時刻、そのスパンに関連するログイベントの セットが含まれる。 このため、スパンは分散システムの様々なサービスからの個々のイベントのログを相関させるのに非常に価値がある。

なぜデータ相関が重要なのか？

データの相関関係が重要な理由はいくつかある。

簡単な根本原因分析

ログ、メトリクス、トレースを相関させることで、効果的な根本原因の分析が可能になります。 根本原因はもちろんのこと、相関データを使用することで、インシデントに至る一連の流れを簡単に特定・理解し、問題の原因となっているコンポーネントやサービスを正確に特定することができます。 これにより、問題の効率的な改善が促進され、問題が再発する可能性が低くなります。

パフォーマンスの最適化

相関するメトリクス、ログ、トレースを分析することで、ボトルネック、非効率性、またはリソース集約的なプロセスを特定できます。 この情報により、アプリのパフォーマンスを最適化し、構成を微調整し、リソースをより効果的に割り当てるためのデータ駆動型の意思決定を行うことができます。

ホリスティックな視点

アプリ、ホスト（VMやコンテナなど）、ホスト・コンポーネントなどの異なるソースからのデータを組み合わせることで、相関関係により、さまざまなコンポーネント、サービス、インフラストラクチャ間の相互依存関係を理解することができます。

また、リクエストのエンドツーエンドのフローを洞察し、インシデント発生時のシステム全体の影響を理解し、さまざまなコンポーネントのメトリクスとログの関係を可視化します。

OpenTelemetryのログ・データ・モデル

これは、アプリケーションログファイル、機械が生成したイベント、システムログなど、様々なソースからログを表現することを可能にするモデルと意味規約である。

OpenTelemetryのログ・データ・モデルは、以下の目標を達成しようとしている：

• ログの状態を統一する-ログ記録とは何か、どのようなデータが記録され、転送され、保存され、ロギングシステムによって解釈される必要があるのか。

• 従来のログフォーマットをこのデータモデルに簡単にマッピングする。

• このデータ・モデルとの間で、異種データ・フォーマットの容易な変換を可能にする。

• このデータモデルとの間で変換されるログフォーマットが、意味的に意味のあるものであることを保証する。

• データの保存や送信を必要とする具体的な実装において、データモデルを効率的に表現できるようにする。

• ファーストパーティアプリ、システムフォーマット（Syslogなど）、サードパーティアプリ（Apacheログファイルなど）の3つのコアタイプのログを表現する。

OTelが収集するログの種類

OpenTelemetry Logs Data Modelが表現する3つのタイプのログとイベントを簡単に見てみよう。

• システムフォーマット：OSが生成するログです。 変更可能なアプリによって生成されたものでない限り、一般的にそのフォーマットをコントロールすることは限られている。
• サードパーティアプリケーションのログ：サードパーティアプリが生成するログです。 形式をカスタマイズできる場合もあるが、通常、制御できる範囲は限られている。
• ファーストパーティアプリケーションログ：アプリが生成するログです。 どのように生成され、どのような情報が含まれるかをよりコントロールできる。 また、アプリのソースコードを変更して変更することもできます。

ログ記録

ログレコードはアプリイベントの詳細を提供し、2種類のフィールドを含む。 フィールドについては後述する。

名前付きトップレベル・フィールド

これらは特定の型と意味を持つフィールドである。 これらは、レガシーと今後のログ書式の両方において、必須または定期的に出現するフィールドを含む（例えば、それぞれタイムスタンプとTraceIds）。 トップレベルフィールドのセマンティクスは、すべての既知のログフォーマットとイベントフォーマットで同一でなければならない。 また、OpenTelemetryログのデータモデルに簡単かつ明確に変換できなければならない。

リソースと属性フィールド

任意のキーと値のペアとも呼ばれるこれらのフィールドは、「マップ」として保存され、ログ表現の柔軟性を提供します。 これらのフィールドは、標準化された、あるいは、任意の意味的規約を使用して、ログメッセージのカスタムフィールドと値を定義することを可能にします。 それらは、ユーザーID、リクエストID、エラーコードのような、アプリケーションのニーズに特化した情報を捕捉します。

各フィールドは以下の表で説明されている。

これらのフィールドは通常、典型的なログレコードでは以下のように表現される。

OpenTelemetry ログレコード：例

これは、ログデータモデルに従ったJSON形式のOTel’s Logレコードのようなものです。

 "Timestamp" : "1634630600000",
  "ObservedTimestamp" : "1634630601000",
  "TraceId" : "xyz7890",
  "SpanId" : "ijkl4321",
  "SeverityText" : "INFO",
  "SeverityNumber" : "6",
  "Body" : "A successful request has been processed.",
  "Resource" : {
    "service.name" : "web-backend",
    "host.name" : "web-server-2"
  },
  "InstrumentationScope": {
    "Name" : "JavaLogger",
    "Version": "1.0.0"
  },
  "Attributes" : {
    "http.method": "POST",
    "http.status_code": "200"
  }

では、どうやってこのデータを集めるのか？

ログデータの収集方法

システム、ファーストパーティアプリ、サードパーティアプリのいずれを計測する場合でも、OpenTelemetryはデータ収集に2つのアプローチを提供します。 以下、それらについて説明します。

ファイルまたは標準出力ログ経由

これは、ログを中間媒体（ファイルや標準出力など）に書き込む方法である。 この方法の重要な利点は、アプリケーションがログを生成する方法や、ログを書き込む場所を変更する必要性を最小限に抑えられることです。

このアプローチでは、ログローテーションが使用されている場合であっても、 ファイルログを読み込み、それを正しく処理する能力が必要である。 また、オプションとして、ログを解析し、様々な種類のパーサーを使用して、より構造化されたフォーマットに変換する能力を必要とすることもある。

これを行うために、OpenTelemetry は、Collectorまたは（それができない場合）他のログ収集エージェント（例えば、FluentBit）を使用することを推奨します。 パーサーは、CSV、Common Log Format、LTSV、Key/Value Pair format、JSONのような、カスタムログ形式や一般的なログ形式を扱うように設定することができます。

中間媒体を使うことの重要な欠点は、ファイルの読み込みと解析が必要なことで、これは難しく、時間がかかり、出力フォーマットの定義が不十分な場合は信頼性に欠けることがある。

直接コレクターへ

このアプローチは、OTLPのようなネットワークプロトコルを介してログを出力するようにアプリケーションを修正することを含む。 これは、よく使われるロギングライブラリのアドオンや拡張機能を提供することで、簡単に実現できます。 アドオンは、選択したネットワークプロトコルでログを送信します。 これには、アプリのコードに最小限のローカライズされた変更を加える必要があります。

ログが収集されると、コレクターは、サードパーティアプリの場合と同様に、リソースコンテキストでログをエンリッチする。 このエンリッチメントにより、ログがすべてのコンテキスト次元にわたって包括的な相関情報を持つことが保証される。

このアプローチの利点は、ファイルログの送信に関連する複雑さ（解析、テーリング、ローテーションなど）を減らし、構造化されたフォーマットでログを送信し、ログ収集エージェントなしでログをロギングバックエンドに直接送信できることです。

しかし、この方法にも欠点がないわけではない。 それは、ローカルのログファイルを削除し、ローカルのログ読み取りを方程式から単純化することです。 ロギングバックエンドは、OTLPやその他のOpenTelemetryと互換性のあるネットワークプロトコルからログを受信できなければなりません。

上述のアプローチを容易にするために、OpenTelemetryはブリッジAPIとSDKを提供しています。 これらのツールは、既存のロギングライブラリと一緒に使用することで、自動的にトレースコンテキストをログに含めることができ、OTLP経由でログを送信するプロセスを簡素化します。 ログアペンダーはAPIを利用して、既存のライブラリからOpenTelemetryのデータモデルにログをブリッジし、SDKはログの適切な処理とエクスポートを保証します。

上の図は、レガシーなファーストパーティアプリケーションのログ、サードパーティアプリケーションのログ、そしてシステムログにおいて、2つのアプローチがどのように機能するかを示しています。 下図は、新しいファーストパーティーのアプリケーションが、OpenTelemetry API、SDK、そして既存のログ・ライブラリをどのように使うかを示しています。

ログはOTLP経由でOpenTelemetry Collectorに送られる。 OpenTelemetry CollectorのログはOTel Logs Data Modelに従っているようで、プロセスが容易になる。

OpenTelemetryデータモデルのアーキテクチャを説明したところで、なぜ、そしてどのようにOpenTelemetryが既存のロギング・ソリューションを改善するのかを考えてみましょう。

既存のロギング・ソリューションの限界

既存のロギング・ソリューションは、レガシー・アプリのモニタリングとトラブルシューティングを容易にしてきた。 しかし、以下のような制限があるため、最新のアプリには不適切です。

テレメトリー量

いくつかのロギングソリューションは、最新のアプリケーションによって生成される大量のログを処理するのに苦労しています。 それらはしばしば圧倒され、性能の問題やログ処理の遅れにつながり、観測可能性プロセスを妨げるかもしれません。

統合

レガシーなロギングソリューションは、適切な統合を欠いているか、最新のシステムとシームレスに動作するための追加設定を必要とします。 特定のログイベントまたはパターンを見つけ、複雑なクエリ、フィルタリング、およびログ相関を実装することは、従来のロギングソリューションでは困難な場合があります。 多くの場合、追加のツール（統合するのが難しいかもしれない）または手作業が必要です。

データ保管

これらのロギング・ソリューションでは、保存できるデータ量や保持期間に制限があります。 このため、過去のログデータが失われることが多く、アプリのイベントや動作の傾向を長期にわたって分析することが難しくなります。

標準化

ロギングフレームワーク、ライブラリ、アプリは、様々なマイクロサービスからのログを処理しようとするDevOpsチームにとって問題となり得る多様なログフォーマットを使用する可能性がある。

同様に、標準化されていないということは、レガシーソリューションが出力するログフォーマットが、望ましい観測可能性ソリューションと互換性がない可能性があることを意味する。 多くの場合、分析前にログを変換し、正規化するための追加的な労力が必要になる。

OpenTelemetryは、そのログ・データ・モデルとベンダーにとらわれないバックエンドのサポートによって、これらの制限を克服する手助けをします。 この方法で、OpenTelemetry は、ログの収集、標準化、相関を処理し、容易にし、一方で、選択したバックエンドは、ログの解釈を確実にします。

スケーラビリティ、ストレージ機能、ログフォーマットのサポート、検索および分析機能、リアルタイムのモニタリング機能、および他のモニタリングシステムとの統合に基づいて、ロギングソリューションを選択することが重要です。

良いニュースは、我々の観測可能性フレームワーク、ミドルウェアが、レガシーのロギング・ソリューションの限界に取り組みながら、これらを提供することだ。 このプラットフォームは、OpenTelemetry とその遠隔測定データモデルとシームレスに動作し、他のロギング・ソリューションとは一線を画す多くの特徴を持っています。

• ミドルウェアは、メトリックス、ログ、トレースを1つの統一されたプラットフォームに統合し、関連付けることで、根本原因の分析とアプリケーションの状態に対するエンドツーエンドの可視化を実現します。

• 大規模なデータインジェストを処理し、リアルタイムでログを処理できるスケーラブルなインフラ上に構築されている。

• 強力なログ処理機能を提供し、ログデータに対して高度な分析、フィルタリング、検索クエリを実行できます。

• ミドルウェアは、特定のログイベントが発生したときにアラートをトリガーする閾値、パターン、または特定の条件を定義するインテリジェントなアラートを設定することができます。 これにより、プロアクティブな通知が保証され、アラートによる疲労が軽減され、迅速な問題解決が促進されます。

ミドルウェア：OpenTelemetryベースのフルスタック観測可能プラットフォーム

ミドルウェアは、OTelから収集されたテレメトリを分析するために構築された包括的な観測可能性プラットフォームです。 アプリケーションをエンドツーエンドで可視化するためのログ監視画面を提供します。

• ミドルウェアを始めるには、アカウントを作成してください。
• ログインすると、Middleware Unified Observabilityダッシュボードが表示されます。 このダッシュボードでは、システムの健全性、パフォーマンス、主要メトリクスをハイレベルで概観できます。

• 下の画面は Middleware が OpenTelemetry を含む多くのフレームワークとシームレスに統合していることを示しています。 画面上の OTel アイコンはメトリクスとログです。

• ミドルウェアには、画面左側のアイコンにあるログ監視専用のセクションがあり、ログデータを一元的かつ直感的に閲覧・分析することができる。

• 過去ログのアイコンをクリックすると、以下の画面が表示されます。

このセクションには、ログフィルターオプションがあり、タイムスタンプ、ログレベル、キーワード、またはカスタム属性などの特定の条件に基づいてログメッセージをフィルターすることができます。 左上には、ログレベルがあります。 各「レベル」のボックスをチェックすると、Middlewareは選択されたレベルのメッセージを表示します。

• 個々のメッセージをクリックすると、さらにログを分析することができます。 最初のログメッセージをクリックすると、以下の画面が表示されます。

この画面では、本文、タイムスタンプ、重大度などの必須フィールドとその値を含むログレコードが表示されます。

• フィールドの上にある「ソースログ」をクリックすると、イベントの詳細なタイムスタンプを含む、より詳細な分析が表示されます。 このセクションでは、特定のログのストリーム、ソース、または属性に焦点を当てることができ、特定のログのコンテキストを理解し、効果的にトラブルシューティングを行うことができます。

• 最後に、ホーム画面で “ダッシュボードを見る “から “統合ダッシュボード “に移動すると、ログ、メトリクス、トレースが1つのページで相関して表示されます。 この統一されたページでは、ログのパターン、傾向、異常をインタラクティブなチャートやグラフで視覚化することもできます。

さらに、このプラットフォームでは、インテリジェントなログベースのアラートを設定することができ、特定のログイベントが発生すると、Slackや Microsoft Teamsなどのさまざまなチャネルを介して送信されます。 ログメッセージパターン、ログレベル、または特定の属性に基づいてアラートルールを構成することができます。

OpenTelemetry計装アプリケーションにミドルウェアのパワフルなログの可視化と分析機能を活用することで、問題をプロアクティブに特定し解決することができ、結果としてソフトウェアの品質とユーザー・エクスペリエンスを向上させることができます。

よくあるご質問

ログは、アプリの要件や好みに応じて、コレクターに直接送信されるファイルまたは標準出力ログを介して収集することができます。 どちらのオプションにも長所と短所があります。

ログが個別のイベントやメッセージをキャプチャするのに対し、イベントはアプリの異なるコンポーネント間のタイミングや因果関係など、操作のコンテキストをキャプチャする。

テレメトリーは、ログ、メトリクス、トレースを包含する広義の用語であり、ログは特に、アプリの状態と実行を表すキャプチャされたメッセージやイベントを指す。