解析は、非構造化ログデータを属性(キーと値のペア)に分割するプロセスです。これらの属性を使用して、便利な方法でログをファセットまたはフィルタリングできます。これにより、より優れたチャートとアラートを作成できます。
解析を開始するには、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がログの解析を実装する方法の概要は次のとおりです。
ログの解析 | 使い方 |
---|---|
何 |
|
いつ |
|
どのように |
|
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'
を使用します。
各ルールで解析されるフィールドについては、組み込みの解析ルールに関するドキュメントを参照してください。
| ログソース | マッチングクエリの例 |
---|---|---|
Apacheアクセスログ |
| |
アプリケーションロードバランサーのログ |
| |
CloudFrontWebログ |
| |
ElasticLoadBalancerログ |
| |
HAProxyログ |
| |
KTranslateコンテナヘルスログ |
| |
LinuxCron |
| |
Linuxメッセージ |
| |
MicrosoftIISサーバーログ-W3C形式 |
| |
Monitログ |
| |
MySQLエラーログ |
| |
NGINXアクセスログ |
| |
NGINXエラーログ |
| |
Route53ログ |
| |
RFC5424形式のSyslog |
|
logtype
属性を追加します
ログを集約するときは、それらのログの整理、検索、および解析を容易にするメタデータを提供することが重要です。これを行う簡単な方法の1つは、出荷時に属性logtype
をログメッセージに追加することです。組み込みの解析ルールは、デフォルトで特定のlogtype
値に適用されます。
ヒント
フィールドlogType
、 logtype
、およびLOGTYPE
はすべて、組み込みルールでサポートされています。検索を容易にするために、組織内の単一の構文に合わせるようにすることをお勧めします。
サポートされている配送方法のいくつかによって送信されたログにlogtype
を追加する方法の例を次に示します。
カスタム解析ルールを作成して表示する
多くのログは、独自の方法でフォーマットまたは構造化されています。それらを解析するには、カスタムロジックを構築して適用する必要があります。
Logs UI の左のナビから Parsing を選択し、属性、値、Grok パターンで独自のカスタム解析ルールを作成します。
独自のカスタム解析ルールを作成および管理するには、次のようにします。
- one.newrelic.com >Logsに移動します。
- ログUIの左側のナビゲーションにある[データの管理]から、[解析]をクリックし、[解析ルールの作成]をクリックします。
- 解析ルールの名前を入力します。
- 一致させる属性と値を選択します。
- Grokパターンを作成し、ルールをテストします。 Grokとカスタム解析ルールについては、Grokパターンを使用してログを解析する方法に関するブログ投稿をご覧ください。
- カスタム解析ルールを有効にして保存します。
既存の解析ルールを表示するには:
- one.newrelic.com >Logsに移動します。
- ログUIの左側のナビゲーションにある[データの管理]から、[解析]をクリックします。
トラブルシューティング
解析が意図したとおりに機能しない場合は、次の原因が考えられます。
- ロジック:解析ルールの一致ロジックが、必要なログと一致しません。
- タイミング:解析一致ルールがまだ存在しない値を対象としている場合、失敗します。これは、濃縮プロセスの一部としてパイプラインの後半で値が追加された場合に発生する可能性があります。
- 制限:解析、パターン、ドロップフィルターなどを介してログを処理するために、毎分一定の時間があります。最大時間が費やされた場合、追加のログイベントレコードのために解析がスキップされます。
これらの問題を解決するには、カスタム解析ルールを作成または調整します。