Docs » Splunk Infrastructure Monitoring のメトリクス パイプライン管理 » メトリクス パイプライン管理の概要

メトリクス パイプライン管理の概要 🔗

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

メトリクスパイプライン管理 (MPM) は、Splunk Observability Cloud メトリクスプラットフォームを進化させたもので、メトリクスのカーディナリティを一元管理する解決策を提供します。

With MPM, you have more control over how you ingest and store your metrics, so you can lower costs and improve monitoring performance without updating the configuration of your instance of the Splunk Distribution of the OpenTelemetry Collector. To remove data pre-ingest using the Collector, see Collector を使用して取り込むデータを制御する.

What is metric cardinality, and how does it impact your observability? 🔗

Metric cardinality is the number of unique metric time series (MTS) produced by a combination of metric name and its associated dimensions. A metric has high cardinality when it has a high number of dimension keys, and a high number of possible unique values for those dimension keys.

For example, say you send in data for the metric http.server.duration. If http.server.duration has only 1 dimension endpoint with 3 unique values: A, B, and C, then http.server.duration generates 3 MTS.

If you add another dimension region with 3 unique values: us-east, us-west, and eu, then http.server.duration generates 9 MTS: 3 endpoints * 3 regions.

http.server.duration にはディメンションは2つしかないにもかかわらず、各ディメンションには複数の可能な値があるため、メトリクスのカーディナリティはすでに9になっています。

For more information, see 集計ルールの制限事項.

High cardinality in your system 🔗

High-cardinality metrics allow you to perform detailed analysis and troubleshooting, but they can lead to challenges in data management and system performance​​, as well as incur higher storage costs. With MPM, you can manage and reduce your metrics』 data volume and mitigate any issues caused by high cardinality.

Use metric pipeline management to control your data volume 🔗

For each metric you send to Splunk Observability Cloud, MPM can help you configure how to ingest, keep, and manage the metric’s data volume and cardinality.

For example, you can decide to route your low-value metrics to archived metrics, a low-cost data tier, or even entirely drop them. Meanwhile, your high-value metrics continue to be routed to the real-time tier for alerting and monitoring. To learn more, see Use data routing to keep, archive, or discard your metrics.

You can also convert a high-cardinality metric into a low-cardinality metric by aggregating away the dimensions that are not needed. To learn more, see Use routing exception rules to route a specific MTS or restore archived data.

Control data ingestion and storage: Keep, archive or drop your data 🔗

You can control your data ingestion and storage with MPM’s routing capabilities:

  • Ingest and keep metrics in real time. Metrics stored in the real-time tier are available in charts and detectors.

  • Send your data to archived metrics. Archived metrics are not available in charts and detectors. You can change routing to real-time or filter a subset of data to real -time to make those metrics available in charts and detectors again. You can also restore archived data from up to 8 days in case you need it.

  • Drop your metrics. If you select this option, metrics will be dropped and won’t be available for monitoring. You can still keep aggregated MTS derived from those metrics.

To learn more, see Use data routing to keep, archive, or discard your metrics.

Archived metrics 🔗

You can scale your metric data by sending and storing low-value, infrequently accessed metrics in a cheaper archival tier. Metrics stored in archived metrics are kept, but you cannot use them in charts or detectors directly.

注釈

Archived Metrics cost one-tenth of real-time metrics.

If you need to use a metric that you’ve sent to archived metrics you can route it back to real-time metrics and access it in charts or detectors. You can also backfill historical data from up to 8 days and restore it to the real-time tier if you need to.

注意

メトリクスのディメンションを使用して集計ルールを作成できるのは、メトリクスのディメンションのみです。カスタムプロパティまたはタグを使用した集計はサポートされていません。各タイプのメタデータの詳細については、メタデータ：ディメンション、カスタムプロパティ、タグ、属性 を参照してください。

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.

これは、クエリ時のインジェスト後集計とどう違いますか？ 🔗

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

例 🔗

Splunk Infrastructure Monitoring を使用して、コンテナ化されたワークロードの http.server.duration というメトリクスを送信します。

