Docs » Splunk Infrastructure Monitoring のメトリクス パイプライン管理 » Use aggregation rules to control your data volume

Use aggregation rules to control your data volume 🔗


Available in Enterprise Edition. For more information, see サブスクリプションの種類、拡張、更新、解約.


Data you send from your services to Splunk Observability Cloud can have high cardinality. Instead of adjusting how you send in your data before you send it, aggregation lets you summarize your data in Splunk Observability Cloud based on the dimensions you consider important.

See the following diagram to understand how aggregation works:

flowchart LR accTitle: Data aggregation diagram accDescr: Metrics pipeline management (MPM) receives raw incoming metric time series (MTS). You choose an MTS to aggregate, and perform the aggregation, then you choose whether to keep or drop the raw MTS. MPM keeps the aggregated MTS and any raw MTS that you chose to keep. Raw[(Incoming raw MTS)] ---|MPM|ChooseDimensions{"`Choose MTS to aggregate`"} ---|Perform aggregation|CreateNew("`New aggregated MTS with rolled-up metrics`") ---|Keep or drop raw MTS|OriginalMTS[(Kept MTS and new MTS)]

保持する特定のディメンションを選択することで、データポイントをより少ないディメンションの新しいメトリクスに集約し、重要なディメンションの特定のビューを作成することができます。すべてのディメンションにまたがるメトリクスを表示する必要がない場合は、より簡素化されたデータの集中的なビューを得ることができます。

When you select specific dimensions, metrics pipeline management generates a new metric. The system creates new MTS based on the dimensions you select and rolls up data points for each MTS. By default, aggregation rules roll up the data points into the new MTS using sum, min, max, count, delta, avg, and latest functions.

You can use the new aggregated MTS in the same way as any other MTS in Splunk Observability Cloud.

How is MPM aggregation different from post-ingestion aggregation at query time? 🔗

When you configure charts or detectors, you can aggregate your data using analytic functions, such as sum, and then group your data by specific dimensions, such as sum by region. This aggregation occurs after Splunk Observability Cloud has stored your raw MTS, so you still pay for storing the data.

メトリクス パイプライン管理を使用すると、MTS を保存しながら集計し、集計されたメトリクスのみを保持できます。データポイントごとに保存するディメンションが少なくなり、メトリクス パイプライン管理によってメトリクス値がロールアップされるため、ストレージコストを削減できます。

🔗

You send a metric called http.server.duration for a containerized workload using Splunk Infrastructure Monitoring:

  • Your workload has 10 endpoints, 20 regions, 5 services, and 10,000 containers.

  • Each of the 5 services has 10,000 containers and 10 endpoints.

データはコンテナIDレベルで入ってきており、10(エンドポイント)*5(サービス)*20(リージョン)*10,000(コンテナ)=1,000,000 MTSを生成しています。

1つまたは複数のディメンションを集約することで、メトリクスのカーディナリティを削減できます。

1つのディメンションを使って集計する 🔗

Scenario: You are only interested in the source region of your data.

In this case, you can create an aggregation rule that groups your data by the region dimension. The aggregated metric removes all other dimensions and retains only the region dimension based on your rule.

There are only 20 different values for region, so Splunk Observability Cloud only ingests 20 MTS.

複数のディメンションを使用した集計 🔗

Scenario: You want to continue monitoring endpoints, regions, and services for your data, but don’t need to monitor container IDs.

In this case, you can create an aggregation rule that groups your data by the dimensions you want to keep. The aggregated metric removes the container_id dimension and retains endpoint, region, and service based on your rule.

Your new metric volume is: 10 endpoints * 20 regions * 5 services = 1,000 MTS.

MTS集計ロールアップ期間 🔗

システムから定期的にデータポイントが送信され ているが、その周期が10秒より長い場合、MTS 集計の結果は期待したものと異なる可能性があります。

For example, suppose your systems generate data points every 5 seconds. Two successive data points have timestamps that differ by 5 seconds. If your systems immediately transmit the points to Splunk Observability Cloud, the system ingests two data points every 10 seconds. Metrics pipeline management can roll up the two data points into one aggregated data point with a resolution of 10 seconds, which is the result you expect.

If you are sending data points, but they don’t always arrive with the same frequency, Splunk Observability Cloud might receive two data points in the first 10 seconds, then twelve data points in the next 10 seconds. In both cases, metrics pipeline management rolls up the raw points into a single aggregated data point.

