メトリクス パイプライン管理の概要 🔗
メトリクスパイプライン管理 (MPM) は、Splunk Observability Cloud メトリクスプラットフォームを進化させたもので、メトリクスのカーディナリティを一元管理する解決策を提供します。
MPMを使用すると、メトリクスのインジェストと保存の方法をよりコントロールできるため、Splunk Distribution of the OpenTelemetry Collectorのインスタンスの設定を更新することなく、コストを削減し、監視パフォーマンスを向上させることができます。Collectorを使用してインジェスト前のデータを削除するには、 Collector を使用して取り込むデータを制御する を参照してください。
メトリクスのカーディナリティとは何か、そしてそれが観測可能性にどのような影響を与えるのか？ 🔗
メトリクスのカーディナリティは、メトリクス名と関連する次元の組み合わせによって生成される一意のメトリック時系列（MTS）の数です。メトリクスのカーディナリティが高いのは、ディメンションキーの数が多く、それらのディメンションキーに対して取り得る一意の値の数が多い場合です。
例えば、http.server.duration のデータを送信するとします。http.server.duration に3つの一意な値（ endpoint、A、B ）を持つディメンション C が1つしかない場合 http.server.duration は3つのMTSを生成します。
3つの一意の値（ region、us-east、us-west ）を持つ別のディメンション eu を追加する場合、http.server.duration は、3つのエンド ポイントx 3つのリージョンの9つのMTSを生成します。
http.server.duration にはディメンションは2つしかないにもかかわらず、各ディメンションには複数の可能な値があるため、メトリクスのカーディナリティはすでに9になっています。
詳細は さらに詳しく を参照してください。
システムでの高いカーディナリティ 🔗
カーディナリティの高いメトリクスを使用すると、詳細な分析やトラブルシューティングを実行できますが、データ管理やシステムパフォーマンスに課題が生じたり、ストレージコストが増大したりする可能性があります。MPM を使用すると、メトリクスのデータ量を管理および削減し、カーディナリティが高いために発生する問題を軽減することができます。
メトリクスパイプライン管理でデータ量をコントロールする 🔗
Splunk Observability Cloudに送信するメトリクスごとに、MPMはメトリクスのデータ量とカーディナリティの取り込み、保持、管理方法の設定を支援します。
例えば、価値の低いメトリクスをアーカイブされたメトリクスや低コストデータ層にルーティング、あるいは完全に削除することもできます。一方、価値の高いメトリクスは、アラートとモニタリングのためにリアルタイム層に引き続きルーティングされます。詳細については、データルーティングを使用して、メトリクスの保存、アーカイブ、破棄を行います。 を参照してください。
また、不要なディメンションを集約することで、高カーディナリティメトリクスを低カーディナリティメトリクスに変換することもできます。詳細については、ルーティング例外ルールを使用して、特定の MTS をルーティング、またはアーカイブされたデータをリストアします。 を参照してください。
データの取り込みと保存をコントロール：データの保持、アーカイブまたはドロップ 🔗
MPMのルーティング機能により、データの取り込みと保存をコントロールすることができます：
リアルタイムでメトリクスを取り込み、保持します。リアルタイム層に保存されたメトリクスは、チャートやディテクターで利用できます。
アーカイブされたメトリクスにデータを送信します。アーカイブされたメトリクスは、チャートやディテクターでは使用できません。ルーティングをリアルタイムに変更、またはデータのサブセットをリアルタイムにフィルタリングすることで、それらのメトリクスをチャートやディテクターで再び利用できるようになります。また、必要な場合に備えて、最大8日間のアーカイブデータを復元することもできます。
メトリクスをドロップします。このオプションを選択すると、メトリクスはドロップされ、モニタリングに使用できなくなります。これらのメトリクスから派生した集計 MTS は保持できます。
詳細は、データルーティングを使用して、メトリクスの保存、アーカイブ、破棄を行います。 を参照してください。
アーカイブされたメトリクス 🔗
値の低い、アクセス頻度の低いメトリクスを安価なアーカイブ階層に送信および保存することで、メトリクスデータを拡張できます。アーカイブされたメトリクスに保存されたメトリクスは保持されますが、チャートやディテクターで直接使用することはできません。
Archived metrics are available in realms us0, us1, us2, eu0, au0, and jp0.
注釈
アーカイブされたメトリクスのコストは、リアルタイムのメトリクスの10分の1です。
アーカイブメトリクスに送信したメトリクスを使用する必要がある場合は、リアルタイムメトリクスにルーティングして戻し、チャートやディテクターでアクセスすることができます。また、最大8日間の履歴データを埋め戻し、必要に応じてリアルタイム層に復元することもできます。
注意
メトリクスのディメンションを使用して集計ルールを作成できるのは、メトリクスのディメンションのみです。カスタムプロパティまたはタグを使用した集計はサポートされていません。各タイプのメタデータの詳細については、メタデータ：ディメンション、カスタムプロパティ、タグ、属性 を参照してください。
特定のディメンションを選択すると、メトリクスパイプライン管理は新しいメトリクスを生成します。システムは、選択したディメンションに基づいて新しい MTS を作成し、各 MTS のデータポイントをロールアップします。デフォルトでは、sum、min、max、count、delta、avg、latest 関数を使用して、集計ルールがデータポイントを新しい MTS にロールアップします。集約された新しい MTS は、Splunk Observability Cloud の他の MTS と同じように使用できます。
これは、クエリ時のインジェスト後集計とどう違いますか？ 🔗
チャートまたはディテクターを設定する際、sum などの分析関数を使用してデータを集約し、sum by region などの特定のディメンションでデータをグループ化できます。この集計は、Splunk Observability Cloudが生のMTSを保存した後に行われるため、データの保存に費用がかかります。
メトリクス パイプライン管理を使用すると、MTS を保存しながら集計し、集計されたメトリクスのみを保持できます。データポイントごとに保存するディメンションが少なくなり、メトリクス パイプライン管理によってメトリクス値がロールアップされるため、ストレージコストを削減できます。
例 🔗
Splunk Infrastructure Monitoring を使用して、コンテナ化されたワークロードの http.server.duration というメトリクスを送信します。
ワークロードには、10個のエンドポイント、20個のリージョン、5個のサービス、10,000個のコンテナがあります。5つのサービスにはそれぞれ10,000個のコンテナと10個のエンドポイントがあります。
データはコンテナIDレベルで入ってきており、10（エンドポイント）*5（サービス）*20（リージョン）*10,000（コンテナ）=10,000,000 MTSを生成しています。
1つまたは複数のディメンションを集約することで、メトリクスのカーディナリティを削減できます。
1つのディメンションを使って集計する 🔗
データのソースリージョンにのみ興味があるので、region ディメンションでデータをグループ化する集計ルールを作成します。
集約されたメトリクスは、他のすべてのディメンションを削除し、ルールに基づく region ディメンションのみを保持します。 region には20の異なる値しかないため、Splunk Observability Cloudだけが20のMTSを取り込みます。
複数のディメンションを使用した集計 🔗
データのエンドポイント、リージョン、サービスの監視は継続したいが、コンテナ ID の監視は不要です。保持したいディメンションでデータをグループ化する集約ルールを作成します。
集約されたメトリクスは、container_id ディメンションを削除し、ルールに基づき、endpoint 、region 、service を保持します。新しいメトリクスのボリュームは、10 (エンドポイント) * 20 (リージョン) * 5 (サービス) = 1,000 MTS です。
データドロップルール 🔗
データドロップルールを使用すると、監視したくないデータを破棄できるため、メトリクスの量を減らし、コストを削減できます。たとえば、新しい集計メトリクスを作成する場合、元の集計されていないデータはもはや必要ないかもしれません。
次の点に注意してください：
ルーティング例外ルールを作成することで、この設定をオーバーライドできます。ルーティング例外ルールを使用して、特定の MTS をルーティング、またはアーカイブされたデータをリストアします。 を参照してください。
新しい受信データを削除することはできますが、Splunk Observability Cloud がすでにインジェストしたデータを削除することはできません。
ドロップしたデータは復元できません。
注釈
集計とルーティング例外はルーティングから独立しています。リアルタイム、アーカイブ、ドロップなど、どのルーティングシナリオでも集計ルールを作成できます。ただし、ルーティング例外ルールを作成できるのは、ルーティングが Archived Metrics に設定されている場合のみです。
データをドロップする前に、データをアーカイブまたはドロップする影響とメリット を参照してください。
データ量のコントロール：メトリクスの集計 🔗
サービスから Splunk Observability Cloud に送信するデータは、高いカーディナリティを持つことがあります。データを送信する前に送信方法を調整する代わりに、集約ルールを使用すると、選択したメトリクスデータを新しいメトリクスにロールアップすることで、重要だと考えるディメンションに基づいてデータを要約することができます。
集約ルールを使用すると、フィルターを使用してメトリクス内の MTS のサブセットを選択し、集約ルールでそれらの MTS のディメンションを保持またはドロップできます。MPM は、新しく作成された集約メトリクスにおいてのみ、MTS の選択されたディメンションを保持します。
注意
メトリクスのディメンションを使用して集計ルールを作成できるのは、メトリクスのディメンションのみです。カスタムプロパティまたはタグを使用した集計はサポートされていません。各タイプのメタデータの詳細については、メタデータ：ディメンション、カスタムプロパティ、タグ、属性 を参照してください。
未集約の生データを大量にドロップしながら、有用な洞察を提供するディメンションの組み合わせを集計することで、組織のデータフットプリントを大幅に削減することができます。
詳細は、集計ルールを使ってデータ量をコントロールする を参照してください。
注釈
集計とルーティング例外はルーティングから独立しています。集計ルールは、リアルタイム、アーカイブ、ドロップなど、どのルーティングシナリオでも作成できます。ただし、ルーティング例外ルールを作成できるのは、ルーティングがアーカイブされたメトリクスに設定されている場合だけです。
メトリクスパイプライン管理の制限事項 🔗
MPMは、以下のタイプのメトリクスでは使用できません：
https://ingest.signalfx.com/v1/collectdエンドポイントを通じてインジェストされたメトリクスSplunk Observability Cloudの orgメトリクス
APMの MetricSets
集計ルールの制限事項 🔗
You can only create aggregation rules using your metrics dimensions. Aggregation using custom properties or tags is not supported. For more information on each type of metadata, refer to メタデータ：ディメンション、カスタムプロパティ、タグ、属性.
New aggregation rules are applied to new MTS only. Existing MTS are only used as a reference to create the rule and display the projected outcome.
ヒストグラムメトリクスの制限事項 🔗
You can’t archive or aggregate histogram metrics. By default, they are routed to the real-time tier, and you can drop them with rules as well.
さらに詳しく 🔗
MPM の詳細については、以下のドキュメントを参照してください：
メトリクスとカーディナリティの詳細については、こちらをご覧ください：
メトリクスのカーディナリティについては、ブログ記事 カーディナリティとは？ モニタリングと観測可能性のためのカーディナリティメトリクス を参照してください。
メトリック時系列（MTS）については、メトリック時系列 を参照してください。
Splunk Observability Cloudのデータモデルについては、Splunk Observability Cloud のデータ型 を参照してください。