Docs » Splunk Observability Cloudの組織のメトリクスを表示する

Splunk Observability Cloudの組織のメトリクスを表示する 🔗

Splunk Observability Cloudは具体的なメトリクスを提供するため、組織のプラットフォームの使用状況を測定することができます。

組織のメトリクスには以下が含まれます：

  • 取り込みのメトリクス：送信したデータポイントの数など、Infrastructure Monitoringに送信しているデータを測定します。

  • アプリ使用状況のメトリクス：組織内のダッシュボードの数など、アプリケーション機能の使用状況を測定します。

  • インテグレーションのメトリクス：AWS CloudWatch APIへのコール数など、組織と統合されたクラウドサービスの使用状況を測定します。

  • リソースのメトリクス：作成したカスタムメトリック時系列（MTS）の数など、制限を指定できるリソースの使用状況を測定します。

これらのメトリクスの使用について料金は発生しません。また、これらは システムの制限 にカウントされません。

組織のメトリクスへのアクセス 🔗

管理者の場合は、「組織の概要」ページの組み込みチャートでこれらのメトリクスの一部を表示できます。すべてのユーザーは、カスタムチャートでこれらのメトリクスを表示できます。

「組織の概要」ページにアクセスするには、以下の手順に従ってください：

  1. Log into Splunk Observability Cloud.

  2. 左側のナビで、設定 を選択し、組織の概要 を選択します。

  3. 表示したいメトリクスのタブを選択します：

  • エンゲージメント：ユーザーと、ユーザーが作成したチャート、ディテクター、ダッシュボード、ダッシュボードグループ、チームに関するメトリクス。

  • APMエンタイトルメント：APMのトラブルシューティング用。

  • APMのスロットリング；組織内のスロットリングと制限を追跡するメトリクスを強調表示するチャート。

  • IMエンタイトルメント：IMのトラブルシューティング用。

  • IMシステム制限：組織内のシステム制限の使用状況を追跡するメトリクスを特定するチャート。

  • IMのスロットリング；組織内のスロットリングと制限を追跡するメトリクスを強調表示するチャート。

  • クラウドインテグレーション：クラウドプロバイダーAPIからのテレメトリ収集を制限する可能性のあるエラーとスロットリングを追跡するメトリクスを強調表示するチャート。

組織のメトリクスの解釈と活用 🔗

このセクションでは、使用状況に関するメトリクスの解釈と活用に役立つヒントを提供します。

データ制限、データスロットリング、データフィルタリング 🔗

Data is limited or throttled if you exceed your entitlements or system limits, as explained in Metrics that track system limits and Metrics that track data throttling.

また、データはプラットフォームからフィルタリングされ、特定の組織メトリクス値 で追跡することができます：

  • Data can be automatically filtered out by certain components, such as the SignalFx exporter.

  • 無効なデータもプラットフォームに到達するとフィルタリングされます。例えば、メトリクス名や値がないデータポイントは無効であり、除外されます。トレースやスパンIDのないスパンも同様です。

gross と num のメトリクス値の比較 🔗

メトリクスの中には、 gross 値と num 値をレポートするものがあります。メトリクスの gross と num の値を比較して、システムがデータを制限またはフィルタリングしているかどうかを確認します。

  • gross メトリクスは、スロットリングやフィルタリングが作動する前にシステムが受信するデータポイントの総数をレポートします。

  • num メトリクスは、システムがスロットリングまたはフィルタリングを完了した後に受信するデータポイントの総数をレポートします。

システム制限を追跡するメトリクス 🔗

これらのメトリクスは、Infrastructure Monitoringが組織に課す制限を追跡します。これらの制限を超えると、データが除外されることがあります。

  • sf.org.limit.activeTimeSeries （ゲージ）：過去25時間の移動窓内で、組織が持つことができるアクティブなMTSの最大数。この制限を超えると、Infrastructure Monitoringは新しいMTSのデータポイントの受け入れを停止しますが、既存のMTSのデータポイントの受け入れは継続します。この制限に対する使用状況を監視するには、sf.org.numActiveTimeSeries のメトリクスを使用します。

  • sf.org.limit.containers (gauge): Maximum number of containers that can send data to your organization. This limit is higher than your contractual limit to allow for burst and overage usage. If you exceed this limit, Infrastructure Monitoring drops data points from new containers but keeps accepting data points for existing containers. To monitor your usage against the limit, use the metric sf.org.numResourcesMonitored and filter for the dimension resourceType:containers.

  • sf.org.limit.computationsPerMinute （ゲージ）：1分あたりのSignalFlowの最大計算回数。

  • sf.org.limit.customMetricMaxLimit （ゲージ）：過去60分間の移動窓内で、組織にデータを送信できるアクティブなカスタムMTSの最大数。この制限を超えると、Infrastructure Monitoringは、制限を超えたカスタムMTSのデータポイント を除外しますが、すでに存在していたカスタムMTSのデータポイントの受け入れは継続します。sf.org.numCustomMetrics で定義したカスタムメトリクスを参照してください。

    カスタムMTSの詳細は、カスタムメトリクスとバンドルメトリクスについて を参照してください。

  • sf.org.limit.customMetricTimeSeries （ゲージ）：アクティブなカスタムMTSの最大数。

  • sf.org.limit.detector （ゲージ）：組織に使用できるディテクターの最大数。この上限に達すると、新しいディテクターを作成できなくなります。作成するディテクターの数を監視するには、sf.org.num.detector のメトリクスを使用します。

  • sf.org.limit.eventsPerMinute （ゲージ）：1分あたりの受信イベントの最大数。

  • sf.org.limit.hosts (gauge): Maximum number of hosts that can send data to your organization. The limit is higher than your contractual limit to allow for burst and overage usage. If you exceed this limit, Infrastructure Monitoring drops data points from new hosts but keeps accepting data points for existing hosts. To monitor your usage against the limit, use the metric sf.org.numResourcesMonitored and filter for the dimension resourceType:hosts.

  • sf.org.limit.metricTimeSeriesCreatedPerMinute （ゲージ）：組織での新規MTS作成の最大レート。1分あたりのMTSで測定されます。このレートを超えると、Infrastructure Monitoringは新しいMTSのデータポイントの受け入れを停止しますが、既存のMTSのデータポイントの受け入れは継続します。作成したメトリクスの総数を監視するには、sf.org.numMetricTimeSeriesCreated のメトリクスを使用します。

データのスロットリングを追跡するメトリクス 🔗

As explained in the previous section, certain system limits act as a “ceiling”, or a maximum number of elements allowed in Observability Cloud. But the platform also limits ingestion pace. If you exceed your rate limits, Splunk Observability Cloud might throttle, or slow down, the data you send in.

名前に limit または limited が含まれる組織のメトリクスは、量の上限に達していることを示しますが、throttled が含まれるメトリクス（たとえば、sf.org.numThrottledMetricTimeSeriesCreateCalls ）は、レート/時間の上限に達していることを示し、したがって、1分あたりのデータポイント数を超えて送信することができなくなります。

詳細は、製品別のシステム制限 を参照してください

トークン別の値のメトリクス 🔗

Infrastructure Monitoringが2つの類似したメトリクスを持つ場合があります：

  • 1つのメトリクスは、sf.org.numAddDatapointCalls のように、組織全体の合計を表します。

  • これに類似したメトリクス、sf.org.numAddDatapointCallsByToken は、使用される一意のアクセストークンごとの合計を表します。

The sum of all the by token metric values for a measurement might be less than the total value metric value. For example, the sum, of all sf.org.numAddDatapointCallsByToken values might be less than the value of sf.org.numAddDatapointCalls. The sums differ because Infrastructure Monitoring doesn’t use a token to retrieve data from cloud services you’ve integrated. Infrastructure Monitoring counts the data point calls for the integrated services, but it doesn’t have a way to count the calls for any specific token.

AWS CloudWatch、GCP StackDriver、AppDynamicsについて、この値の差が発生します。

各メトリクスタイプに対して値を持つメトリクス 🔗

一部のメトリクスは、メトリクスのタイプ（カウンター、累積カウンター、ゲージ）ごとに値を持つため、メトリクスごとに3つのMTSがあります。各MTSには、COUNTER、CUMULATIVE_COUNTER、または GAUGE の値を持つ category というディメンションがあります。これらのメトリクスは複数のMTSを持つ可能性があるため、sum() のSignalFlow関数を使用して合計値を確認する必要があります。

例えば、sf.org.numMetricTimeSeriesCreated について3つのMTSを受け取る可能性があります。カウンターであるMTSの数に対して1つ、累積カウンターであるMTSの数に対して1つ、ゲージであるMTSの数に対して1つです。

また、category を単一の値でフィルタリングして（例： GAUGE ）、そのタイプのメトリクスだけを表示することもできます。

停止したディテクターをカウントするメトリクス 🔗

sf.org.numDetectorsAborted のメトリクスは、ディテクターがリソース制限に達したためにInfrastructure Monitoringが停止させたディテクターの数を監視します。大部分は、ディテクターが250K MTSの制限を超えた場合です。この条件はまた、ディテクターID、停止の理由、およびMTSまたはデータポイントの値または制限（ディテクターが停止した原因となったいずれか）の詳細を記録するイベント sf.org.abortedDetectors も生成します。

詳細については、イベントを使用してメトリクスにコンテキストを追加する を参照してください。

クラウド認証エラーのメトリクス 🔗

Editing a role and removing a user’s permissions to cloud services might generate authentication errors from your cloud service provider. When this happens, Splunk Observability Cloud integrations won’t work properly, and won’t be able to collect data and metadata from your services.

Splunk Observability Cloud has the following metrics to track auth errors:

  • sf.org.num.awsServiceAuthErrorCount

  • sf.org.num.gcpServiceAuthErrorCount

  • sf.org.num.azureServiceAuthErrorCount

If you’re getting any of these errors, you need to fix your roles or tokens so Splunk Observability Cloud can retrieve your data.

ダッシュボード で、これらのエラーを使用して、この問題が発生しているかどうかを検出することができます。

子組織のメトリクス 🔗

If a parent org has associated child organizations, child org metrics are also added to Splunk Observability Cloud. They represent the same values as the equivalent parent org metric, and you can identify them with the child prefix.

For example, sf.org.child.numCustomMetrics represents the number of custom metrics Splunk Observability Cloud monitors for the child org, the same way sf.org.numCustomMetrics is the number of custom metrics monitored for the parent org.

組織のメトリクスのリスト 🔗

メトリクスファインダー を使用して、組織のメトリクスを検索します。

Splunk Observability Cloud provides the following organization metrics:

トラブルシューティング 🔗

Splunk Observability Cloudをご利用のお客様で、Splunk Observability Cloud内のデータを確認できない場合は、以下の方法でサポートを受けることができます。

Splunk Observability Cloudをご利用のお客様

見込み客および無料トライアルユーザー様

  • Splunk Answers のコミュニティサポートで質問し、回答を得る

  • Splunk #observability ユーザーグループの Slack チャンネルに参加して、世界中の顧客、パートナー、Splunk 社員とのコミュニケーションを図る。参加するには、Get Started with Splunk Community マニュアルの チャットグループ を参照してください。

このページは 2024年12月09日 に最終更新されました。