を使用したログの解析は、大量のログ データから重要な情報を抽出するための貴重な手法です。この方法を採用すると、パターン、エラー、その他の重要な洞察を効果的に特定でき、最終的にログ分析を合理化し、システムのパフォーマンスを向上させることができます。 正規表現 前提条件 BindPlane OP および BindPlane エージェント (カスタム OpenTelemetry コレクター) カスタム解析が必要な複雑なログ ファイル 正規表現の知識 考えられるすべてのバリエーションに一致するログ サンプルの選択。  (オプション) regex101.com などの優れた正規表現テスト ツール ブログの例の regex101 へのリンクは次のとおりです:  https://regex101.com/r/6hhy6K/4 複雑なログ データのサンプル この投稿では、以下の例に似たログ エントリを調べます。スクリプトを利用してこれらのエントリを現在のタイムスタンプを持つファイルに書き込むことで、リアルタイム データを効果的に操作できます。   May 01 14:31:11 loggen-app10 test-system[712]: Mon May 01 14:31:11 UTC 2023|TEST_PROC|[result=Service Access Granted,service=https://portal.fakeuni.edu/uPortal/Login?...,requiredAttributes={}]|SERVICE_ACCESS_ENFORCEMENT_TRIGGERED|camillec1997|172.13.49.165|172.16.156.55 May 01 14:31:11 loggen-app10 test-system[712]: Mon May 01 14:31:11 UTC 2023|TEST_PROC|[result=Service Access Granted,service=https://portal.fakeuni.edu/uPortal/Login?...,requiredAttributes={}]|SERVICE_ACCESS_ENFORCEMENT_TRIGGERED|camillec1997|172.13.49.165|172.16.156.55 May 01 14:31:11 loggen-app10 test-system[712]: Mon May 01 14:31:11 UTC 2023|TEST_PROC|[event=success,timestamp=May 01 14:31:11 UTC 2023,source=RankedMultifactorAuthenticationProviderWebflowEventResolver]|AUTHENTICATION_EVENT_TRIGGERED|audit:unknown|172.25.178.6|172.16.156.55 May 01 14:31:11 loggen-app08 test-system[780]: Mon May 01 14:31:11 UTC 2023|TEST_PROC|Supplied credentials: [UsernamePasswordCredential(username=dawsonb, source=null, customFields={})]|AUTHENTICATION_SUCCESS|dawsonb|172.12.154.117|172.16.156.53 May 01 14:31:11 loggen-app10 test-system[712]: Mon May 01 14:31:11 UTC 2023|TEST_PROC|[event=success,timestamp=May 01 14:31:11 UTC 2023,source=RankedMultifactorAuthenticationProviderWebflowEventResolver]|AUTHENTICATION_EVENT_TRIGGERED|audit:unknown|172.25.178.6|172.16.156.55 データの分析 ここで、上記の最初のログ エントリを取得し、それを解析したいセクションに分割し始めることができます。 まず、2 つのタイムスタンプがあることがわかります。   **May 01 14:31:11** loggen-app10 test-system[712]: **Mon May 01 14:31:11 UTC 2023**|TEST_PROC|[result=Service Access Granted,service=https://portal.fakeuni.edu/uPortal/Login?...,requiredAttributes={}]|SERVICE_ACCESS_ENFORCEMENT_TRIGGERED|camillec1997|172.13.49.165|172.16.156.55  2 番目のタイムスタンプは、最高の精度を達成するために使用できるより多くの情報 (タイムゾーンと年は役立ちますが、曜日は実際には役に立ちません) が含まれているため、公式のタイムスタンプとして保存します。 これを詳しく見ると、最初のタイムスタンプと一致する非キャプチャ パターンを作成します。    。これに「   」が続き、3 文字の月の省略形を表します。月の後には「   」があり、スペースをキャプチャします。 2 桁の月の日を 0 で埋めたもの。そして別の空間。最後に、「   」があります。これは、2 桁の時、2 桁の分、2 桁の秒、および 1 つ以上のスペースを表します。 ^\w{3}\s\d{2}\s\d{2}:\d{2}:\d{2}\s+The caret “^” \w{3} \s\d{2}\s \d{2}:\d{2}:\d{2}\s+  2 番目のタイムスタンプには、名前付きキャプチャ グループが必要です。これは、解析されたフィールドの JSON BLOB 内の名前付きフィールドになります。   (?P<timestamp>\w{3}\s\w{3}\s\d{2}\s\d{2}:\d{2}:\d{2}\s\w{3}\s\d{4}) このキャプチャ グループに「タイムスタンプ」という名前を付けました。これには、他のタイムスタンプと同じ基本的な正規表現が含まれており、省略された曜日をキャプチャするために先頭に「   」と「   」は、3 文字のタイムゾーンと 4 桁の年を取得するために、末尾の「   」を置き換えます。  \w{3}\s \s\w{3}\s\d{4} \s+ ログ メッセージをさらに詳しく調べて、ホスト名とシステムを解析します。   May 01 14:31:11 **loggen-app10 test-system[712]**: Mon May 01 14:31:11 UTC 2023|TEST_PROC|[result=Service Access Granted,service=https://portal.fakeuni.edu/uPortal/Login?...,requiredAttributes={}]|SERVICE_ACCESS_ENFORCEMENT_TRIGGERED|camillec1997|172.13.49.165|172.16.156.55 このメッセージでは、ホスト名は  、システムは です。これらのログを受け取ったとき、[712] が何であるかについては知らされていませんでした。これは PID (プロセス ID) であると仮定しましたが、今のところ個別に解析しないことにしました。これらのフィールドの解析は非常に簡単で、最終的には「  になります。名前付きキャプチャ グループ、ホスト名、システムのペアがあります。 **loggen-app10** **test-system[712]** (?P<hostname>[^\s]+)\s+(?P<system>.*?):\s+ ホスト名のパターンは「   」です。これは、スペース以外の文字をキャプチャし、できるだけ多くの文字をキャプチャすることを意味します (貪欲に)。これに「   」が続きます。これは、少なくとも 1 つ、ただしできるだけ多くの (これも欲張りです) スペースをキャプチャします。 [^\s]+ \s+ システムのキャプチャ グループは、スペースの後、コロン文字までのすべてをキャプチャするため、さらに簡単になります。これを行うには、「  を使用します。 ”。このパターンが示しているのは、任意のキャラクターを 0 回以上キャプチャすることですが、欲張らないでください。 .*? その後に、コロン文字とさらに 1 つ以上のスペースが追加されます。これらはキャプチャされませんが、このセクションと上で書いたタイムスタンプ セクションの間に埋め込む必要があります。  これにより、次の開始パターンが得られます。   ^\w{3}\s*\d{2}\s*\d{2}:\d{2}:\d{2}\s+(?P<hostname>[^\s]+)\s+(?P<system>.*?):\s+(?P<timestamp>\w{3}\s\w{3}\s\d{2}\s\d{2}:\d{2}:\d{2}\s\w{3}\s\d{4}) パターン作成プロセス全体を実行するわけではありませんが、上記と同様にパターンを分割していきます。 結果の最終的なパターンは次のようになります。   ^\w{3}\s*\d{2}\s*\d{2}:\d{2}:\d{2}\s+(?P<hostname>[^\s]+)\s+(?P<system>.*?):\s+(?P<timestamp>\w{3}\s\w{3}\s\d{2}\s\d{2}:\d{2}:\d{2}\s\w{3}\s\d{4})\|(?P<app_name>\w*)\|((?P<message_type>.*?):\s+)?\[?(?P<message>.*)\]?\|(?P<event_message>.*?)\|(?P<username>.*?)\|(?P<external_ip>[\d\.:]*)\|(?P<internal_ip>[\d\.:]*) この最終パターンには、次の名前付きキャプチャ グループが含まれており、これらは解析されたデータの JSON BLOB のフィールドになります。 ホスト名 システム タイムスタンプ アプリ名 メッセージの種類 メッセージ イベントメッセージ ユーザー名 外部IP 内部 IP  正規表現の実装 BindPlane で File ソースを作成します。これは、/root/complex.log に生成されたログ ファイルを調べます。 [解析形式]で正規表現を選択しました。 Regex パターンの下に、上記の最終パターンを入力します。 [タイムスタンプの解析] チェックボックスをオンにし、形式として [手動] を選択し、タイムスタンプのパターンの時間解析コードを入力しました。   完了すると、次のようになります。 データの送信と検証 テストを完了するには、宛先を作成し、そこでデータを確認する必要があります。私のユースケースでは、Google Cloud Logging の宛先を選択しました。 パイプラインの構成が完了したら、それをエージェントに接続します。しばらく実行した後、エージェントのページで [最近のテレメトリを表示] ボタンをクリックします。    テレメトリ ビューには、次の解析されたログが表示されます。 最後に、   Cloud Logging コンソールでも確認します。  Google これは同じログ エントリを表示します。これには、最近のテレメトリ ビューからの本体の JSON マップ オブジェクトの JSON ペイロードが含まれています。 次のステップ 次のステップでは、そのメッセージ値の解析を見ていきたいと思います。多くの場合、これはキーと値のセットです。上記のスクリーンショットとサンプルにあるとおりです。これらのキー/値エントリを解析して JSON の別の層にするプロセッサにデータを渡すことができます。上記の例では、  それ自体に解析されて戻され、次のようなフィールドが存在する可能性があります。 body.message   body.message.result=Service Access Granted body.message.service=https://innosoftfusiongo.com/sso/logi… body.message.principal=SimplePrincipal(id=dawsonb, attributes={mail=[dawson.branden@fakeuni.edu], eduPersonAffiliation=[Staff], ou=[Recreation/Student Rec Center], givenName=[Dawson], cn=[Dawson Branden], title=[Asst. Director], employeeNumber=[5000000], o=[Vice ChancellorStudent Affairs], fakeuniOrg=[Vice ChancellorStudent Affairs], casMFARequired=[YES], uid=[dawsonb], eduPersonPrimaryAffiliation=[Staff], fakeuniCid=[5000000], fakeuniSeparationDate=[99991231000000Z], UDC_IDENTIFIER=[dawsonb], sn=[Branden], organizationalStatus=[Staff]}) body.message.requiredAttributes=”” これでも、 body.message.principle をキー/値パーサーに通すことでさらに解析できます。 ここで、「なぜ body.message サブフィールドの正規表現解析も使用しなかったのですか?」と疑問に思う人もいるでしょう。答え: あまりにも矛盾しています。すでにキーと値のペアを解析できる機能がある場合、正規表現は信じられないほど複雑になります。 結論 ログ ファイルにはさまざまな形式のデータが含まれています。多くの場合、このデータは人間が読みやすく、チェーンの後半で自動化やツールが操作しやすくするために解析する必要があります。 私が取り組んだ例は単純なファイル ログに対して実行されましたが、ここでの手法は任意のログ ストリームに対して使用できます。 BindPlane は、正規表現の解析に加えて、   、  、キーと値のペア、および文字区切りの値もサポートします。プロセッサを使用すると、これらのパーサーを連結して埋め込みデータを解析し、すべてを使用可能な形式に操作できます。 JSON XML   こちらでも公開しております。

Learn more and join the conversation. 

このオーディオは、ストーリーの元の言語で制作されています。

効率的なログ分析: BindPlane OP と OpenTelemetry による Regex の力の活用

About Author

コメント

ラベル

この記事は

Related Stories

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps