ログデータの解析

解析は、非構造化ログデータを属性（キーと値のペア）に分割するプロセスです。これらの属性を使用して、便利な方法でログをファセットまたはフィルタリングできます。これにより、より優れたチャートとアラートを作成できます。

解析を開始するには、YouTubeで次のビデオチュートリアルをご覧ください（約4分半）。

New Relicは、ルールに従ってログデータを解析します。このドキュメントでは、ログの解析のしくみ、組み込みのルールの使用方法、およびカスタムルールの作成方法について説明します。

api.newrelic.com/graphiqlにあるGraphQLAPIであるNerdGraphを使用して、ログ解析ルールを作成、クエリ、および管理することもできます。詳細については、解析に関するNerdGraphチュートリアルを参照してください。

構文解析の例

良い例は、非構造化テキストを含むデフォルトのNGINXアクセスログです。検索には便利ですが、それ以外はあまり役に立ちません。典型的な行の例を次に示します。

127.180.71.3 - - [10/May/1997:08:05:32 +0000] "GET /downloads/product_1 HTTP/1.1" 304 0 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.21)"

解析されていない形式では、ほとんどの質問に答えるために全文検索を行う必要があります。解析後、ログはresponse codeやrequest URLなどの属性に整理されます。

{
  "remote_addr":"93.180.71.3",
  "time":"1586514731",
  "method":"GET",
  "path":"/downloads/product_1",
  "version":"HTTP/1.1",
  "response":"304",
  "bytesSent": 0,
  "user_agent": "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.21)"
}

解析により、これらの値をファセットするカスタムクエリを簡単に作成できます。これは、リクエストURLごとの応答コードの分布を理解し、問題のあるページをすばやく見つけるのに役立ちます。

ログ解析のしくみ

NewRelicがログの解析を実装する方法の概要は次のとおりです。

ログの解析	使い方
何	すべての解析は`message`フィールドに対して行われます。他のフィールドは解析できません。各解析ルールは、ルールが解析を試みるログを決定する一致基準を使用して作成されます。照合プロセスを簡素化するために、ログに`logtype`属性を追加することをお勧めします。ただし、 `logtype`の使用に限定されません。任意の属性を一致基準として使用できます。
いつ	解析は、各ログメッセージに1回だけ適用されます。複数の解析ルールがログに一致する場合、成功した最初のルールのみが適用されます。解析は、データがNRDBに書き込まれる前に、ログの取り込み中に行われます。データがストレージに書き込まれると、それを解析することはできなくなります。解析は、データの強化が行われる前にパイプラインで行われます。解析ルールの一致基準を定義するときは注意してください。基準が、解析またはエンリッチメントが実行されるまで存在しない属性に基づいている場合、一致が発生したときにそのデータはログに存在しません。その結果、解析は行われません。
どのように	ルールは、 Grok 、正規表現、またはその2つの混合で記述できます。 Grokは、複雑な正規表現を抽象化するパターンのコレクションです。メッセージフィールドのコンテンツがJSONの場合、自動的に解析されます。

Grokを使用して属性を解析する

解析パターンは、ログメッセージを解析するための業界標準であるGrokを使用して指定されます。 logtypeフィールドの着信ログは、組み込みパターンと照合され、可能であれば、関連付けられたGrokパターンがログに適用されます。

Grokは正規表現のスーパーセットであり、リテラルの複雑な正規表現の代わりに使用される組み込みの名前付きパターンを追加します。たとえば、整数を正規表現(?:[+-]?(?:[0-9]+))と一致させることができることを覚えておく代わりに、 %{INT}と書くだけで、同じ正規表現を表すGrokパターンINTを使用できます。

一致する文字列では、いつでも正規表現とGrokパターン名を組み合わせて使用できます。詳細については、 Grok構文とサポートされているタイプのリストを参照してください。

Grok解析ルールパターンを作成するときにGrokデバッガーを使用する方法については、YouTubeビデオ（約6分）をご覧ください。

ログレコードは次のようになります。

{
  "message": "54.3.120.2 2048 0"
}

この情報は正確ですが、それが何を意味するのか正確には直感的ではありません。 Grokパターンは、必要なテレメトリデータを抽出して理解するのに役立ちます。たとえば、次のようなログレコードははるかに使いやすいです。

{
  "host_ip": "43.3.120.2",
  "bytes_received": 2048,
  "bytes_sent": 0
}

これを行うには、これら3つのフィールドを抽出するGrokパターンを作成します。例えば：

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

