ログデータの解析

ログレコードは次のようになります。

{
  "message": "54.3.120.2 2048 0"
}

この情報は正確ですが、それが何を意味するのか正確には直感的ではありません。 Grokパターンは、必要なテレメトリデータを抽出して理解するのに役立ちます。たとえば、次のようなログレコードははるかに使いやすいです。

{
  "host_ip": "43.3.120.2",
  "bytes_received": 2048,
  "bytes_sent": 0
}

これを行うには、これら3つのフィールドを抽出するGrokパターンを作成します。例えば：

%{IP:host_ip} %{INT:bytes_received} %{INT:bytes_sent}

処理後、ログレコードにはフィールドhost_ip 、 bytes_received 、およびbytes_sentが含まれます。 New Relicでこれらのフィールドを使用して、ログデータのフィルタリング、ファセット、統計操作を実行できるようになりました。 New RelicでGrokパターンを使用してログを解析する方法の詳細については、ブログ投稿を参照してください。

適切な権限がある場合は、UIで解析ルールを作成して、Grok解析を作成、テスト、および有効にすることができます。たとえば、Inventory Servicesと呼ばれるマイクロサービスの1つについて特定の種類のエラーメッセージを取得するには、特定のエラーメッセージと製品を検索するGrok解析ルールを作成します。これをする：

1. ルールに名前を付けます。たとえば、 Inventory Services error parsing 。

2. 解析する既存のフィールドを選択するか (デフォルト = message )、新しいフィールド名を入力します。

3. 着信ログのプレフィルターとして機能する NRQL WHERE句を特定します。たとえば、 entity.name='Inventory Service'です。このプレフィルターは、ルールで処理する必要があるログの数を絞り込み、不要な処理を削除します。

4. 一致するログが存在する場合はそれを選択するか、[ログの貼り付け] タブをクリックしてサンプル ログに貼り付けます。

5. Grok解析ルールを追加します。例えば：

   Inventory error: %{DATA:error_message} for product %{INT:product_id}

   コピー

   どこ：

• Inventory error：解析ルールの名前
• error_message：選択したいエラーメッセージ
• product_id：在庫サービスの製品ID

6. 解析ルールを有効にして保存します。

   すぐに、InventoryServiceログが2つの新しいフィールドerror_messageとproduct_idで強化されていることがわかります。ここから、これらのフィールドのクエリ、チャートやダッシュボードの作成、アラートの設定などを行うことができます。

   詳細については、UI でカスタム解析ルールを追加するためのドキュメントを参照してください。

OPTIONAL_TYPEフィールドは、抽出する属性値のタイプを指定します。省略した場合、値は文字列として抽出されます。

サポートされているタイプは次のとおりです。

複数行のログがある場合は、 GREEDYDATA Grok パターンが改行と一致しないことに注意してください (これは .*と同等です)。

したがって、 %{GREEDYDATA:some_attribute} を直接使用する代わりに、その前に複数行のフラグを追加する必要があります。 (?s)%{GREEDYDATA:some_attribute}

New Relic ログ パイプラインは、デフォルトでログ JSON メッセージを解析しますが、JSON ログ メッセージがプレーン テキストと混在している場合があります。この状況では、それらを解析して、JSON 属性を使用してフィルタリングできるようにする必要がある場合があります。その場合は、 json grok typeを使用できます。これは、grok パターンによってキャプチャされた JSON を解析します。この形式は、grok 構文、解析された json 属性に割り当てるプレフィックス、 json grok タイプの 3 つの主要部分に依存しています。json grok typeを使用すると、適切にフォーマットされていないログから 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を使用して、抽出する属性のリストを定義できます。たとえば、次の 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})}

:json(_CONFIG_)を使用してjson Grok タイプを構成することもできます。

• 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({"noPrefix": true}): JSON から抽出された属性からプレフィックスを削除するには、このオプションを true に設定します。