ワークロードには、10個のエンドポイント、20個のリージョン、5個のサービス、10,000個のコンテナがあります。5つのサービスにはそれぞれ10,000個のコンテナと10個のエンドポイントがあります。

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

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

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

データのソースリージョンにのみ興味があるので、region ディメンションでデータをグループ化する集計ルールを作成します。

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 only Splunk Observability Cloud only ingests 20 MTS.

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

データのエンドポイント、リージョン、サービスの監視は継続したいが、コンテナ ID の監視は不要です。保持したいディメンションでデータをグループ化する集約ルールを作成します。

集約されたメトリクスは、container_id ディメンションを削除し、ルールに基づき、endpoint 、region 、service を保持します。新しいメトリクスのボリュームは、10 (エンドポイント) * 20 (リージョン) * 5 (サービス) = 1,000 MTS です。

データドロップルール 🔗

Data dropping rules let you discard any data you don’t want to monitor, so you can reduce metrics volume and save cost. For example, if you create a new aggregated metric, you might no longer need the original unaggregated data.

Note that:

  • You can override this setting by creating routing exception rules. See Use routing exception rules to route a specific MTS or restore archived data.

  • 新しい受信データを削除することはできますが、Splunk Observability Cloud がすでにインジェストしたデータを削除することはできません。

  • ドロップしたデータは復元できません。

注釈

Aggregation and routing exceptions are independent from routing. You can create aggregation rules in any routing scenario: real time, archived, or dropped. However, you can only create routing exception rules when routing is set to Archived Metrics.

Before you drop any data, see Impact and benefits of archiving or dropping data.

Control your data volume: Aggregate your metrics 🔗

The data you send from your services to Splunk Observability Cloud can have high cardinality. Instead of adjusting how you are sending in your data before you send it, aggregation rules allow you to summarize your data based on the dimensions you consider important by rolling up your selected metric data into new metrics that take up less storage and increase computational performance.

With aggregation rules, you can use filters to select a subset of MTS in the metric, then keep or drop dimensions in those MTS with an aggregation rule. MPM keeps selected dimensions for the MTS only in the newly created aggregated metric.

注意

メトリクスのディメンションを使用して集計ルールを作成できるのは、メトリクスのディメンションのみです。カスタムプロパティまたはタグを使用した集計はサポートされていません。各タイプのメタデータの詳細については、メタデータ：ディメンション、カスタムプロパティ、タグ、属性 を参照してください。

未集約の生データを大量にドロップしながら、有用な洞察を提供するディメンションの組み合わせを集計することで、組織のデータフットプリントを大幅に削減することができます。

To learn more, see Use aggregation rules to control your data volume.

注釈

Aggregation and routing exceptions are independent from routing. You can create aggregation rules in any routing scenario: real-time, archived, or dropped. However, you can only create routing exception rules when routing is set to archived metrics.

Metrics pipeline management limitations 🔗

MPM is not available for the following types of metrics:

  • Metrics ingested through the https://ingest.signalfx.com/v1/collectd endpoint

  • Splunk Observability Cloud’s org metrics

  • APM’s MetricSets

集計ルールの制限事項 🔗

メトリクスのディメンションを使用して集計ルールを作成できるのは、メトリクスのディメンションのみです。カスタムプロパティまたはタグを使用した集計はサポートされていません。各タイプのメタデータの詳細については、メタデータ：ディメンション、カスタムプロパティ、タグ、属性 を参照してください。

Histogram metrics limitations 🔗

You cannot archive or aggregate histogram metrics. By default, they are routed to the real-time tier, and you can drop them with rules as well.

集計ルールの制限事項 🔗

メトリクスのディメンションを使用して集計ルールを作成できるのは、メトリクスのディメンションのみです。カスタムプロパティまたはタグを使用した集計はサポートされていません。各タイプのメタデータの詳細については、メタデータ：ディメンション、カスタムプロパティ、タグ、属性 を参照してください。

さらに詳しく 🔗

See the following docs to learn more about MPM:

To learn more about metrics and cardinality, see:

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