処理後、ログレコードにはフィールドhost_ip 、 bytes_received 、およびbytes_sentが含まれます。 New Relicでこれらのフィールドを使用して、ログデータのフィルタリング、ファセット、統計操作を実行できるようになりました。 New RelicでGrokパターンを使用してログを解析する方法の詳細については、ブログ投稿を参照してください。

適切な権限がある場合は、UIで解析ルールを作成して、Grok解析を作成、テスト、および有効にすることができます。たとえば、Inventory Servicesと呼ばれるマイクロサービスの1つについて特定の種類のエラーメッセージを取得するには、特定のエラーメッセージと製品を検索するGrok解析ルールを作成します。これをする：

ルールに名前を付けます。たとえば、 Inventory Services error parsing 。
受信ログのプレフィルターとして機能する属性/値のペアを特定します。たとえば、 entity.nameと値Inventory Service 。このプレフィルターは、ルールで処理する必要のあるログの数を絞り込み、不要な処理を削除します。
Grok解析ルールを追加します。例えば：
```
Inventory error: %{DATA:error_message} for product %{INT:product_id}
```
どこ：

Inventory error：解析ルールの名前
error_message：選択したいエラーメッセージ
product_id：在庫サービスの製品ID

Grokパターンをテストして、受信ログが一致するかどうかを確認します。
解析ルールを有効にして保存します。
すぐに、InventoryServiceログが2つの新しいフィールドerror_messageとproduct_idで強化されていることがわかります。ここから、これらのフィールドのクエリ、チャートやダッシュボードの作成、アラートの設定などを行うことができます。
詳細については、UIにカスタム解析ルールを追加するためのドキュメントを参照してください。

Grokパターンの構文は次のとおりです。

%{PATTERN_NAME[:OPTIONAL_EXTRACTED_ATTRIBUTE_NAME[:OPTIONAL_TYPE]]}

どこ：

PATTERN_NAME Grokパターンの1つです。 grok-patternsをクリックして、最も一般的に使用されるパターンを表示します。パターン名は、正規表現を表すわかりやすい名前です。これらは、対応する正規表現とまったく同じです。
OPTIONAL_EXTRACTED_ATTRIBUTE_NAME、指定されている場合は、パターン名と一致する値でログメッセージに追加される属性の名前です。これは、正規表現を使用して名前付きキャプチャグループを使用するのと同じです。これが指定されていない場合、解析ルールは文字列の領域に一致するだけで、その値で属性を抽出しません。

OPTIONAL_TYPE 抽出する属性値のタイプを指定します。省略した場合、値は文字列として抽出されます。たとえば、 "File Size: 123" }から値123を数値として属性file_sizeに抽出するには、 value: %{INT:file_size:int}を使用します。

サポートされているタイプは次のとおりです。

Grokで指定されたタイプ	NewRelicデータベースに保存されているタイプ
`boolean`	`boolean`
`byte` `short` `int` `integer`	`integer`
`long`	`long`
`float`	`float`
`double`	`double`
`string` （デフォルト） `text`	`string`
`date` `datetime`	ISO8601時間として `long`

ログタイプによる整理

New Relicのログ取り込みパイプラインは、ログイベントをログの解析方法を説明するルールと照合することでデータを解析できます。ログイベントを解析する方法は2つあります。

組み込みのルールを使用します。
カスタムルールを定義します。

ルールは、マッチングロジックと解析ロジックの組み合わせです。照合は、ログの属性に対してクエリ照合を定義することによって行われます。ルールはさかのぼって適用されません。ルールが作成される前に収集されたログは、そのルールによって解析されません。

ログとその解析方法を整理する最も簡単な方法は、ログイベントにlogtypeフィールドを含めることです。これにより、NewRelicにログに適用する組み込みルールが通知されます。

重要

解析ルールがアクティブになると、ルールによって解析されたデータは永続的に変更されます。これを元に戻すことはできません。

制限

解析は計算コストが高く、リスクが伴います。解析は、アカウントで定義されたカスタムルールと、パターンをログに一致させるために行われます。多数のパターンまたは不十分に定義されたカスタムルールは、完了するのに非常に長い時間がかかる一方で、大量のメモリとCPUリソースを消費します。

問題を防ぐために、ルールごととアカウントごとの2つの解析制限を適用します。

