New RelicでGrokパターンを使ったLog解析による構造化の方法

英語で火星人に由来する言葉はGrokだけかもしれません。Grokは、ロバート・A・ハインラインが1961年に発表したSF小説『異星の客』に登場します。しかし、この記事では、ログメッセージを解析するための業界標準としてのGrokに焦点を当て、それがNew Relicでどのように機能するかを説明します。

その前に、一般的にGrok解析がどのように機能するかについて少し説明します。

どのようなプラットフォームにおいても、ログの遠隔測定から最大限の価値を引き出すためには、ロギングバックエンドに送られる、構造化されていないメッセージを解析する能力が必要です。

以下のログと

以下のログの違いについて考えてみましょう。

3つの独立したフィールドを持つエンティティは、フリーテキストの塊よりも観察可能性の面で大きなメリットがあり、Grokではこの種の絞り込みを比較的容易に行うことができます。

Grokパターン %{SYNTAX:SEMANTIC} を定義することで、ログメッセージ内の特定のデータを検索することができます。

SYNTAXは、テキストにマッチするパターンの名前です。SYNTAXログに入る可能性のあるパターンには、NUMBER、INT、IPなど、非常によく使われるものがあります。NUMBERパターンは、4.55、4、8、その他のあらゆる数字にマッチします。IPパターンは、54.3.120.2や174.49.99.1などにマッチします。 SEMANTICは、マッチしたテキストに与えられる識別子です。パターンがあなたのテキストにマッチした場合、識別子を持つフィールドがログレコードに作成されます。

つまり、"[IP address] [Bytes Received] [Bytes Sent]"という形式のログメッセージ（例えば："54.3.120.2 2048 0"）があった場合、以下のGrokパターンを使ってその形式にマッチさせ、3つの有用なフィールドを抽出することができます。

"%{IP:host_ip} %{INT:bytes_received} %{INT:bytes_sent}"

処理後のログレコードには、host_ip、bytes_received、bytes_sentの3つの新しいフィールドが追加されます。  これらのフィールドを オブザーバビリティプラットフォーム で使用することで、ログデータのフィルタリング、ファセット化、統計処理を行うことができます。

New RelicにおけるGrok解析の動作について

構文解析は、ログパイプラインのフォワーディング層またはバックエンドのいずれかで適用されます。New Relic はバックエンド解析を使用し、特定の指定されたログタイプに対する組み込み解析を提供していますが、解析 UI で任意の解析ルールを作成することもできます。

ビルトインの解析ルールもカスタムルールも、Grok パターンを使って、フリーテキストの文字列から有用な情報を抽出する方法を指定します。解析によって、バリューフィールドの統計分析、ファセット検索、フィルタなどの高度な機能を使用することができます。もし、データを分類して別々のフィールドに分けることができなければ、ワイルドカードや正規表現を使った煩雑な全文検索に頼ることになり、定量的な価値は低くなってしまいます。

New RelicにおけるビルトインGrokパターン

logtypeフィールドを持つすべての受信ログは、そのlogtypeに関連するビルトインパターンのリストと照合されます。  可能な場合、次の例で示すように、関連する内蔵のGrokパターンがそのログに適用されます。

ビルトイン解析に関するドキュメントはこちらをご参照ください。

New RelicでGrokのカスタムパターンを作成する

権限を持っていれば、Manage Parsing UIを使ってNew RelicでGrokパターンを作成、テスト、有効化することができます。

例えば、"Inventory Service "という名前のマイクロサービスがあるとします。  このサービスは、有用な情報を含む自由で構造化されていないテキストを含む特定のエラーログを出力します。

例えば次のような：

繰り返しになりますが、これは有用な情報です。しかし、もっと構造を持ったものにしたいものです。

フリーテキストのクエリを使ってUIでそのようなログを探すことはできますが、複雑で計算コストのかかる正規表現を使わずにNRQLでこのようなクエリを使うのは難しいでしょう。

その代わりに、必要な情報を抽出するための解析ルールを作成することができます。

Manage parsing > Create New Parsing Rule をクリックし、以下の手順を実行します。

1. ルールに、"InventoryService Error Parsing "のような便利な名前を付けます。
2. プレフィルターとして機能する属性/値のペアを入力します。これにより、このルールで処理する必要のあるログが絞り込まれ、不要な処理が削除されます。  ここでは、属性として "entity.name"、値として "Inventory Service "を選択します。
3. Grokの解析ルールを追加します。この場合、次のようになります。

4. Test Grokをクリックすると、Grokルールがシステムに入ってくるログのどれかにマッチするかどうかが表示されます。
5. ルールを有効にし、Save parsing rule をクリックします。

すぐに、システムに入ってくるInventory Serviceのログに、error_messageとproduct_idという2つの新しいフィールドが追加され、強化されていることがわかります。

これで、これらのフィールドを使ったクエリを使用して、データエクスプローラーにビジュアライゼーションを作成することができます。

Grokパターンを開発するためのツールとリソース

Grok Debuggerは、Grokパターンを実験するための非常に便利なUIです。これは、New Relic で使用できる本番用の Grok パターンを作成するための IDE のようなものだと考えてください。

次のようにサンプルのログの内容と、マッチさせたいパターンを入力します。

パターンがサンプルの内容と一致すれば、抽出されたフィールドが表示されます。

構文に関しては、解析ルールを作成する際に頻繁に使用する必要がある、より便利なGrokパターンのサブセットをご紹介します。

Grok Debuggerには、Grokパターンとその基礎となる正規表現の定義のより詳細なリストがあります。

まとめ

お客様のログのメッセージフィールドに、有用で人間が読める情報が含まれており、何らかの明白な構造を持っている場合、Grok の解析でそのデータを正規化することをご検討ください。そうすることで、ログがファーストクラスのエンティティになり、APM やインフラストラクチャ・モニタリング・エージェントからの他のイベントと同じように、NRQL でクエリしたり、ダッシュボードやアラートで使用したりすることができます。