ログ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 code
やrequest URL
などの属性に編成されます。
"remote_addr" : "93.180.71.3" ,
"path" : "/downloads/product_1" ,
"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}
などの式は機能しません。
Grokの例:ログから有用なデータを取得する ログレコードは次のようになります。
"message" : "54.3.120.2 2048 0"
この情報は正確ですが、それが何を意味するのかは直感的に分かりにくいです。Grokパターンは、必要なテレメトリーデータを抽出して理解するのに役立ちます。たとえば、次のようなログレコードははるかに使いやすくなります。
これを行うには、次の3つのフィールドを抽出するGrokパターンを作成します。
%{IP:host_ip} %{INT:bytes_received} %{INT:bytes_sent}
処理後、ログレコードにはフィールドhost_ip
、bytes_received
、 bytes_sent
が含まれます。これで、New Relicのこれらのフィールドを使用して、ログデータのフィルタリング、ファセット化、統計操作を実行できるようになります。New RelicでGrokパターンを使用してログを解析する方法の詳細については、ブログ記事 をご覧ください。
UIの例:Grok解析ルールの作成 適切な権限がある場合は、UIで解析ルールを作成し、Grok解析を作成、テスト、有効化できます。たとえば、Inventory Servicesと呼ばれるマイクロサービスの1つについて特定のタイプのエラーメッセージを取得するには、特定のエラーメッセージと製品を検索するGrok解析ルールを作成します。これを行うには、以下を実行します。
ルールに名前を付けます。たとえば、 Inventory Services error parsing
です。
解析する既存のフィールドを選択するか(デフォルト = message
)、新しいフィールド名を入力します。
受信ログの事前フィルターとして機能するNRQL WHERE
句を識別します(例:entity.name='Inventory Service'
)。この事前フィルターは、ルールで処理する必要があるログの数を絞り込み、不要な処理を削除します。
一致するログが存在する場合はそれを選択するか、[ログの貼り付け]タブをクリックしてサンプルログを貼り付けます。
Grok解析ルールを追加します。例:
Inventory error: %{DATA:error_message} for product %{INT:product_id}
対象箇所:
Inventory error
:解析ルールの名前error_message
:選択するエラーメッセージproduct_id
:Inventory Serviceの製品ID解析ルールを有効にして保存します。
すぐに、Inventory Serviceログに2つの新しいフィールドerror_message
とproduct_id
が追加されていることがわかります。ここから、これらのフィールドに対してクエリの実行、グラフやダッシュボードの作成、アラートの設定などが行えます。
詳細については、UIでカスタム解析ルールを追加するためのドキュメント を参照してください。
サポートされているGrokタイプ OPTIONAL_TYPE
フィールドは、抽出する属性値のタイプを指定します。省略すると、値は文字列として抽出されます。
サポートされているタイプは次のとおりです:
Grokで指定されたタイプ
New Relicデータベースに保存されているタイプ
boolean
boolean
byte
short
int
integer
integer
long
long
float
float
double
double
string
(デフォルト) text
string
date
datetime
Time as a long
デフォルトではISO 8601として解釈されます。OPTIONAL_PARAMETER
が存在する場合、 datetime
を解釈するために使用する日付と時刻のパターン文字列 を指定します。
これは解析中にのみ使用できることに注意してください。取り込みパイプラインの後半で、すべてのログに対して実行される、追加の個別タイムスタンプ解釈ステップ があります。
json
JSON構造化データ。詳細については、プレーンテキストと混在するJSONの解析 を参照してください。
csv
CSVデータ。詳細については、CSVの解析 を参照してください。
geo
IPアドレスからの地理的位置。詳細については、IPアドレスの位置情報の特定(GeoIP) を参照してください。
key value pairs
キーの値のペア。詳細については、キーの値ペアの解析 を参照してください。
Grokの複数行の解析 複数行のログがある場合は、GREEDYDATA
Grokパターンが改行と一致しないことに注意してください(.*
に相当します)。
したがって、%{GREEDYDATA:some_attribute}
を直接使用するのではなく、その前に複数行フラグを追加する必要があります。 (?s)%{GREEDYDATA:some_attribute}
プレーンテキストと混在するJSONの解析 New Relic LogsパイプラインはデフォルトでログのJSONメッセージを解析しますが、プレーンテキストと混在するJSONログメッセージが含まれる場合があります。このような状況では、それらを解析し、JSON属性を使用してフィルタリングできるようにする必要がある場合があります。その場合は、grokパターンによってキャプチャされたJSONを解析するjson
grokタイプ を使用できます。この形式は、grok構文、解析されたjson属性に割り当てるプレフィックス、およびjson
grokタイプ という3つの主要な部分に依存します。json
grokタイプ を使用すると、適切にフォーマットされていないログからJSONを抽出して解析できます。たとえば、ログの先頭に日付/時刻文字列が付いている場合などです。
2015 -05 -13T23 : 39 : 43 .945958Z { "event" : "TestRequest" , "status" : 200 , "response" : { "headers" : { "X-Custom" : "foo" } } , "request" : { "headers" : { "X-Custom" : "bar" } } }
このログ形式からJSONデータを抽出して解析するには、次のGrok式を作成します。
%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json}
結果のログは次のようになります。
containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.status: 200
my_attribute_prefix.response.headers.X-Custom: "foo"
my_attribute_prefix.request.headers.X-Custom: "bar"
オプションkeepAttributes
またはdropAttributes
を使用して、抽出または削除する属性のリストを定義できます。たとえば、次のGrok式の場合:
%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json({"keepAttributes": ["my_attribute_prefix.event", "my_attribute_prefix.response.headers.X-Custom"]})}
結果のログは次のようになります。
containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.request.headers.X-Custom: "bar"
my_attribute_prefix
プレフィックスを省略したい場合は、設定に"noPrefix": true
を含めることができます。
%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json({"noPrefix": true})}
my_attribute_prefix
プレフィックスを省略し、 status
属性のみを保持する場合は、設定に"noPrefix": true
と"keepAttributes: ["status"]
を含めることができます。
%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json({"noPrefix": true, "keepAttributes": ["status"]})}
JSONがエスケープされている場合は、isEscaped
オプションを使用して解析できます。JSONがエスケープされてから引用符で囲まれている場合は、以下に示すように引用符も一致させる必要があります。たとえば、次のGrok式の場合:
%{TIMESTAMP_ISO8601:containerTimestamp} "%{GREEDYDATA:my_attribute_prefix:json({"isEscaped": true})}"
エスケープされたメッセージを解析することができます。
2015-05-13T23:39:43.945958Z "{\"event\": \"TestRequest\", \"status\": 200, \"response\": {\"headers\": {\"X-Custom\": \"foo\"}}, \"request\": {\"headers\": {\"X-Custom\": \"bar\"}}}"
結果のログは次のようになります。
containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.status: 200
my_attribute_prefix.response.headers.X-Custom: "foo"
my_attribute_prefix.request.headers.X-Custom: "bar"
json
Grokタイプ を設定するには、 :json(_CONFIG_)
を使用します。
json({"dropOriginal": true})
:解析に使用されたJSONスニペットを削除します。true
(デフォルト値)に設定すると、解析ルールによって元のJSONスニペットが削除されます。JSON属性はメッセージフィールドに残ることに注意してください。json({"dropOriginal": false})
:抽出されたJSONペイロードが表示されます。false
に設定すると、完全なJSONのみのペイロードが上記のmy_attribute_prefix
で指定された属性の下に表示されます。ここでもJSON属性がメッセージフィールドに残り、ユーザーにJSONデータの3つの異なるビューが提供されることに注意してください。3つのバージョンすべてを保存する必要がある場合は、ここではデフォルトのtrue
を使用することをお勧めします。json({"depth": 62})
:JSON値を解析する深さのレベル(デフォルトは62)。json({"keepAttributes": ["attr1", "attr2", ..., "attrN"]})
:JSONから抽出される属性を指定します。指定されたリストは空にできません。この設定オプションが設定されていない場合は、すべての属性が抽出されます。json({"dropAttributes": ["attr1", "attr2", ..., "attrN"]})
:JSONから削除する属性を指定します。この設定オプションが設定されていない場合、属性は削除されません。json({"noPrefix": true})
:JSONから抽出された属性からプレフィックスを削除するには、このオプションをtrue
に設定します。json({"isEscaped": true})
:エスケープされたJSONを解析するには、このオプションをtrue
に設定します(これは通常、JSONが文字列化されたときに表示されます。たとえば、{\"key\": \"value\"}
)CSVの解析 システムがコンマ区切り値(CSV)ログを送信し、それをNew Relicで解析する必要がある場合は、GrokパターンによってキャプチャされたCSVを解析するcsv
Grokタイプ を使用できます。この形式は、Grok構文、解析されたCSV属性に割り当てるプレフィックス、およびcsv
Grokタイプ という3つの主要な部分に依存します。csv
Grokタイプ を使用すると、ログからCSVを抽出して解析できます。
例として次のCSVログ行を示します。
"2015-05-13T23:39:43.945958Z,202,POST,/shopcart/checkout,142,10"
そして、次の形の解析ルール:
%{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"]})}
ログは次のように解析されます:
log.timestamp: "2015-05-13T23:39:43.945958Z"
log.url: "/shopcart/checkout"
「ログ」プレフィックスを省略する必要がある場合は、設定に"noPrefix": true
を含めることができます。
%{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"], "noPrefix": true})}
列の設定: CSV Grokタイプ設定(有効なJSONである必要があります)で列を示すことが必須です。 列名として「_」(アンダースコア)を設定することで、結果のオブジェクトからその列を削除し、任意の列を無視できます。 オプション設定のオプション: 「列」の設定は必須ですが、次の設定でCSVの解析を変更することができます。
dropOriginal :(デフォルトはtrue
)解析に使用されるCSVスニペットを削除します。true
(デフォルト値)に設定すると、解析ルールによって元のフィールドが削除されます。noPrefix :(デフォルトはfalse
)結果のオブジェクトのプレフィックスとしてGrokフィールド名を含めません。separator :(デフォルトは,
)各列を分割する文字/文字列を定義します。もう1つの一般的なシナリオはタブ区切り値(TSV)です。この場合、区切り文字として\t
を指定する必要があります(例: %{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"], "separator": "\t"})
quoteChar :(デフォルトは"
)列の内容をオプションで囲む文字を定義します。IPアドレスの位置情報(GeoIP) システムがIPv4アドレスを含むログを送信する場合、 New Relicはそれらを地理的に特定し、指定された属性でログイベントを強化することができます。geo
Grokタイプ を使用すると、GrokパターンによってキャプチャされたIPアドレスの位置が検索されます。この形式は、IPの都市、国、緯度/経度など、住所に関連する1つ以上のフィールドを返すように設定できます。
次のログ行を例に挙げます。
2015-05-13T23:39:43.945958Z 146.190.212.184
そして、次の形の解析ルール:
%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:ip:geo({"lookup":["city","region","countryCode", "latitude","longitude"]})}
ログは次のように解析されます。
ip.countryName: United States
ip.regionName: New Jersey
containerTimestamp:2015-05-13T23:39:43.945958Z
Lookup設定: geo
アクションによって返される必要なlookup
フィールドを指定することが必須です。以下のオプションから少なくとも1つの項目が必要です。
city :都市名countryCode :国の略称countryName :国名latitude :緯度longitude :経度postalCode :郵便番号、ZIPコード、または類似の番号region :州、県、または地域の略語regionName :州、県、または地域の名前キーの値のペアを解析する New Relic Logsパイプラインはデフォルトでログメッセージを解析しますが、キーの値のペアとしてフォーマットされたログメッセージが存在する場合があります。この状況では、それらを解析して、キーと値の属性を使用してフィルタリングできるようにする必要がある場合があります。
その場合は、grokパターンによってキャプチャされたキーと値のペアを解析するkeyvalue
grokタイプ を使用できます。この形式は、grok構文、解析されたキーと値の属性に割り当てるプレフィックス、およびkeyvalue
grokタイプ という3つの主要な部分に依存します。keyvalue
grokタイプ を使用すると、適切にフォーマットされていないログからキーの値のペアを抽出して解析できます。たとえば、ログの先頭に日付/時刻文字列が付いている場合などです。
2015 -05 -13T23 : 39 : 43 .945958Z key1=value1 , key2=value2 , key3=value3
このログ形式からキーの値データを抽出して解析するには、次のGrok式を作成します。
%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:keyvalue()}
結果のログは次のようになります。
containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.key1: "value1"
my_attribute_prefix.key2: "value2"
my_attribute_prefix.key3: "value3"
カスタム区切り文字と区切り文字を定義して、必要なキーの値のペアを抽出することもできます。
2015 -05 -13T23 : 39 : 43 .945958Z event : TestRequest request : bar
たとえば、次のGrok式の場合:
%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:keyvalue({"delimiter": " ", "keyValueSeparator": ":"})}
結果のログは次のようになります。
containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.request: "bar"
my_attribute_prefix
プレフィックスを省略したい場合は、設定に"noPrefix": true
を含めることができます。
%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:keyValue({"noPrefix": true})}
結果のログは次のようになります。
containerTimestamp: "2015-05-13T23:39:43.945958Z"
カスタム引用符文字プレフィックスを設定する場合は、設定に「quoteChar」を含めることができます。
2015 -05 -13T23 : 39 : 43 .945958Z nbn_demo='INFO' , message='This message contains information with spaces , sessionId='abc123'
%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:keyValue({"quoteChar": "'"})}
結果のログは次のようになります。
"my_attribute_prefix.message": "'This message contains information with spaces",
"my_attribute_prefix.nbn_demo": "INFO",
"my_attribute_prefix.sessionId": "abc123"
Grokパターンの問題 ログ形式に合わせて、次のオプションを使用して解析動作をカスタマイズできます。
区切り文字
説明: 各キーの値のペアを区切る文字列。デフォルト値: ,
(カンマ)オーバーライド: この動作を変更するには、フィールドdelimiter
を設定します。keyValueSeparator
説明: キーに値を割り当てるために使用される文字列。デフォルト値: =
オーバーライド: カスタム区切り文字を使用するためにフィールドkeyValueSeparator
を設定します。quoteChar
説明: スペースまたは特殊文字を含む値を囲むために使用される文字。デフォルト値: "
(二重引用符)オーバーライド: quoteChar
を使用してカスタム文字を定義します。dropOriginal
説明: 解析後に元のログメッセージを削除します。ログの保存容量を削減するのに役立ちます。デフォルト値: true
オーバーライド: 元のログメッセージを保持するには、 dropOriginal
をfalse
に設定します。noPrefix
説明: true
の場合、結果のオブジェクトのプレフィックスとしてGrokフィールド名を除外します。デフォルト値: false
オーバーライド: noPrefix
をtrue
に設定して有効にします。escapeChar
説明: 特殊なログ文字を処理するためのカスタムエスケープ文字を定義します。デフォルト値: ""(バックスラッシュ)オーバーライド: escapeChar
でカスタマイズします。rimValues
説明: 空白を含む値をトリミングできます。デフォルト値: false
オーバーライド: トリミングを有効にするには、 trimValues
をtrue
に設定します。trimKeys
説明: 空白を含むキーをトリミングできます。デフォルト値: true
オーバーライド: トリミングを有効にするには、 trimKeys
をtrue
に設定します。ログタイプ別に整理 New Relicのログ取り込みパイプラインは、ログイベントをログの解析方法を記述したルールと照合することでデータを解析できます。ログイベントを解析するには2つの方法があります。
ルールは、一致ロジックと解析ロジックの組み合わせです。マッチングは、ログの属性にクエリマッチを定義することによって行われます。ルールは遡及的に適用されません。ルールが作成される前に収集されたログは、そのルールによって解析されません。
ログとその解析方法を整理する最も簡単な方法は、ログイベントにlogtype
フィールドを含めることです。これにより、ログに適用する組み込みルールがNew Relicに通知されます。
重要 解析ルールがアクティブになると、そのルールによって解析されたデータは永続的に変更されます。これを元に戻すことはできません。
制限 解析には計算コストがかかるため、リスクが生じます。解析は、アカウントで定義されたカスタムルールと、ログへのパターンの一致に対して実行されます。パターンの数が多い場合やカスタムルールの定義が不十分な場合は、大量のメモリとCPUリソースが消費され、完了するまでに非常に長い時間がかかります。
問題を防ぐために、メッセージごと、ルールごと、およびアカウントごとの2つの解析制限が適用されます。
LIMIT:
説明
メッセージごと、ルールごと
メッセージごと、ルールごとの制限により、単一のメッセージの解析にかかる時間が100ミリ秒を超えないようにします。その制限に達すると、システムはそのルールを使用してログメッセージを解析する試みを停止します。
取り込みパイプラインは、そのメッセージに対して他の適用可能な処理を実行しようとしますが、メッセージは取り込みパイプラインを通過し、NRDBに保存されます。ログメッセージは元の解析されていない形式になります。
アカウントごと
アカウントごとの制限は、アカウントが公平な割合を超えてリソースを使用することを防ぐために存在します。この制限では、アカウントの all のログメッセージの処理に費やされる1分あたりの合計時間が考慮されます。
ビルトイン解析ルール 一般的なログ形式には、確立された解析ルールがすでに作成されています。組み込みの解析ルールの利点を活用するには、ログを転送するときにlogtype
属性を追加します。次の表に記載されている値を設定すると、その種類のログのルールが自動的に適用されます。
組み込みルールのリスト 次のlogtype
属性値は、定義済みの解析ルールにマップされます。たとえば、アプリケーションロードバランサーを作成するには、次のようにします。
New Relic UIからは、logtype:"alb"
形式を使用します。 NerdGraph からは、logtype = 'alb'
形式を使用します。各ルールで解析されるフィールドについては、組み込みの解析ルール に関するドキュメントをご覧ください。
を追加する logtype
ログを集約するときは、ログの整理、検索、解析を容易にするメタデータを提供することが重要です。これを行う簡単な方法の1つは、出荷時にログメッセージに属性logtype
を追加することです。組み込みの解析ルール は、特定のlogtype
値にデフォルトで適用されます。
ヒント フィールドlogType
、 logtype
、 LOGTYPE
はすべて組み込みルールでサポートされています。検索を容易にするために、組織内で単一の構文に合わせることをお勧めします。
以下は、サポートされている配送方法 によって送信されたログにlogtype
を追加する方法の例です。
New Relic Infrastructureエージェントの例 attribute
としてlogtype
を追加します。名前付きソースごとにログタイプを設定する必要があります。
Fluentdの例 record_transformer
を使用して新しいフィールドを追加するフィルターブロックを、.conf
ファイルに追加します。この例では、組み込みのNGINX解析ルールをトリガーするために、nginx
のlogtype
を使用します。他のFluentdの例 を確認してください。
Fluent Bitの例 record_modifier
を使用して新しいフィールドを追加するフィルターブロックを、.conf
ファイルに追加します。この例では、組み込みのNGINX解析ルールをトリガーするために、nginx
のlogtype
を使用します。他のFluent Bitの例 を確認してください。
Record hostname ${HOSTNAME}
Record service_name Sample-App-Name
Logstashの例 add_field
mutateフィルターを使用して新しいフィールドを追加するフィルターブロックを、Logstash設定に追加します。この例では、組み込みのNGINX解析ルールをトリガーするために、nginx
のlogtype
を使用します。他のLogstashの例 を確認してください。
"service_name" = > "myservicename"
ログAPIの例 New Relicに送信されるJSONリクエストに属性を追加できます。この例では、組み込みのNGINX解析ルールをトリガーするために、値nginx
のlogtype
属性を追加します。ログAPI の使用について詳しくは、こちらをご覧ください。
Host: log-api.newrelic.com
Content-Type: application/json
X-License-Key: YOUR_LICENSE_KEY
"timestamp": TIMESTAMP_IN_UNIX_EPOCH,
"message": "User 'xyz' logged in",
"service": "login-service",
"hostname": "login.example.com"
カスタム解析ルールの作成と表示 多くのログは、独自の方法でフォーマットまたは構造化されています。これらを解析するには、カスタムロジックを構築して適用する必要があります。
ログUIの左側のナビゲーションからParsing を選択し、有効なNRQL WHERE
句とGrokパターンを使用して独自のカスタム解析ルールを作成します。
独自のカスタム解析ルールを作成および管理するには:
one.newrelic.com > All capabilities > Logs に移動します。ログUIの左側のナビゲーションのManage data から、 Parsing をクリックし、次にCreate parsing rule をクリックします。 新しい解析ルールの名前を入力します。 解析する既存のフィールドを選択するか(デフォルト = message
)、新しいフィールド名を入力します。 解析するログに一致する有効なNRQL WHERE
句を入力します。 一致するログが存在する場合はそれを選択するか、 Paste log タブをクリックしてサンプルログを貼り付けます。ログUIまたは書き込みビルダーからテキストをコピーして解析UIに貼り付ける場合は、それが Unformatted バージョンであることを確認してください。 解析ルールを入力し、 Output セクションの結果を表示してそれが機能していることを確認します。Grokとカスタム解析ルールの詳細については、Grokパターンを使用してログを解析する方法に関するブログ記事 をお読みください。 カスタム解析ルールを有効にして保存します。 既存の解析ルールを表示するには:
one.newrelic.com > All capabilities > Logs に移動します。ログUIの左側のナビゲーションにあるManage data から、 Parsing をクリックします。 トラブルシューティング 解析が意図したとおりに機能しない場合は、次の原因が考えられます。
Logic: 解析ルールの一致ロジックが、必要なログと一致しません。Timing: 解析一致ルールがまだ存在しない値である場合、失敗します。これは、エンリッチメントプロセスの一部として値がパイプラインの後半で追加された場合に発生する可能性があります。Limits: 解析、パターン、ドロップフィルターなどを使用してログを処理するために、1分ごとに一定の時間が利用できます。最大時間が経過した場合、追加のログイベントレコードの解析はスキップされます。これらの問題を解決するには、カスタム解析ルール を作成または調整します。