また、毎秒データポイントを送信し、受信データポイントの解像度を維持したい場合は、MTS集計を使用しないでください。

潜在的な問題 🔗

未加工のデータポイントが作成されたときにシステムが追加するタイムスタンプと、データポイントを集計するときにシステムが使用する時間の違いは、次のいずれかの問題を引き起こす可能性があります:

  • 集計されたMTSの開始時刻と終了時刻がずれる可能性があります。サーバーで生成されたデータポイントが、タイムスタンプに記録された作成時刻からしばらくして到着する場合があります。この場合、集計された MTS 全体がチャート上でより新しい時刻にシフトし、開始時刻が実際のタイムスタンプよりも新しいことを示します。このシフトは、メトリクス パイプライン管理がデータポイントのタイムスタンプを無視し、代わりにデータポイントをインジェストした時刻を使用するために発生します。

    For example, if your data points have a 10:00 timestamp, but Splunk Observability Cloud doesn’t start receiving them until 10:10, the aggregated MTS seems to start at 10:10 instead of 10:00.

  • 集計されたMTSは、誤った継続時間を持つように見える可能性があります。

解決策 🔗

以下のオプションを使用することで、このような集約の問題を避けることができます:

  • 不要なディメンションを削除するように OTel Collector を再設定することによって、データを送信する前に独自の MTS 集約を実行します。

  • チャートの生成やディテクターの作成時に、SignalFlowを使用してデータを集約します。

Benefits of aggregating using metric pipeline management 🔗

Use MPM instead of aggregation at query time 🔗

Although you can use SignalFlow to aggregate MTS by applying the 「group by」 option, this aggregation is different from MPM aggregation:

  • MPM aggregates MTS before storing the MTS in the Splunk Observability Cloud database.

  • SignalFlow stores MTS in the database before doing the aggregation.

  • SignalFlow can’t help you remove high-cardinality dimensions, and it can’t drop MTS you don’t need.

  • MPM aggregation occurs before raw MTS ingestion is complete, so you can eliminate high-cardinality dimensions and drop data you don’t want.

Use MPM instead of modifying the Splunk Distribution of the OpenTelemetry Collector 🔗

When you use MPM, you don’t have to modify the configuration of your Splunk Distribution of the OpenTelemetry Collector. With MPM you can remove high-cardinality dimensions, drop MTS you don’t need, and route MTS to the low-cost data tier after you ingest OpenTelemetry data.

To learn how to remove data before ingestion by modifying the Collector configuration, see Collector を使用して取り込むデータを制御する.

Create aggregation rules for a metric 🔗

注釈

You must have the Admin or Power user role to create or edit an aggregation rule. For more information, see Splunk Observability Cloud のロールについて.

To access and create the aggregation rules for a metric follow these steps:

  1. Access your Splunk Observability Cloud account.

  2. In the left navigation menu, select Settings > Metrics Pipeline Management to access the landing screen with a list of all your metrics and a summary of their rulesets.

  3. Select or search for a metric to access the metric’s summary page.

  4. In the Added by rule tile, select Add.

  5. In the Create aggregation rule dialog, complete the options:

  • Name your rule.

  • Filter incoming data to a specific MTS population. Search for dimension keys or values to narrow down the associated metric time series (MTS).

  • Configure the dimensions settings. Search for dimensions and select either Keep or Drop. Splunk Observability Cloud saves the dimensions you keep in the new aggregated MTS and removes the dropped dimensions.

注釈

You cannot aggregate histogram metrics.

After creating new metrics using aggregation, you can drop unwanted or unnecessary metrics and reduce your data volume. Learn more at Impact and benefits of archiving or dropping data.

Edit, deactivate, or delete an aggregation rule 🔗

To edit, activate/deactivate, or delete an existing routing exception rule, perform the following steps:

  1. Access your Splunk Observability Cloud account.

  2. In the left navigation menu, select Settings > Metrics Pipeline Management to access the landing screen with a list of all your metrics and a summary of their rulesets.

  3. Select or search for a metric to access the metric’s summary page.

  4. From the list of rules, find the metric you want to change, then select any of the available options in the More actions (⋮) menu.

This page was last updated on 2024年05月08日.