• ログイン無料アカウント

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

英語版と齟齬がある場合、英語版の定めが優先するものとします。より詳しい情報については、本リンクをご参照ください。

問題を作成する

ログデータの解析

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

解析を開始するには、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 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ごとの応答コードの分布を理解し、問題のあるページをすばやく見つけるのに役立ちます。

ログ解析のしくみ

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分)をご覧ください。

ログタイプによる整理

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

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

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

重要

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

制限

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

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

制限

説明

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

ルールごとのメッセージごとの制限により、単一のメッセージの解析に費やされる時間が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"

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値に適用されます。

ヒント

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

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

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

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

Screenshot of Log parsing in UI

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

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

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

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

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

トラブルシューティング

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

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

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

Copyright © 2022 New Relic株式会社。