システムがコンマ区切り値 (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.status: "202"
log.method: "POST"
log.url: "/shopcart/checkout"
log.time: "142"
log.bytes: "10"

「ログ」プレフィックスを省略する必要がある場合は、構成に"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 : (デフォルトは" ) 必要に応じて列の内容を囲む文字を定義します。

システムが IPv4 アドレスを含むログを送信する場合、New Relic はそれらを地理的に特定し、指定された属性でログ イベントを充実させることができます。 geo Grok タイプを使用できます。これは、Grok パターンによってキャプチャされた IP アドレスの位置を見つけます。この形式は、住所に関連する 1 つ以上のフィールド (都市、国、IP の緯度/経度など) を返すように構成できます。

例として次のログ行があるとします。

2015-05-13T23:39:43.945958Z 146.190.212.184

そして、次の形の解析規則:

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:ip:geo({"lookup":["city","region","countryCode", "latitude","longitude"]})}

ログは次のように解析されます。

ip: 146.190.212.184
ip.city: North Bergen
ip.countryCode: US
ip.countryName: United States
ip.latitude: 40.793
ip.longitude: -74.0247
ip.postalCode: 07047
ip.region: NJ
ip.regionName: New Jersey
containerTimestamp:2015-05-13T23:39:43.945958Z
ISO8601_TIMEZONE:Z

ルックアップ構成:

geo アクションによって返される目的の lookup フィールドを指定することは必須です。次のオプションから少なくとも 1 つのアイテムが必要です。

• city: 都市名
• countryCode: 国の略称
• countryName: 国名
• latitude: 緯度
• longitude: 経度
• postalCode: 郵便番号、郵便番号など
• region: 州、州、または地域の略語
• regionName: 州、県、または地域の名前

logtypeをattribute }として追加します。名前付きソースごとにログタイプを設定する必要があります。

logs:
  - name: file-simple
    file: /path/to/file
    attributes:
      logtype: fileRaw
  - name: nginx-example
    file: /var/log/nginx.log
    attributes:
      logtype: nginx

フィルタブロックを.conf fileに追加します。これは、 record_transformerを使用して新しいフィールドを追加します。この例では、 nginxのlogtypeを使用して、組み込みのNGINX解析ルールをトリガーします。他のFluentdの例を確認してください。

<filter containers>
  @type record_transformer
  enable_ruby true
  <record>
    #Add logtype to trigger a built-in parsing rule for nginx access logs
    logtype nginx
    #Set timestamp from the value contained in the field "time"
    timestamp record["time"]
    #Add hostname and tag fields to all records
    hostname "#{Socket.gethostname}"
    tag ${tag}
  </record>
</filter>

record_modifierを使用して新しいフィールドを追加するフィルターブロックを.confファイルに追加します。この例では、 nginxのlogtypeを使用して、組み込みのNGINX解析ルールをトリガーします。他のFluentBitの例を確認してください。

[FILTER]
    Name record_modifier
    Match *
    Record logtype nginx
    Record hostname ${HOSTNAME}
    Record service_name Sample-App-Name

add_field変異フィルターを使用して新しいフィールドを追加するLogstash構成にフィルターブロックを追加します。この例では、 logtypeのnginxを使用して、組み込みのNGINX解析ルールをトリガーします。他のLogstashの例を確認してください。

filter {
  mutate {
    add_field => {
      "logtype" => "nginx"
      "service_name" => "myservicename"
      "hostname" => "%{host}"
    }
  }
}

NewRelicに送信されるJSONリクエストに属性を追加できます。この例では、値nginxのlogtype属性を追加して、組み込みのNGINX解析ルールをトリガーします。 LogsAPIの使用の詳細をご覧ください。

POST /log/v1 HTTP/1.1
Host: log-api.newrelic.com
Content-Type: application/json
X-License-Key: YOUR_LICENSE_KEY
Accept: */*
Content-Length: 133
{
  "timestamp": TIMESTAMP_IN_UNIX_EPOCH,
  "message": "User 'xyz' logged in",
  "logtype": "nginx",
  "service": "login-service",
  "hostname": "login.example.com"
}