keyboard_double_arrow_up

Blog X-Tech5エンジニアがお送りするテックブログ
SREやDevOpsをはじめ、インフラエンジニアリングの実践情報を届けします。

New Relic : ログのパース方法

2023年11月7日 

New Relic のログのパース方法を公式ドキュメントを中心に整理します。

仕様

Parsing log data \| New Relic Documentation

What

パース対象のログを特定します。

When

パースルールの適用における仕様です。重要な事項が書かれています。

  • パースルールは各ログメッセージに 1回だけ 適用
    • 複数ルールに合致する場合、 最初に成功したルール が適用される
  • パースルールに順序は無い
    • 複数ルールに合致する場合、 ランダムで1つのルール が適用される
  • データがNRDBに取り込まれる前に適用される
    • 取り込み後(既存ログデータ)の解析は不可
  • データの強化(エンリッチメント)が行われる前にパイプラインで適用される
    • エンリッチメントで追加される属性によるパースルールでの合致は行えない

上から順に評価されると勘違いしそうですが、ルールに順序が無い点に注意です。
ルール作成時の順序の指定もありません。また、重複したルールでも特に警告などは出ません。

データの強化(エンリッチメント) は、ログ取り込み後に付与されている属性の付与を指しているのだと思います。
ログ送信時点で付与していない属性が該当します。
例: newrelic.logPattern、newrelic.source、pluging.type など

How

ルールは Grokパターン、または、正規表現で記述します。

Filterに合致するログが既に取り込み済みであれば、解析例として利用できます。

Filterに合致するログが存在しない場合は直接ログを貼り付けて利用します。

Grok とは

%{SYNTAX:SEMANTIC} が基本構文です。

なお、New Relic では 生成AIの機能として New Relic Grok がありますが、全くの別物です。

  • 参考URL
    • Grok の基本: Grok filter plugin \| Logstash Reference \[8\.10\] \| Elastic
    • チェッカー: https://grokdebugger.com/
    • パターン例: https://github.com/thekrakken/java-grok/tree/master/src/main/resources/patterns
      • ※ New Relic では上記 Grok Debugger でサポートしているパターンすべてをサポートしているわけではない

Grok パターン

%{PATTERN_NAME[:OPTIONAL_EXTRACTED_ATTRIBUTE_NAME[:OPTIONAL_TYPE]]}
  • PATTERN_NAME
    • サポートされている Grok パターン
  • OPTIONAL_EXTRACTED_ATTRIBUTE_NAME
    • ログメッセージに追加される属性名
    • 指定が無い場合、属性として抽出しない
  • OPTIONAL_TYPE
    • 属性値の型
    • 指定がない場合、文字列

正規表現の名前付きキャプチャも利用できます。以下2つは同一の意味を持ちます。
ただし、OPTIONAL_TYPE の指定ができないため名前付きキャプチャでの設定は文字列になると思われます。

# Grok pattern
^%{NOTSPACE:type}

# Named capturing group
^(?<type>\S+)

timestamp 属性

timestamp 属性は特別な意味を持ちます。

Logs インターフェースでの参照時の初期カラム、TIMESERIES での横軸になります。

Log event data \| New Relic Documentation

ログパース時に timestamp 属性を上書きする事が可能です。

例: ALB アクセスログ

AWS の ALB(Application Load Balancer) のアクセスログを NewRelic-log-ingestion-s3 で取り込んでいる場合の例です。

組み込み解析ルールでは、ログメッセージ内の日時は time 属性に設定し、timestamp 属性には New Relic への送信時間(取り込み時間)が設定されます。

カスタムログパースを利用して time 属性としている部分を timestamp 属性に置き換えます。

# 組み込み解析ルール logtype = 'alb'
^%{NOTSPACE:type} %{TIMESTAMP_ISO8601:time} %{NOTSPACE:elb}
# カスタム解析ルール
^%{NOTSPACE:type} %{TIMESTAMP_ISO8601:timestamp} %{NOTSPACE:elb}

この様にすることで、timestamp 属性へログメッセージ内の日時を設定できます。

特殊な Grok 型

CSV形式など特定のフォーマットであればパースする仕組みが型として用意されています。

Supported Grok Types

  • 複数行
    • (?s)%{GREEDYDATA:some_attribute}
  • JSON
    • JSON形式のログはデフォルトでパースされる
  • テキストと混合したJSON
    • %{GREEDYDATA:my_attribute_prefix:json}
  • CSV/TSV
    • %{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"]})}
  • 位置情報
    • %{GREEDYDATA:ip:geo({"lookup":["city","region","countryCode", "latitude","longitude"]})}

組み込み解析ルール

一般的なLogFormatに対するパースルールが事前定義されています。

Built\-in log parsing rules \| New Relic Documentation

これらは logtype 属性がマッチすると適用されます。

カスタムルールより前に判定されることに留意してください。
組み込み解析ルールの logtype で送信した場合、前述のWhenが働くため、エラーにならない限りカスタムルールは判定されません。
予約語の様な物と考えた方が良さそうです。

また、一般的な名称でカスタムルールを作成して運用している状態で、
新たに組み込み解析ルールが同名で追加された場合、組み込み解析ルールが優先されることになると思われます。

組み込み解析ルールの logtype は Web UI 上に表示されていないため、ドキュメント (Parsing log data \| New Relic Documentation) で確認する必要があります。

現時点で22種の logtype が定義されています。

logtype = ‘alb’
logtype = ‘apache’
logtype = ‘apache_error’
logtype = ‘cassandra’
logtype = ‘cloudfront-rtl’
logtype = ‘cloudfront-web’
logtype = ‘elb’
logtype = ‘haproxy_http’
logtype = ‘iis_w3c’
logtype = ‘ktranslate-health’
logtype = ‘linux_cron’
logtype = ‘linux_messages’
logtype = ‘mongodb’
logtype = ‘monit’
logtype = ‘mysql-error’
logtype = ‘nginx’
logtype = ‘nginx-error’
logtype = ‘postgresql’
logtype = ‘rabbitmq’
logtype = ‘redis’
logtype = ‘route-53’
logtype = ‘syslog-rfc5424’

制限

大量のログに対して複雑なパースを行う際にリソース制限によりパースできない場合があります。

  • メッセージ、ルール
    • 単一のメッセージに掛かる処理時間が 100 ミリ秒
  • アカウント
    • New Relic 全体でのアカウント共通制限があり、すべてのログメッセージに費やす1分間の処理時間合計が考慮される

パースエラーやリソース制限によるスキップが行われた場合など、ログのパースが失敗しても特にエラーメッセージ等は出力されません。
取り込まれたログがパースされたか否かでの判断になります。

まとめ

New Relic へ取り込んだログは logtype を指定することで組み込みルールによりパースされます。
組み込みルールに沿わないログフォーマットはカスタムルールを作成してパースします。

パースルールはログメッセージを解析し属性として値を抽出する機能であり、
複数の値から新たに値を生成したり、値を変換したりという様な処理はサポートされていません。

パースルールが適用されるのは 1 ログメッセージにつき1度きりです。
既に取り込み済みのログに対するパースは行えません。