• EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は参考用に提供されます。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、 を参照してください。

問題を作成する

ログデータの解析

New Relic では、ログの解析とは、構造化されていないログ データから属性(キー:値のペア) を引き出すプロセスを指します。これらの属性を使用して、より実用的な方法でログを検索およびクエリできます。これにより、より優れたグラフとアラートを作成できます。

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

NerdGraph (GraphQL API) を使用して、ログ解析ルールを作成、クエリ、管理することもできます。これに役立つツールは、 Nerdgraph API Explorerです。詳細については、 解析に関する 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ごとの応答コードの分布を理解し、問題のあるページをすばやく見つけるのに役立ちます。

ログ解析のしくみ

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

ログの解析

使い方

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

いつ

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

どのように

  • ルールは、 Grok 、正規表現、またはその 2 つの組み合わせで記述できます。Grok は、複雑な正規表現を抽象化するパターンのコレクションです。

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

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

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

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

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

どこ:

  • PATTERN_NAME サポートされている Grok パターンの 1 つです。パターン名は、正規表現を表すわかりやすい名前です。それらは、対応する正規表現とまったく同じです。
  • OPTIONAL_EXTRACTED_ATTRIBUTE_NAME、指定されている場合は、パターン名と一致する値でログメッセージに追加される属性の名前です。これは、正規表現を使用して名前付きキャプチャグループを使用するのと同じです。これが指定されていない場合、解析ルールは文字列の領域に一致するだけで、その値で属性を抽出しません。
  • OPTIONAL_TYPE 抽出する属性値のタイプを指定します。省略した場合、値は文字列として抽出されます。たとえば、 "File Size: 123" }から値123を数値として属性file_sizeに抽出するには、 value: %{INT:file_size:int}を使用します。

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

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

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

ログタイプによる整理

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

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

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

重要

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

制限

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

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

制限

説明

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

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

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

アカウントごと

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

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

ヒント

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

組み込みの解析ルール

一般的なログ形式には、確立された解析ルールがすでに作成されています。組み込みの解析ルールを利用するには、ログを転送するときに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

カサンドラログ

logtype:"cassandra"

cloudfront-web

CloudFront (標準のウェブログ)

logtype:"cloudfront-web"

cloudfront-rtl

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

logtype:"cloudfront-rtl"

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"

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

Route53ログ

logtype:"route-53"

syslog-rfc5424

RFC5424形式のSyslog

logtype:"syslog-rfc5424"

logtype属性を追加します

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

ヒント

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

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

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

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

ログ 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. 一致するログが存在する場合はそれを選択するか、[ログの貼り付け] タブをクリックしてサンプル ログに貼り付けます。
  7. 解析ルールを入力し、[出力]セクションで結果を表示して、それが機能していることを検証します。Grok とカスタム解析ルールについて学習するには、Grok パターンを使用してログを解析する方法に関するブログ投稿をお読みください。
  8. カスタム解析ルールを有効にして保存します。

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

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

トラブルシューティング

解析が意図したとおりに機能しない場合は、次のことが原因である可能性があります。

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

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

まだお持ちでない場合は、以下で無料の New Relic アカウントを作成して、今すぐデータの監視を開始してください。

Copyright © 2024 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.