制限	説明
ルールごとのメッセージごと	ルールごとのメッセージごとの制限により、単一のメッセージの解析に費やされる時間が100ミリ秒を超えることはありません。その制限に達すると、システムはそのルールでログメッセージを解析しようとするのをやめます。取り込みパイプラインは、そのメッセージに該当する他のメッセージを実行しようとしますが、メッセージは引き続き取り込みパイプラインを通過してNRDBに保存されます。ログメッセージは、元の未解析の形式になります。
アカウントごと	アカウントごとの制限は、アカウントがリソースの公平なシェアを超えて使用することを防ぐために存在します。制限では、1分あたりのアカウントのすべてのログメッセージの処理に費やされた合計時間が考慮されます。制限は固定値ではありません。アカウントによって毎日保存されるデータの量と、その顧客をサポートするために後で割り当てられる環境サイズに比例してスケールアップまたはスケールダウンします。

制限

説明

ルールごとのメッセージごと

ルールごとのメッセージごとの制限により、単一のメッセージの解析に費やされる時間が100ミリ秒を超えることはありません。その制限に達すると、システムはそのルールでログメッセージを解析しようとするのをやめます。

取り込みパイプラインは、そのメッセージに該当する他のメッセージを実行しようとしますが、メッセージは引き続き取り込みパイプラインを通過してNRDBに保存されます。ログメッセージは、元の未解析の形式になります。

アカウントごと

アカウントごとの制限は、アカウントがリソースの公平なシェアを超えて使用することを防ぐために存在します。制限では、1分あたりのアカウントのすべてのログメッセージの処理に費やされた合計時間が考慮されます。

制限は固定値ではありません。アカウントによって毎日保存されるデータの量と、その顧客をサポートするために後で割り当てられる環境サイズに比例してスケールアップまたはスケールダウンします。

ヒント

レート制限に達しているかどうかを簡単に確認するには、NewRelicUIのシステム制限ページに移動します。

組み込みの解析ルール

一般的なログ形式には、確立された解析ルールがすでに作成されています。組み込みの解析ルールを利用するには、ログを転送するときにlogtype属性を追加します。次の表にリストされている値に値を設定すると、そのタイプのログのルールが自動的に適用されます。

組み込みルールのリスト

次のlogtype属性値は、事前定義された解析ルールにマップされます。たとえば、アプリケーションロードバランサーをクエリするには、次のようにします。

New Relic UIから、形式logtype:"alb"を使用します。
NerdGraphから、形式logtype = 'alb'を使用します。

各ルールで解析されるフィールドについては、組み込みの解析ルールに関するドキュメントを参照してください。

`logtype`	ログソース	マッチングクエリの例
`apache`	Apacheアクセスログ	`logtype:"apache"`
`alb`	アプリケーションロードバランサーのログ	`logtype:"alb"`
`cloudfront-web`	CloudFrontWebログ	`logtype:"cloudfront-web"`
`elb`	ElasticLoadBalancerログ	`logtype:"elb"`
`haproxy_http`	HAProxyログ	`logtype:"haproxy_http"`
`ktranslate-health`	KTranslateコンテナヘルスログ	`logtype:"ktranslate-health"`
`linux_cron`	LinuxCron	`logtype:"linux_cron"`
`linux_messages`	Linuxメッセージ	`logtype:"linux_messages"`
`iis_w3c`	MicrosoftIISサーバーログ-W3C形式	`logtype:"iis_w3c"`
`monit`	Monitログ	`logtype:"monit"`
`mysql-error`	MySQLエラーログ	`logtype:"mysql-error"`
`nginx`	NGINXアクセスログ	`logtype:"nginx"`
`nginx-error`	NGINXエラーログ	`logtype:"nginx-error"`
`route-53`	Route53ログ	`logtype:"route-53"`
`syslog-rfc5424`	RFC5424形式のSyslog	`logtype:"syslog-rfc5424"`

`logtype`属性を追加します

ログを集約するときは、それらのログの整理、検索、および解析を容易にするメタデータを提供することが重要です。これを行う簡単な方法の1つは、出荷時に属性logtypeをログメッセージに追加することです。組み込みの解析ルールは、デフォルトで特定のlogtype値に適用されます。

ヒント

フィールドlogType 、 logtype 、およびLOGTYPEはすべて、組み込みルールでサポートされています。検索を容易にするために、組織内の単一の構文に合わせるようにすることをお勧めします。

サポートされている配送方法のいくつかによって送信されたログにlogtypeを追加する方法の例を次に示します。

logtypeをattribute }として追加します。名前付きソースごとにログタイプを設定する必要があります。

logs:
  - name: file-simple
    file: /path/to/file
    attributes:
      logtype: fileRaw  
  - name: nginx-example
    file: /var/log/nginx.log
    attributes:
      logtype: nginx

フィルタブロックを.conf fileに追加します。これは、 record_transformerを使用して新しいフィールドを追加します。この例では、 nginxのlogtypeを使用して、組み込みのNGINX解析ルールをトリガーします。他のFluentdの例を確認してください。

