多くの種類のログは、KPI などのトレンドを長期間にわたって追跡するテレメトリーとして使用されます。CDN ログ、VPC フロー ログ、ファイアウォール ログ、ネットワーク ログなど、大量のログ データを要約する手段として、ログからメトリクスを生成することはコスト効率が高い方法です。generate metrics プロセッサを使用すると、クエリに一致するログをカウントするカウント メトリクス、またはリクエストの所要時間などログに含まれる数値値を分布として集計するディストリビューション メトリクスを生成できます。

注: 生成されたメトリクスは カスタム メトリクス として課金されます。詳細は カスタム メトリクスの課金 を参照してください。

To set up the processor:

Click Manage Metrics to create new metrics or edit existing metrics. This opens a side panel.

• If you have not created any metrics yet, enter the metric parameters as described in the Add a metric section to create a metric.
• If you have already created metrics, click on the metric’s row in the overview table to edit or delete it. Use the search bar to find a specific metric by its name, and then select the metric to edit or delete it. Click Add Metric to add another metric.

Add a metric

1. Enter a filter query. Only logs that match the specified filter query are processed. All logs, regardless of whether they match the filter query, are sent to the next step in the pipeline. Note: Since a single processor can generate multiple metrics, you can define a different filter query for each metric.
2. Enter a name for the metric.
3. Define parameters セクションで、メトリクスのタイプ (count、gauge、distribution) を選択します。カウント メトリクスの例 と ディストリビューション メトリクスの例 を参照してください。詳細は メトリクスのタイプ も参照してください。
   • For gauge and distribution metric types, select a log field which has a numeric (or parseable numeric string) value that is used for the value of the generated metric.
   • For the distribution metric type, the log field’s value can be an array of (parseable) numerics, which is used for the generated metric’s sample set.
   • Group by フィールドでは、メトリクス値をどのようにグループ化するかを決定します。たとえば、4 つのリージョンに数百台のホストが分散している場合、リージョンでグループ化すると各リージョンごとに 1 本の線をグラフ化できます。Group by 設定で指定したフィールドは、構成されたメトリクスのタグとして設定されます。
4. Click Add Metric.

メトリクスタイプ

これらのタイプのメトリクスはログに対して生成できます。詳細は メトリクスのタイプ と ディストリビューション のドキュメントを参照してください。

カウント メトリクスの例

status:error ログの例の場合:

{"status": "error", "env": "prod", "host": "ip-172-25-222-111.ec2.internal"}

"status":"error" を含むログの数をカウントし、それらを env と host でグループ化するカウント メトリクスを作成するには、次の情報を入力します:

ディストリビューション メトリクスの例

次の API レスポンス ログの例の場合:

{
    "timestamp": "2018-10-15T17:01:33Z",
    "method": "GET",
    "status": 200,
    "request_body": "{"information"}",
    "response_time_seconds: 10
}

API 呼び出しに要する平均時間を測定するディストリビューション メトリクスを作成するには、次の情報を入力します:

Filter query syntax

Each processor has a corresponding filter query in their fields. Processors only process logs that match their filter query. And for all processors except the filter processor, logs that do not match the query are sent to the next step of the pipeline. For the filter processor, logs that do not match the query are dropped.

For any attribute, tag, or key:value pair that is not a reserved attribute, your query must start with @. Conversely, to filter reserved attributes, you do not need to append @ in front of your filter query.

For example, to filter out and drop status:info logs, your filter can be set as NOT (status:info). To filter out and drop system-status:info, your filter must be set as NOT (@system-status:info).

Filter query examples:

• NOT (status:debug): This filters for only logs that do not have the status DEBUG.
• status:ok service:flask-web-app: This filters for all logs with the status OK from your flask-web-app service.
  • This query can also be written as: status:ok AND service:flask-web-app.
• host:COMP-A9JNGYK OR host:COMP-J58KAS: This filter query only matches logs from the labeled hosts.
• @user.status:inactive: This filters for logs with the status inactive nested under the user attribute.

Queries run in the Observability Pipelines Worker are case sensitive. Learn more about writing filter queries in Datadog’s Log Search Syntax.