ログデータの解析

ログparsingは、定義したルールに基づいて、非構造化ログデータを属性(キーと値のペア)に変換するプロセスです。これらの属性をNRQLクエリで使用すると、ログを便利な方法でファセット化またはフィルタリングできます。

New Relicは、特定の解析ルールに従ってログデータを自動解析します。このドキュメントでは、ログ解析の仕組みと、独自のカスタム解析ルールを作成する方法について説明します。

また、GraphQL APIであるNerdGraphを使用して、ログ解析ルールを作成、クエリ、管理することもできます。このために役立つツールは、Nerdgraph APIエクスプローラーです。詳細については、解析に関するNerdGraphチュートリアルを参照してください。

ログ解析に関する5分間のビデオはこちらです:

解析例

良い例としては、構造化されていないテキストを含むデフォルトの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 coderequest 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ごとの応答コードの分布を理解し、問題のあるページをすばやく見つけることができます。

ログ解析の仕組み

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

ログ解析

使用方法

対象

  • 解析は特定の選択されたフィールドに適用されます。デフォルトでは、messageフィールドが使用されます。ただし、現在データに存在しないフィールド/属性も含め、任意のフィールド/属性を選択できます。
  • 各解析ルールは、ルールが解析を試みるログを決定するNRQL WHERE句を使用して作成されます。
  • 一致プロセスを簡素化するために、ログにlogtype属性を追加することをお勧めします。ただし、logtypeの使用に限定されるわけではなく、1つ以上の属性をNRQL WHERE句の一致基準として使用できます。

タイミング

  • 解析は各ログメッセージに1回だけ適用されます。複数の解析ルールがログに一致する場合、最初に成功したルールのみが適用されます。
  • 解析ルールは順序付けられていません。複数の解析ルールがログに一致する場合、ランダムに1つが選択されます。同じログと一致しないように解析ルールを構築してください。
  • 解析は、データがNRDBに書き込まれる前に、ログの取り込み中に行われます。データがストレージに書き込まれると、解析できなくなります。
  • パイプラインで解析が行われ、 beforeデータの強化が行われます。解析ルールの一致基準を定義するときは注意してください。条件が解析またはエンリッチメントが行われるまで存在しない属性に基づいている場合、一致が発生したときにそのデータはログに存在しません。その結果、解析は行われません。

方法

  • ルールはGrok、正規表現、またはその2つを組み合わせて記述できます。Grokは、複雑な正規表現を抽象化するパターンのコレクションです。
  • 解析UIではJava Regex構文をサポートしています。キャプチャグループ内の属性名またはフィールド名の場合、Java Regexでは[A-Za-z0-9]のみが許可されます。

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

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

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

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

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

対象箇所:

  • PATTERN_NAME は、サポートされているGrokパターンの1 つです。パターン名は、正規表現を表すユーザーフレンドリな名前です。これらは対応する正規表現とまったく同じです。
  • OPTIONAL_EXTRACTED_ATTRIBUTE_NAMEを指定した場合、パターン名と一致する値とともにログメッセージに追加される属性の名前です。これは、正規表現を使用して名前付きキャプチャグループを使用するのと同じです。これが指定されていない場合、解析ルールは文字列の領域のみを照合し、属性とその値を抽出しません。
  • OPTIONAL_TYPE は、抽出する属性値のタイプを指定します。省略すると、値は文字列として抽出されます。インスタンスの場合、値123 "File Size: 123"から数値として属性file_sizeに抽出するには、 value: %{INT:file_size:int}を使用します。
  • OPTIONAL_PARAMETER は、特定のタイプに対してオプションのパラメーターを指定します。現在、パラメーターを受け取るのはdatetime型のみです。詳細については、以下を参照してください。

一致する文字列では、正規表現とGrokパターン名を組み合わせて使用することもできます。

サポートされているGrokパターンのリストについてはこのリンクを、サポートされているGrokタイプのリストについてはこちらをクリックしてください。

変数名は明示的に設定する必要があり、%{URI:uri}のように小文字にする必要があることに注意してください。%{URI}%{URI:URI}などの式は機能しません。

ログタイプ別に整理

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

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

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

重要

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

制限

解析には計算コストがかかるため、リスクが生じます。解析は、アカウントで定義されたカスタムルールと、ログへのパターンの一致に対して実行されます。パターンの数が多い場合やカスタムルールの定義が不十分な場合は、大量のメモリとCPUリソースが消費され、完了するまでに非常に長い時間がかかります。