<filter containers>
  @type record_transformer
  enable_ruby true
  <record>
    #Add logtype to trigger a built-in parsing rule for nginx access logs
    logtype nginx
    #Set timestamp from the value contained in the field "time"
    timestamp record["time"]
    #Add hostname and tag fields to all records
    hostname "#{Socket.gethostname}"
    tag ${tag}
  </record>
</filter>

record_modifierを使用して新しいフィールドを追加するフィルターブロックを.confファイルに追加します。この例では、 nginxのlogtypeを使用して、組み込みのNGINX解析ルールをトリガーします。他のFluentBitの例を確認してください。

[FILTER]
    Name record_modifier
    Match *
    Record logtype nginx
    Record hostname ${HOSTNAME}
    Record service_name Sample-App-Name

add_field変異フィルターを使用して新しいフィールドを追加するLogstash構成にフィルターブロックを追加します。この例では、 logtypeのnginxを使用して、組み込みのNGINX解析ルールをトリガーします。他のLogstashの例を確認してください。

filter {
  mutate {
    add_field => {
      "logtype" => "nginx"
      "service_name" => "myservicename"
      "hostname" => "%{host}"
    }
  }
}

NewRelicに送信されるJSONリクエストに属性を追加できます。この例では、値nginxのlogtype属性を追加して、組み込みのNGINX解析ルールをトリガーします。 LogsAPIの使用の詳細をご覧ください。

POST /log/v1 HTTP/1.1
Host: log-api.newrelic.com
Content-Type: application/json
X-License-Key: YOUR_LICENSE_KEY
Accept: */*
Content-Length: 133
{
  "timestamp": TIMESTAMP_IN_UNIX_EPOCH,
  "message": "User 'xyz' logged in",
  "logtype": "accesslogs",
  "service": "login-service",
  "hostname": "login.example.com"
}

カスタム解析ルールを作成して表示する

多くのログは、独自の方法でフォーマットまたは構造化されています。それらを解析するには、カスタムロジックを構築して適用する必要があります。

Logs UI の左のナビから Parsing を選択し、属性、値、Grok パターンで独自のカスタム解析ルールを作成します。

独自のカスタム解析ルールを作成および管理するには、次のようにします。

one.newrelic.com >Logsに移動します。
ログUIの左側のナビゲーションにある[データの管理]から、[解析]をクリックし、[解析ルールの作成]をクリックします。
解析ルールの名前を入力します。
一致させる属性と値を選択します。
Grokパターンを作成し、ルールをテストします。 Grokとカスタム解析ルールについては、Grokパターンを使用してログを解析する方法に関するブログ投稿をご覧ください。
カスタム解析ルールを有効にして保存します。

既存の解析ルールを表示するには：

one.newrelic.com >Logsに移動します。
ログUIの左側のナビゲーションにある[データの管理]から、[解析]をクリックします。

トラブルシューティング

解析が意図したとおりに機能しない場合は、次の原因が考えられます。

ロジック：解析ルールの一致ロジックが、必要なログと一致しません。
タイミング：解析一致ルールがまだ存在しない値を対象としている場合、失敗します。これは、濃縮プロセスの一部としてパイプラインの後半で値が追加された場合に発生する可能性があります。
制限：解析、パターン、ドロップフィルターなどを介してログを処理するために、毎分一定の時間があります。最大時間が費やされた場合、追加のログイベントレコードのために解析がスキップされます。

これらの問題を解決するには、カスタム解析ルールを作成または調整します。

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

構文解析の例

ログ解析のしくみ

Grokを使用して属性を解析する

Grokの例：ログから有用なデータを取得する

UIの例：Grok解析ルールの作成

Grok構文とサポートされているタイプ

ログタイプによる整理

重要

制限

ヒント

組み込みの解析ルール

組み込みルールのリスト

`logtype`属性を追加します

ヒント

NewRelicインフラストラクチャエージェントの例

流暢な例

流暢なビットの例

Logstashの例

LogsAPIの例

カスタム解析ルールを作成して表示する

トラブルシューティング

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

ログデータの解析

構文解析の例

ログ解析のしくみ

Grokを使用して属性を解析する

UIの例：Grok解析ルールの作成

Grok構文とサポートされているタイプ

ログタイプによる整理

重要

制限

ヒント

組み込みの解析ルール

組み込みルールのリスト

logtype属性を追加します

ヒント

NewRelicインフラストラクチャエージェントの例

流暢な例

流暢なビットの例

Logstashの例

LogsAPIの例

カスタム解析ルールを作成して表示する

トラブルシューティング

`logtype`属性を追加します