- 重要な情報
- はじめに
- 用語集
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
プロセッサーはパイプラインの中で実行され、データ構造化アクションを完了し、ログを豊かにする属性を生成します。
ログコンフィギュレーション設定で、Grok パーサー や 日付リマッパー などの処理系を設定して、ログの属性を抽出・作成・再マッピングし、ファセット検索を充実させることが可能です。
注:
構造化ログは有効な形式で送信する必要があります。構造にパースに無効な文字が含まれている場合は、mask_sequences 機能を使用して、これらを Agent レベルで削除する必要があります。
ベストプラクティスとして、パイプライン毎のプロセッサー数は最大 20 で使用することが推奨されます。
メッセージ全体や未加工のイベントの特定の属性をパースするためのカスタム Grok ルールを作成できます。詳細については、パースのセクションを参照してください。ベストプラクティスとして、Grok プロセッサー毎のパース規則は最大 10 で使用することが推奨されます。
Datadog ログ構成ページで、Grok プロセッサープロセッサーを定義します。
Parse my logs をクリックして、基底のパイプラインを流れるログの 3 つのパースルールのセットを始動させます。そこから属性の名前を絞り込み、必要に応じて他のタイプのログに新しいルールを追加します。この機能を使用するには、対応するログがインデックス化され、実際に流入している必要があります。除外フィルターを一時的に無効にするか、サンプリングして、これを機能させることができます。
サンプルをクリックして選択すると、パースルールに対する評価が開始され、結果が画面の下に表示されます。
プロセッサーには最大 5 つのサンプルを保存できます。各サンプルの長さは最大 5000 文字となります。すべてのサンプルについて、Grok パーサーのパース規則のいずれかがそのサンプルに一致するかどうかのステータス (match
または no match
) を確認することができます。
次の Grok パーサー JSON ペイロードで Datadog ログパイプライン API エンドポイントを使用します。
{
"type": "grok-parser",
"name": "ログメッセージをパース",
"is_enabled": true,
"source": "message",
"samples": ["sample log 1", "sample log 2"],
"grok": {"support_rules": "<サポート規則>", "match_rules": "<照合規則>"}
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | いいえ | プロセッサーが有効になっているかどうか。デフォルト: false 。 |
source | 文字列 | はい | パースするログ属性の名前。デフォルト: message 。 |
samples | 文字列の配列 | いいえ | この Grok パーサーのサンプルログのリストです(最大 5)。 |
grok.support_rules | 文字列 | はい | grok パーサーのサポート規則のリスト。 |
grok.match_rules | 文字列 | はい | grok パーサーの照合規則のリスト。 |
Datadog はログを受信すると、以下のデフォルトの属性のいずれかの値を使用してタイムスタンプを付けます。
timestamp
date
_timestamp
Timestamp
eventTime
published_date
ログにこのリストにない属性の日付がある場合は、ログ日付リマッパープロセッサーを使用して、その日付属性を公式のログタイムスタンプとして定義してください。
ログに上記の形式に準拠したタイムスタンプがない場合、grok プロセッサーを使用してタイムスタンプからエポックタイムを抽出し、新しい属性に変換します。日付リマッパーは新しく定義された属性を使用します。
Datadog でカスタム日付と時間形式をパースする方法については、日付のパースを参照してください。
注:
T[hh][mm][ss]
、拡張フォーマットは T[hh]:[mm]:[ss]
です。それ以前のバージョンでは、どちらのフォーマットでも T (時刻を表す) が省略されています。Datadog ログ構成ページで、ログ日付リマッパープロセッサーを定義します。
次のログ日付リマッパー JSON ペイロードで Datadog ログパイプライン API エンドポイントを使用します。
{
"type": "date-remapper",
"name": "<ソース属性> を公式のログ日付として定義",
"is_enabled": false,
"sources": ["<ソース属性_1>"]
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | いいえ | ロセッサーが有効になっているかどうか。デフォルト: false 。 |
sources | 文字列の配列 | はい | ソース属性の配列。 |
ログに公式なステータスとして属性を割り当てるには、ステータスリマッパープロセッサーを使用します。例えば、ステータスリマッパーを使用して、ログに重大度レベルを追加します。
受信したステータス値は、次のようにマップされます。
emerg
に一致しないものは、error (3) にマップされます注: 複数のログステータスリマッパープロセッサーがログに適用された場合は、(パイプラインの順序で) 最初のプロセッサーだけが考慮されます。
Datadog ログ構成ページで、ログステータスリマッパープロセッサーを定義します。
次のログステータスリマッパー JSON ペイロードで Datadog ログパイプライン API エンドポイントを使用します。
{
"type": "status-remapper",
"name": " <ソース属性> を公式のログ日付として定義",
"is_enabled": true,
"sources": ["<ソース属性>"]
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | いいえ | ロセッサーが有効になっているかどうか。デフォルト: false 。 |
sources | 文字列の配列 | はい | ソース属性の配列。 |
サービスリマッパープロセッサーは、ログに 1 つまたは複数の属性を正式なサービスとして割り当てます。
注: 複数のサービスリマッパープロセッサーがログに適用された場合は、(パイプラインの順序で) 最初のプロセッサーだけが考慮されます。
Datadog ログ構成ページで、ログサービスリマッパープロセッサーを定義します。
次のログサービスリマッパー JSON ペイロードで Datadog ログパイプライン API エンドポイントを使用します。
{
"type": "service-remapper",
"name": "<ソース属性> を公式のログサービスとして定義",
"is_enabled": true,
"sources": ["<ソース属性>"]
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | いいえ | ロセッサーが有効になっているかどうか。デフォルト: false 。 |
sources | 文字列の配列 | はい | ソース属性の配列。 |
message
は、Datadog のキー属性です。その値はログエクスプローラーの Content 列に表示され、ログのコンテキストを提供します。検索バーを使って、ログメッセージでログを見つけることができます。
ログメッセージリマッパープロセッサーを使用して、1 つまたは複数の属性を公式ログメッセージとして定義します。属性が存在しない可能性があり、代替が可能な場合には、複数の属性を定義します。例えば、定義されたメッセージの属性が attribute1
、attribute2
、attribute3
で、attribute1
が存在しない場合は attribute2
が使用されます。同様に、attribute2
が存在しない場合、attribute3
が使用されます。
メッセージ属性を定義するには、まずストリングビルダープロセッサーを使用して、使用したい属性ごとに新しい文字列属性を作成します。次に、ログメッセージリマッパーを使用して、文字列属性をメッセージとして再マッピングします。
注: 複数のログメッセージリマッパープロセッサーがログに適用された場合は、(パイプラインの順序で) 最初のプロセッサーだけが考慮されます。
Datadog ログ構成ページで、ログメッセージリマッパープロセッサーを定義します。
次のログメッセージリマッパー JSON ペイロードで Datadog ログパイプライン API エンドポイント を使用します。
{
"type": "message-remapper",
"name": "<ソース属性> を公式のログメッセージとして定義",
"is_enabled": true,
"sources": ["msg"]
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | いいえ | ロセッサーが有効になっているかどうか。デフォルト: false 。 |
sources | 文字列の配列 | はい | ソース属性の配列。デフォルト: msg 。 |
リマッパープロセッサーは、任意のソース属性やタグを、別のターゲット属性やタグにリマップします。例えば、user
を firstname
にリマップして、ログエクスプローラーのログをターゲットにすることができます。
タグ/属性名の制約については、属性とタグのドキュメントに説明があります。いくつかの追加の制約は、:
や ,
として適用され、ターゲットタグ/属性名では許可されません。
リマッパーのターゲットが属性の場合、リマッパーは値を新しい型(String
、Integer
、Double
)への変換を試みることができます。型変換できない場合、元の型が保持されます。
注: Double
の小数点以下の桁数は .
である必要があります。
Datadog ログ構成ページで、リマッパープロセッサーを定義します。たとえば、user
を user.firstname
に再マップします。
次のリマッパー JSON ペイロードで Datadog ログパイプライン API エンドポイントを使用します。
{
"type": "attribute-remapper",
"name": "<SOURCE_ATTRIBUTE> を <TARGET_ATTRIBUTE> へ再マップ",
"is_enabled": true,
"source_type": "attribute",
"sources": ["<SOURCE_ATTRIBUTE>"],
"target": "<TARGET_ATTRIBUTE>",
"target_type": "tag",
"target_format": "integer",
"preserve_source": false,
"override_on_conflict": false
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | いいえ | ロセッサーが有効になっているかどうか。デフォルト: false 。 |
source_type | 文字列 | いいえ | ソースがログの attribute または tag のどちらであるかを定義します。デフォルト: attribute 。 |
sources | 文字列の配列 | はい | ソース属性またはタグの配列。 |
target | 文字列 | はい | ソースの再マップ先になる最終的な属性またはタグの名前。 |
target_type | 文字列 | いいえ | ターゲットがログの attribute または tag のどちらであるかを定義します。デフォルト: attribute 。 |
target_format | 文字列 | いいえ | 属性値を別の型にキャストするかを定義します。可能な値には、auto 、string 、integer があり、デフォルトは auto です。auto に設定するとキャストは適用されません。 |
preserve_source | Boolean | いいえ | 再マップされたソース要素を削除または維持します。デフォルト: false 。 |
override_on_conflict | Boolean | いいえ | ターゲット要素が既に設定されている場合に上書きするかどうか。デフォルト: false 。 |
URL パーサープロセッサーは URL からクエリパラメーターなどの重要なパラメーターを抽出します。これをセットアップすると、次の属性が生成されます。
Datadog ログ構成ページで、URL パーサープロセッサーを定義します。
{
"type": "url-parser",
"name": "http.url 属性から URL をパース",
"is_enabled": true,
"sources": ["http.url"],
"target": "http.url_details"
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | いいえ | ロセッサーが有効になっているかどうか。デフォルト: false 。 |
sources | 文字列の配列 | いいえ | ソース属性の配列。デフォルト: http.url |
target | 文字列 | はい | sources から抽出されたすべての詳細を含む親属性の名前。デフォルト: http.url_details 。 |
ユーザーエージェントパーサープロセッサーは useragent
属性を受け取り、OS、ブラウザ、デバイス、およびその他のユーザーデータを抽出します。設定されると、以下のような属性が生成されます。
注: エンコードされたユーザーエージェントがログに含まれている場合 (IIS ログなど) は、パースの前に URL をデコードするようにプロセッサーを構成してください。
Datadog ログ構成ページで、ユーザーエージェントプロセッサーを定義します。
次のユーザーエージェントパーサー JSON ペイロードで Datadog ログパイプライン API エンドポイントを使用します。
{
"type": "user-agent-parser",
"name": "<ソース属性> をパースしてすべてのユーザーエージェント情報を抽出",
"is_enabled": true,
"sources": ["http.useragent"],
"target": "http.useragent_details",
"is_encoded": false
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | いいえ | プロセッサーが有効になっているかどうか。デフォルト: false 。 |
sources | 文字列の配列 | いいえ | ソース属性の配列。デフォルト: http.useragent 。 |
target | 文字列 | はい | sources から抽出されたすべての詳細を含む親属性の名前。デフォルト: http.useragent_details 。 |
is_encoded | Boolean | いいえ | ソース属性が URL エンコードされているかどうかを定義します。デフォルト: false 。 |
指定された検索クエリに一致するログに、新しい属性 (新しい属性の名前にはスペースまたは特殊文字を含まない) を追加するには、カテゴリプロセッサーを使用します。次に、複数のカテゴリを使用すると、1 つの分析ビューに複数のグループが作成されます (複数の URL グループ、マシングループ、環境、応答時間バケットなど)。
注:
Datadog ログ構成ページで、カテゴリプロセッサーを定義します。たとえば、Web アクセスログをステータスコード範囲に基づいて分類 (応答コード 200 ~ 299 の場合は「OK」、応答コード 300 ~ 399 の場合は「通知」など) するには、次のプロセッサーを追加します。
このプロセッサーは、次のような結果をもたらします。
次のカテゴリプロセッサー JSON ペイロードで Datadog ログパイプライン API エンドポイントを使用します。
{
"type": "category-processor",
"name": "<ターゲット属性> 属性にカスタム値を割り当て",
"is_enabled": true,
"categories": [
{"filter": {"query": "<クエリ_1>"}, "name": "<割り当て値_1>"},
{"filter": {"query": "<クエリ_2>"}, "name": "<割り当て値_2>"}
],
"target": "<ターゲット属性>"
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | いいえ | ロセッサーが有効になっているかどうか。デフォルト: false 。 |
categories | オブジェクトの配列 | はい | フィルターと名前の配列。フィルターはログに一致するかどうかを識別し、名前はログにカスタム値を割り当てるために使用されます。 |
target | 文字列 | はい | 一致するカテゴリによって値が定義されるターゲット属性の名前。 |
ログに、指定された式の結果を含む新しい属性 (新しい属性の名前にはスペースまたは特殊文字を含まない) を追加するには、算術演算プロセッサーを使用します。これにより、異なる単位を持つ異なる時間属性を 1 つの属性に再マップしたり、同じログ内の複数の属性に対して演算を行ったりします。
算術演算プロセッサー式には、括弧および基本的な算術演算子 -
、+
、*
、/
を使用できます。
デフォルトでは、属性がない場合は計算がスキップされます。Replace missing attribute by 0 を選択すると、属性値がない場合は自動的に 0 を挿入して、常に計算が行われます。
注: ログの属性にない場合、または数値に変換できない場合、属性が見つからないと表示されることがあります。
注:
-
は、属性名にも使用されるため、式内ではスペースで区切る必要があります。0.1234567891
の場合、実際に属性に格納される値は 0.123456789
になります。Datadog ログ構成ページで、算術演算プロセッサーを定義します。
次の算術演算プロセッサー JSON ペイロードで Datadog ログパイプライン API エンドポイントを使用します。
{
"type": "arithmetic-processor",
"name": "<プロセッサー名>",
"is_enabled": true,
"expression": "<算術演算>",
"target": "<ターゲット属性>",
"is_replace_missing": false
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | いいえ | プロセッサーが有効になっているかどうか。デフォルト: false 。 |
expression | 文字列 | はい | 1 つ以上のログ属性間の算術演算。 |
target | 文字列 | はい | 算術演算の結果を格納する属性の名前。 |
is_replace_missing | Boolean | いいえ | true の場合は、expression 内の欠落している属性をすべて 0 に置き換えます。false の場合は、属性が欠落していると演算をスキップします。デフォルト: false 。 |
ログに、指定されたテンプレートの結果を含む新しい属性 (スペースまたは特殊文字を含まない) を追加するには、ストリングビルダープロセッサーを使用します。これを使用して、異なる属性や生文字列を 1 つの属性に集約することができます。
このテンプレートは生テキストとブロックに %{attribute_path}
構文を組み合わせた形で定義されます。
注:
Datadog ログ構成ページで、ストリングビルダープロセッサーを定義します。
以下のようなログがある場合、テンプレート Request %{http.method} %{http.url} was answered with response %{http.status_code}
を使って、結果を返します。例:
{
"http": {
"method": "GET",
"status_code": 200,
"url": "https://app.datadoghq.com/users"
},
"array_ids": [123, 456, 789],
"array_users": [
{"first_name": "John", "last_name": "Doe"},
{"first_name": "Jack", "last_name": "London"}
]
}
リクエスト GET https://app.datadoghq.com/users に対する応答 200
注: http
はオブジェクトであり、ブロック内で使用することはできません (%{http}
は失敗します)。一方、%{http.method}
、%{http.status_code}
、または %{http.url}
は、対応する値を返します。ブロックは、値の配列や配列内の特定の属性に対して使用することができます。例えば、 %{array_ids}
というブロックを追加すると、以下のような値が返されます。
123,456,789
%{array_users}
はオブジェクトリストのため戻り値はありません。
しかし、%{array_users.first_name}
は次のように配列に含まれる first_name
のリストを返します:
John,Jack
次のストリングビルダープロセッサー JSON ペイロードで Datadog ログパイプライン API エンドポイントを使用します。
{
"type": "string-builder-processor",
"name": "<プロセッサー名>",
"is_enabled": true,
"template": "<ストリングビルダーテンプレート>",
"target": "<ターゲット属性>",
"is_replace_missing": true
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | 〇 | プロセッサーのタイプ。 |
name | 文字列 | ✕ | プロセッサーの名前。 |
is_enabled | Boolean | ✕ | プロセッサーが有効になっているかどうかを示します。デフォルトは false です。 |
template | 文字列 | 〇 | 1 つまたは複数の属性と生テキストを使用した数式です。 |
target | 文字列 | 〇 | テンプレートの結果を含む属性名です。 |
is_replace_missing | Boolean | ✕ | true の場合は、template 内の欠落している属性をすべて空の文字列に置き換えます。false の場合 (デフォルト) は、属性が欠落していると演算をスキップします。 |
geoIP パーサーは、IP アドレスの属性を受け取り、対象の属性パスに大陸、国、小区域、または都市情報 (利用可能な場合) を抽出します。
ほとんどの要素は name
と iso_code
(大陸の場合は code
) 属性を含んでいます。subdivision
は国が使用する最初のレベルの細分化で、アメリカ合衆国の場合は “States”、フランスの場合は “Departments” となります。
例えば、geoIP パーサーは network.client.ip
属性から位置を抽出し、それを network.client.geoip
属性に格納します。
次の geoIP パーサー JSON ペイロードで Datadog ログパイプライン API エンドポイントを使用します。
{
"type": "geo-ip-parser",
"name": "network.client.ip 属性から位置情報のエレメントをパース",
"is_enabled": true,
"sources": ["network.client.ip"],
"target": "network.client.geoip"
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | いいえ | ロセッサーが有効になっているかどうか。デフォルト: false 。 |
sources | 文字列の配列 | いいえ | ソース属性の配列。デフォルト: network.client.ip |
target | 文字列 | はい | sources から抽出されたすべての詳細を含む親属性の名前。デフォルト: network.client.geoip |
ルックアッププロセッサーを使用して、ログ属性と Reference Table (ベータ版) またはプロセッサーマッピングテーブルに保存された人間が読める値との間のマッピングを定義することができます。
例えば、ルックアッププロセッサーを使用して、内部サービス ID を人間が読めるサービス名にマッピングすることができます。
また、本番環境への接続を試みた MAC アドレスが、盗まれたマシンのリストに含まれているかどうかの確認にも使用できます。
ルックアッププロセッサーは、以下の動作を行います。
マッピングテーブルには、Reference Table を選択する、手動で source_key,target_value
のリストを入力する、または CSV ファイルをアップロードすることで値を入力できます。
マッピングテーブルのサイズ上限は 100Kb です。この制限はプラットフォーム上のすべてのルックアッププロセッサーに適用されますが、Reference Table はより大容量のファイルサイズをサポートしています。
次のルックアッププロセッサー JSON ペイロードで Datadog ログパイプライン API エンドポイントを使用します。
{
"type": "lookup-processor",
"name": "<プロセッサー名>",
"is_enabled": true,
"source": "<ソース属性>",
"target": "<ターゲット属性>",
"lookup_table": ["key1,value1", "key2,value2"],
"default_lookup": "<デフォルトターゲット値>"
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | はい | プロセッサーが有効になっているかどうかを示します。デフォルトは false です。 |
source | 文字列 | はい | ルックアップを実行する際に使用したソース属性です。 |
target | 文字列 | はい | マッピングリスト内 (マッピングリスト内で見つからない場合は default_lookup ) の対応する値を含む属性名です。 |
lookup_table | 文字列の配列 | はい | ソース属性値とそれに関連するターゲット属性値のマッピングテーブルです。[ “source_key1,target_value1”, “source_key2,target_value2” ] のような形式で示されます。 |
default_lookup | 文字列 | いいえ | リスト上にソースの値がない場合、ターゲット属性に設定する値です。 |
アプリケーショントレースとログの間の関連付けを改善する方法は 2 つあります。
トレース ID をアプリケーションログに挿入する方法のドキュメントを参照してください。セットアップの大半は、ログのインテグレーションによってデフォルトで行われます。
トレースリマッパープロセッサーを使用して、トレース ID として関連付けられるログ属性を定義します。
Datadog ログ構成ページで、トレースリマッパープロセッサーを定義します。次のように、プロセッサータイルでトレース ID 属性パスを入力します。
次のトレースリマッパー JSON ペイロードで Datadog ログパイプライン API エンドポイントを使用します。
{
"type": "trace-id-remapper",
"name": "dd.trace_id を、このログに関連する公式のトレース ID として定義",
"is_enabled": true,
"sources": ["dd.trace_id"]
}
パラメーター | タイプ | 必須 | 説明 |
---|---|---|---|
type | 文字列 | はい | プロセッサーのタイプ。 |
name | 文字列 | いいえ | プロセッサーの名前。 |
is_enabled | Boolean | いいえ | プロセッサーが有効になっているかどうか。デフォルト: false 。 |
sources | 文字列の配列 | いいえ | ソース属性の配列。デフォルト: dd.trace_id 。 |
お役に立つドキュメント、リンクや記事: