本記事はKhushboo Nigamによる”AI-Driven Log Analytics for Custom Applications in OCI“の日本語翻訳版記事です。


レガシーシステム、カスタム・アプリケーション、マルチクラウド・アーキテクチャなどを含む多くのエンタープライズ環境では、ログは構造化形式(CSVなど)または非構造化アプリケーション・ログファイル(.logなど)として、Oracle Cloud Infrastructure(OCI)Object Storageなどのクラウド・オブジェクトストアにエクスポートされます。このエクスポートは、スケジュールに基づいて実行することも、自動化されたデータ・パイプラインを通じて実行することもできます。Oracle Cloud Infrastructure Log Analyticsを使用すると、カスタムログソースとパーサーを使用して、外部ソースから取得したログを取り込み、解析および分析できます。この機能により、ログを最初の配信ポイントとしてObject Storageに直接出力するシステムにも、可観測性が拡張されます。

このブログでは、注文状況の詳細を示す構造化区切りログと、複数行のスタックトレースを含む非構造化アプリケーション・エラーログという2種類のログをLog Analyticsに取り込むサンプル・ユースケースを解説します。区切りログには区切りパーサーを作成し、アプリケーション・ログには複数行処理に対応した正規表現パーサーを作成して、データを正しく解釈します。ログを取り込んだ後、ClusterなどのMLベースの可視化ツールを用いて取り込んだログデータを分析する方法、LoganAIを用いて迅速なインサイトを得る方法、ウィジェットを作成する方法、エッジケースの検出ルールを設定する方法を紹介します。

以下のアーキテクチャ図は、オンプレミス、他のクラウド環境、またはOCI内で実行されているさまざまなアプリケーションからログを取り込む方法を示しています。アプリケーションはVMまたはコンテナ上で実行できます。このアプローチで、はログはまずOCI Object Storageに保存され、その後Log Analyticsで処理されます。

アーチ
Object Storage経由でログ分析にログを取り込むためのリファレンス・アーキテクチャ

 

ログの取り込み

Oracle Cloud Infrastructure (OCI) Log Analyticsは、ObjectCollectionRuleリソースを使用して、Object Storageのバケットからログ・データを継続的に収集できます。ルールタイプ(LIVE、HISTORIC、またはHISTORIC_LIVE)に応じて、OCIはObject Storageと連携してイベントおよびStreamingサービスを活用し、新しいオブジェクトを検出して処理します。

これを有効にするには、OCI REST APIまたはCLIを使用してObjectCollectionRuleを作成します。LIVEおよびHISTORIC_LIVEタイプのルールでは、リアルタイムのオブジェクト通知にストリーミングを使用するため、Stream OCIDが必要です。HISTORICルールの場合、Log Analyticsはストリーミングを使用せずに、Object Storageから既存のオブジェクトを直接取得します。

ルールが作成され、必要なIAMポリシーが設定されると、ログの取り込みが自動的に開始されます。この方法は、Object Storageに保存されているあらゆるタイプのログの取り込みをサポートします。Object Storageは追加をオブジェクトの上書き(新しいバージョン)として処理するため、ログを単一のファイルに継続的に追加するのではなく、定期的に新しいファイルとしてアップロードすることをお勧めします。

ObjectCollectionRuleの設定手順の詳細については、こちらをご覧ください。以下は、このデモで使用したサンプルのログ構造です。

オスバケット
サンプルのObject Storageログのアップロード

パーサーの作成

区切り型

まず、サンプル・ログデータの1行を調べてみましょう。

サンプル
サンプルの注文ログ

このログは、小売システムの一部であるバックエンドのアプリケーション・サービスを表しています。各ログ・エントリには、タイムスタンプ、サービス名、ログの重大度、実行されたアクションを説明するメッセージが含まれます。この例では、ログ・フィールドはパイプ文字(|)で区切られています。この区切り文字はパーサーの作成時に指定されます。

カスタム・パーサーを作成します。

  1. 「監視および管理」→「管理」→「パーサー」に移動します。
  2. 「パーサーの作成」をクリックします。
  3. フォームに次の情報を入力してください。
    • 区切り文字 (|)
    • サンプルログデータ
    • 各列に対応するフィールド名
    • (オプション)ログにヘッダー行が含まれている場合

以下のスクリーンショットは、サンプルのログ・データと選択した区切り文字を使用してパーサー構成を定義する方法を示しています。

カスタムパーサー-1
区切りパーサーの設定

 

カスタマーパーサー-2
パーサーにおけるフィールドマッピング

正規表現タイプ

一部のログ、特にアプリケーション・エラーログは、CSVのような明確な区切り構造に従っていません。代わりに自由形式のテキストで記述され、スタック・トレースが含まれている場合など、複数行にまたがることがよくあります。このような場合、OCI Log Analyticsの正規表現パーサーを使用すると、ログ形式に一致する正規表現を定義することで、キー・フィールドを抽出できます。

この例では、1行のINFOメッセージと複数行のERRORスタックトレースの両方を含むサンプルのアプリケーション・ログエントリを使用します。正規表現パーサーは、各ログエントリが正しく認識され、タイムスタンプ、レベル、サービス、メッセージなどの重要なフィールドが抽出されることを保証します。