問題を防ぐために、メッセージごと、ルールごと、およびアカウントごとの2つの解析制限が適用されます。

LIMIT:

説明

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

メッセージごと、ルールごとの制限により、単一のメッセージの解析にかかる時間が100ミリ秒を超えないようにします。その制限に達すると、システムはそのルールを使用してログメッセージを解析する試みを停止します。

取り込みパイプラインは、そのメッセージに対して他の適用可能な処理を実行しようとしますが、メッセージは取り込みパイプラインを通過し、NRDBに保存されます。ログメッセージは元の解析されていない形式になります。

アカウントごと

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

ヒント

レート制限に達したかどうかを簡単に確認するには、New Relic UIのシステムLimitsページに移動します。

ビルトイン解析ルール

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

組み込みルールのリスト

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

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

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

logtype

ログソース

一致するクエリの例

apache

Apacheアクセスログ

logtype:"apache"

apache_error

Apacheエラーログ

logtype:"apache_error"

alb

アプリケーションロードバランサーログ

logtype:"alb"

cassandra

Cassandraログ

logtype:"cassandra"

cloudfront-web

CloudFront(標準ウェブログ)

logtype:"cloudfront-web"

cloudfront-rtl

CloudFront(リアルタイムウェブログ)

logtype:"cloudfront-rtl"

elb

Elastic Load Balancerログ

logtype:"elb"

haproxy_http

HAProxyログ

logtype:"haproxy_http"

ktranslate-health

KTranslateコンテナの健全性ログ

logtype:"ktranslate-health"

linux_cron

Linux cron

logtype:"linux_cron"

linux_messages

Linuxメッセージ

logtype:"linux_messages"

iis_w3c

Microsoft IISサーバーログ - W3C形式

logtype:"iis_w3c"

mongodb

MongoDBログ

logtype:"mongodb"

monit

Monitログ

logtype:"monit"

mysql-error

MySQLエラーログ

logtype:"mysql-error"

nginx

NGINXアクセスログ

logtype:"nginx"

nginx-error

NGINXエラーログ

logtype:"nginx-error"

postgresql

PostgreSQLログ

logtype:"postgresql"

rabbitmq

Rabbitmqログ

logtype:"rabbitmq"

redis

Redisログ

logtype:"redis"

route-53

Route 53ログ

logtype:"route-53"

syslog-rfc5424

RFC5424形式のSyslog

logtype:"syslog-rfc5424"

を追加する logtype

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

ヒント

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

以下は、サポートされている配送方法によって送信されたログにlogtypeを追加する方法の例です。

カスタム解析ルールの作成と表示

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

Screenshot of log parsing in UI

ログUIの左側のナビゲーションからParsingを選択し、有効なNRQL WHERE句とGrokパターンを使用して独自のカスタム解析ルールを作成します。

独自のカスタム解析ルールを作成および管理するには:

  1. one.newrelic.com > All capabilities > Logsに移動します。
  2. ログUIの左側のナビゲーションのManage dataから、 Parsingをクリックし、次にCreate parsing ruleをクリックします。
  3. 新しい解析ルールの名前を入力します。
  4. 解析する既存のフィールドを選択するか(デフォルト = message)、新しいフィールド名を入力します。
  5. 解析するログに一致する有効なNRQL WHERE句を入力します。
  6. 一致するログが存在する場合はそれを選択するか、 Paste logタブをクリックしてサンプルログを貼り付けます。ログUIまたは書き込みビルダーからテキストをコピーして解析UIに貼り付ける場合は、それが Unformatted バージョンであることを確認してください。
  7. 解析ルールを入力し、 Outputセクションの結果を表示してそれが機能していることを確認します。Grokとカスタム解析ルールの詳細については、Grokパターンを使用してログを解析する方法に関するブログ記事をお読みください。
  8. カスタム解析ルールを有効にして保存します。

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

  1. one.newrelic.com > All capabilities > Logsに移動します。
  2. ログUIの左側のナビゲーションにあるManage dataから、 Parsingをクリックします。

トラブルシューティング

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

  • Logic: 解析ルールの一致ロジックが、必要なログと一致しません。
  • Timing: 解析一致ルールがまだ存在しない値である場合、失敗します。これは、エンリッチメントプロセスの一部として値がパイプラインの後半で追加された場合に発生する可能性があります。
  • Limits: 解析、パターン、ドロップフィルターなどを使用してログを処理するために、1分ごとに一定の時間が利用できます。最大時間が経過した場合、追加のログイベントレコードの解析はスキップされます。

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