アプリエラーログ
サンプルのアプリケーション・エラーログ

 

カスタム パーサーを作成するには:
1.「監視および管理」→「管理」→「パーサー」に移動します。

2.「パーサーの作成」をクリックします。

3.「パーサーを作成」をクリックし、パーサーの種類として「正規表現」を選択します。このパーサーは詳細モードで作成します。名前、説明、ログ内容の例を入力してください。

4. ログ行の構造に一致する正規表現パターンを貼り付けます。例えば、次の式はタイムスタンプ、ログレベル、サービス名、メッセージを解析します。

^{TIMEDATE}\s+([A-Z]+)\s+\[([^\]]+)\]\s+-\s+(?s)(.*)

5. スタックトレースやエラーメッセージが複数行にわたる場合は、エントリ開始式を各ログエントリの先頭行と一致するように設定してください。これにより、Log Analyticsは各ログエントリの先頭を認識し、後続のインデントされた行をそれに関連付けます。例:

^{TIMEDATE}

ログに対してパーサー式とエントリ開始式が正常に機能したら、それらによって解析されるフィールドを追加できるようになります。この例では、タイムスタンプ、リスクレベル、サービス名、メッセージを選択しました。+アイコンをクリックして、任意のフィールドを作成することもできます。

正規表現1
正規表現パーサーの設定

  6. パーサーテスト機能を使用して、サンプルのログ・ファイルで正規表現を検証します。フィールドが正しく抽出されていることを確認します。完了したら、「変更を保存」をクリックします。

テスト
パーサーのテスト

 

カスタム・ソースの作成

次のステップは、カスタム・ソースを作成することです。これにより、取り込み中にログをどのように処理および拡充するかを定義できます。

以下を実行します。

  1. 「監視および管理」→「管理」→「ソース」に移動します。
  2. 「ソースの作成」をクリックします。
  3. ログはObject Storageから取り込まれるため、エンティティ タイプには OCI Object Storageのバケットを選択します。
  4. 前の手順で作成したカスタム・パーサーをアタッチします。

この例では、構造化ログデータ用のRetailOrderAppLogsとアプリケーション・エラーログ用のRetailAppErrorLogsという2つのログ・ソースがあります。両方のログ・ソースは、それぞれのパーサーに関連付けられます。

このステップでは、コンテキスト・メタデータを追加してログを拡充させることもできます。例えば、RetailOrderAppLogsのログ・ソースでは、event_code が「FRAUD_SUSPECTED」であるログエントリに「Action Failed(アクション失敗)」というラベルを追加しました。このようなラベルを付けることで、ログの検索性が向上し、ダッシュボードやアラートで重要なイベントを特定しやすくなります。

ls
カスタム・ラベル付きログソース

注:区切りログ・ファイルにヘッダーがある場合は、ログソースにその情報を追加することが重要です。下の画像は「データ・フィルタ」セクションを示しています。このセクションでは、マスクまたは削除する必要があるログデータを定義するのに便利です。ここでヘッダーの詳細を定義することで、ログの取り込み時にヘッダーが削除され、ログ・エントリとして扱われないようにすることができます。

ヘッダ
ログ・ソースのヘッダー詳細を定義

 アプリケーション・エラーログのログ・ソースについては、パーサー・セクションで作成された正規表現パーサーを定義しました。

エラー
アプリケーションのエラーログ・ソース

ログ・エクスプローラで解析されたログ・データを表示

Log Analyticsに取り込まれたログは、ログ・エクスプローラで確認できます。下の画像は、小売注文アプリケーションのログです。

注文ログ
ログ・エクスプローラでのアプリケーションの注文ログ

ログが取り込まれ解析されると個々のログ・イベントを展開して、元の区切られたファイルから抽出された構造化データを検査できます。

各ログ・レコードには次のものが含まれます。

  • timestamp、service_name、event_code など、パイプ (|) 区切り文字を使用して解析されるフィールド
  • 以下のようなログ・ソースレベルで追加されたエンリッチメント・フィールド
    • ラベル(例:重大なイベントの場合は「アクション失敗」)
    • 重大度(例:INFO、WARN、ERROR)

この構造化されたビューにより、ログ全体でより強力な検索、フィルタリング、ダッシュボード機能が有効になります。

解析されたデータ
アプリケーションの注文ログ・データ

以下は正規表現パーサーを使用したアプリケーションのエラーログのビューです。

アプリエラー
ログ・エクスプローラでのアプリケーションのエラーログ

 

エラーログ
複数行のアプリケーションのエラーログ

 

ログ結果のフィルタリングと絞り込み

解析済みフィールドは、ログ検索結果をフィルタリングして絞り込むためにも使用できます。例えば、「フィールド」メニューから解析済みフィールド「イベントコード」を選択すると、order_placed、payment_successful、fraud_suspectedなど、ログに記録されている可能性のあるすべての値が表示されます。

これにより、ログ・パターンをすばやく調査できるようになり、正確なフィールド名や値を覚えていなくても、対象を絞ったクエリを構築できるようになります。

イベント
ログをフィルタリングするためのイベントコード

イベントコード = order_received が選択されると、ログはフィルタリングされます

注文受付
Caption

機械学習ベースのビジュアラゼーションを活用

機械学習ベースの可視化機能「クラスタ」を使用すると、ログ・イベントを意味のあるクラスタにグループ化して素早く表示できます。これは、ログメッセージ間の意味的類似性に基づいて行われるため、ログ内の正確な文言が異なっていても、繰り返し発生するパターン、異常、または外れ値を検出できます。

これは、事前定義されたクエリを必要とせずに隠れた傾向を明らかにするため、障害のデバッグや大量のログのスキャンを行うときに特に役立ちます。

クラスタ
MLベースのクラスタ・ビジュアライゼーション

 また、別のタブで潜在的な問題のログも強調表示されます。

円周率
クラスタで強調表示された潜在的な問題

これらのログに対して行われた顧客のクエリで作成されたウィジェットを組み合わせて、リアルタイムで更新される監視ダッシュボードを作成できます。

デシベル
注文ログのサンプル・ダッシュボード

 

LoganAIで分析

LoganAIは、Oracle Log Analyticsの人工知能(AI)機能です。LoganAIを使用すると、AIを活用してログから抽出されたデータを分析できます。LoganAIは、AIを活用したログ要約、実用的なフォローアップ質問、ユーザー・フレンドリーな説明などに活用できます。

次の前提条件を設定する必要があります。

LoganAIはログ・データの要約を作成できるので、大量のログ・データを確認する必要がある場合に役立ちます。また、ログのコンテキストをさらに絞り込むのに役立つ追加の質問も提案します。下の画像は、アプリケーション・エラーログに対してLoganAIを実行している様子です。LoganAIはこれらのログに表示されている内容を要約し、どのサービスで最も多くのエラーが発生しているかという追加の質問に答えます。

人工知能
LoganAI アプリケーション・エラーログの概要

チャットを再開すると、以下に示すように別の回答が表示されます。特定のログに関する詳細な説明を表示するには、フォロー・アップの質問のいずれかを選択してください。

ローガンAIサマリー
LoganaAI分析

 LoganAIを1つのログ・エントリのみに使用することで、特定のログの説明を表示することを選択できます。

1エントリ
単一ログ入力に関するLoganAI分析

検出ルールとアラームを使用したアラートの作成

ログに対して実行したカスタム検索は保存して、検出ルールを作成することもできます。このルールは定義された頻度で実行され、ログ・データ内の特定のパターンまたはイベントを探します。一致するログ・エントリが見つかると、メトリック・データポイントがOCI Monitoringサービスに送信されます。

これらのメトリックがMonitoringで利用できるようになると、以下が可能になります。

検出ルールを作成するには以下を実施します。

  • 「監視および管理」 → 「管理」 →「 検出ルール」に移動します。
  • 検出ルールの作成をクリックします。
  • 検索検出ルールを選択し、以下を入力します。
    • 名前
    • ログ検索クエリ
    • 頻度(どのくらいの頻度で実行されるか)
    • メトリック排出の目標詳細

以下のスクリーンショットは、保存済み検索に設定された検出ルールの例を示しています。このルールは、イベントコードが「fraud_suspected」であることを示します。このルールをアラームと組み合わせることで、該当する取引が検出された際にアラートを送信できます。

検出
疑わしい不正行為を検出するための検出ルール

 

結論

OCI Log Analyticsを拡張して構造化ログと非構造化ログの両方を処理できるようにすることで、標準的なシステム・ログだけでなく、アプリケーションのあらゆるレイヤーに可観測性をもたらします。カスタム・パーサー(注文状況などの構造化イベントには区切り文字、複雑な複数行のエラートレースには正規表現)を使用すると、生のログファイルを意味のあるクエリ可能なフィールドに変換できます。エンリッチメント・ルールとラベルを追加することでコンテキストがさらに強化され、検出ルールとアラームにより、重要なイベントに対して事後対応ではなくプロアクティブに対応できるようになります。

解析とアラート生成に加え、真の力を発揮するのは分析です。Clusterなどのフィルターや可視化機能を活用することで、複雑なクエリを作成することなく、繰り返し発生するパターンや異常を迅速に特定できます。LoganAIを使用すると、ログ調査がさらに迅速化され、問題を分かりやすい言葉で要約、相関分析、理解できます。これによりトラブル・シューティングにおける洞察を得るまでの時間が大幅に短縮されます。

エンタープライズ・システムがますます分散化、ハイブリッド化、複雑化する中で、構造化されたデータ取り込み、自動検出、AIを活用した分析を組み合わせることで、強靭かつインテリジェントな監視パイプラインを構築できます。OCI Log Analyticsは、多様なログタイプを統合する柔軟性、豊富な分析を可能にする深み、そして根本原因分析を加速するLoganAIのインテリジェンスを提供します。これらはすべて、現代のアプリケーション運用に不可欠な機能です。