Splunk Observability Cloudの用語集 🔗
A 🔗
- エージェント（デプロイの方法） 🔗
エージェントとは、Splunk Distribution of OpenTelemetry Collector のインスタンスがアプリケーションと共に、またはアプリケーションと同じホスト上で実行されるデプロイメント方法です。たとえば、Splunk Distribution of OpenTelemetry Collector をLinux、Kubernetes、またはWindows用に構成する場合は、エージェントのデプロイ方法を使用しています。
- アラート 🔗
アラートは、ディテクタールールの条件が満たされたときにトリガーされます。例えば、アプリケーションのリクエスト数を監視するあるディテクターは、リクエスト数が静的閾値（例えば1分あたり20リクエスト）を下回る場合、および／または計算された閾値（例えば過去1時間の1分あたりのリクエスト数の平均＋3標準偏差）を上回る場合にアラートを生成するルールを持っています。
アラートがトリガーされると、ディテクターは event も作成し、オプションで notification を送信する場合もあります。現在アクティブになっているアラートはすべて「アラートとディテクター」で確認できます。
- 分析 🔗
分析とは、データポイントの集合に適用できる数学関数です。Splunk Infrastructure Monitoringで適用可能な分析の全リストは、Splunk Observability Cloudの関数のリファレンス を参照してください。
- automatic discovery 🔗
Automatic discovery is a feature of the Splunk Distribution of the OpenTelemetry Collector that identifies the services, such as third-party databases and web servers, running in your environment and sends telemetry data from them to Splunk Application Performance Monitoring (APM) and Infrastructure Monitoring. The Collector configures service-specific receivers that collect data from an endpoint exposed on each service. For more information, see Discover telemetry sources automatically.
C 🔗
- コールスタック 🔗
コールスタックとは、現在呼び出されているメソッドを追跡するためにマシンが使用するデー タ構造のことです。アクティブなコールスタックがサンプリングされると、その結果はスタックトレースになります。
- カウンターメトリクス 🔗
カウンターメトリックスタイプは、ある時間間隔内の発生回数のカウントであるデータを表します。これは、アクティビティやイベントの発生を測定するもので、例えば、ウェブサイトが提供するウェブページの数や、プロセス内の例外の数などがあります。ある期間のカウンターを合計すると、その間隔内の正味のアクティビティが計算されます。カウンターはゼロ以上の整数値しか取ることができず、各レポート間隔の終了時にゼロにリセットされます。
- 累積カウンターメトリクス 🔗
累積カウンターメトリクスタイプは、発生回数の累積カウントを表します。これは通常、アプリケーションまたはプロセスの生涯におけるアクティビティの合計を表します。累積カウンターはレポート間隔ごとにリセットされません。累積カウンターの例としては、Webサーバーが起動してからの Splunk Infrastructure Monitoring API呼び出しの総数や、インターフェイスが起動してからの送信バイトの総計などがあります。累積カウンターも、カウンターと同様に、増分値を導くために使用できます。
D 🔗
- ディテクター 🔗
ディテクターは、ユーザーの関心対象の条件について信号をモニターします。
これらの条件は、条件が満たされたときにアラートをトリガーする1つまたは複数のルールとして表されます。ディテクター内の個々のルールは、重大度に応じて「情報」、「警告」、「マイナー」、「メジャー」、「クリティカル」のラベルを付されます。
例えば、APIコールのレイテンシを監視するあるディテクターは、ディテクタールールで定義されている「通常」よりもレイテンシが著しく高い場合に「クリティカル」のアラートをトリガーします。
詳細は、Splunk Observability Cloudのアラートとディテクターの概要 を参照してください。
- ディメンション 🔗
ディメンションとは、メトリクス名とともに時系列のIDの一部となるキーと値のペアです。Infrastructure Monitoring全体で、これらのディメンションによって時系列をフィルタリングおよび集計できます。
E 🔗
- イベント 🔗
イベントとは、Splunk Infrastructure Monitoringに構造化されたログラインとして表される定期的な発生事象です。例えば、イベントの値はキーと値のペアの任意の組み合わせとして表すことができます。イベントはInfrastructure Monitoringにおいて メトリクス に次ぐものであり、メトリクスデータにコンテキストを提供することを意図しています。イベントは、チャートに表示したり、「イベント」サイドバーに表示したりできます。詳細は イベントを使用してメトリクスにコンテキストを追加する を参照してください。
- イベント時系列 🔗
イベント時系列（ETS）は、イベント名およびオプションの追加ディメンションによって一意に識別されるイベントのシーケンスです。例えば、
code pushという名前でrepositoryというディメンションを持つイベント時系列を作成して、あるリポジトリのコードプッシュイベントを記録することができます。このようなETSの例としては、sf_eventType:code push ``やrepository:ui-code-base``があります。
F 🔗
- フレームグラフ 🔗
フレームグラフは、スタックトレースの集合を視覚的に表現したものです。スタックトレース内のすべてのコード行に対して、対応する行がフレームグラフ内にあります。フレームグラフの各バーの幅は、フレームグラフの時間範囲内で収集されたスタックトレースにおいてそれぞれのコード行が現れる回数を表しています。例えば、あるコード行がフレームグラフの幅の100％を占める場合、そのコード行は、その集合内のすべてのスタックトレースに現れているということです。フレームグラフのY軸は、スタックトレースの深さを示します。フレ―ムグラフの色はランダムです。X軸は時間順ではありません。スタックトレースの左から右への順序はランダムであり、時間ベースのシーケンスとの相関はありません。
- フラッピー 🔗
ある detector が頻繁にアラートをトリガーしクリアする場合、その状態を「フラッピー」といいます。たとえば、値が90%に達したときにアラートをトリガーするようにディテクターを設定していて、監視している信号がこの値の周辺で定期的に急上昇したり急降下したりする場合、アラートのトリガーとクリアの頻度が高くなりすぎてアラートの意味がありません。このフラッピーな状態を抑えるために、アラートがトリガーされる前に値が90%の状態を一定時間維持する必要があることを条件で指定するとよいでしょう。
G 🔗
- ゲートウェイ（デプロイの方法） 🔗
ゲートウェイとは、Splunk Distribution of OpenTelemetry Collector が単独で実行されるデプロイメントの方法です。Splunk Distribution of OpenTelemetry Collectorをスタンドアロンパッケージとして構成する場合は、ゲートウェイのデプロイ方法を使用しています。
- ゲージメトリクス 🔗
ゲージメトリクスタイプは、各時点で特定の値を持つデータを表します。これは、一定時間にわたる何らかの値を測定するものです。監視において使用されるゲージの例には、CPU使用率、JVMのヒープ空き率、アプリケーションの内部キューのサイズなどがあります。レポート頻度（つまり、どれくらいの頻度で読み取りを行うか）は、ゲージにとって最も重要です。一般的に、頻度が高いほど精度の高さと結びつくからです。
たとえば、CPU使用率を5分ごとに測定するということは、読み取りと読み取りの間に発生した可能性のあるピークやバレーを見逃すということですが、それらのピークやバレーが重要である可能性は十分にあります。
I 🔗
- インテグレーション 🔗
An integration is a configurable component of Splunk Observability Cloud that connects Splunk Observability Cloud to a third-party service. Most integrations connect third-party data services, but Splunk Observability Cloud also offers SSO and notification integrations.
M 🔗
- メトリクス 🔗
メトリクスは、Splunk Infrastructure Monitoringに送信するデータの主な形式です。メトリクスは数値として表される定期的な測定結果です。同じメトリクスを複数のソースまたは送信元からレポートすることができます。通常、ソースとメトリックの一意の組み合わせはそれぞれ メトリック時系列 になります。
- メトリクスカーディナリティ 🔗
メトリクスカーディナリティは、メトリクス名と関連するディメンションの組み合わせによって生成される一意のメトリック時系列（MTS）の数です。したがって、メトリクスのカーディナリティが高いのは、ディメンションキーの数が多く、それらのディメンションキーに対して取り得る一意の値の数が多い場合です。
- メトリック時系列 🔗
メトリック時系列（MTS）は、メトリクスとディメンションセット（空の場合もある）の一意の組み合わせによって定義されます。最も一般的なディメンションはソースで、インフラストラクチャメトリクスの場合はホストやインスタンス、アプリケーションメトリクスの場合はアプリケーションコンポーネントやサービス層などです。分析パイプラインの出力もメトリック時系列です。
- MTS 🔗
metric time series を参照してください。
- ミュートルール 🔗
ミュートルールは、指定した アラート の 通知 を送信しない期間を定義するものです。アラート通知のミュート を参照してください。
N 🔗
P 🔗
- プロパティ 🔗
プロパティとは、メトリクス、ディメンション、または時系列に結び付けることのできるキーと値のペアです。プロパティは、関連付けられているオブジェクトに関する追加の操作情報を提供するために使用できる任意のテキストデータを定義します。プロパティは、時系列IDの一部ではないという意味において、ディメンションとは異なります。プロパティの値を変更しても、その時系列のIDには影響しません。
プロパティ値は、チャートの動的フィルタ―として（例：場所のプロパティ値が「シアトル」のサーバーのCPU使用率の90パーセンタイルの表示）、または、グループ化のために（例：サーバーのCPU使用率の90パーセンタイルを場所の値でグループ化して表示）、最も頻繁に使用されます。
R 🔗
- realm 🔗
The self-contained deployment of Splunk Observability Cloud where your organization is hosted. Different realms have different Splunk Observability Cloud API endpoints. For example, the endpoint for sending data in the us1 realm is https://ingest.us1.signalfx.com, while the endpoint for sending data in the eu0 realm is https://ingest.eu0.signalfx.com.
- ロールアップ 🔗
データポイントの蓄積で、何らかの数式または統計的式が適用されたものです。例えば、1週間の期間における95パーセンタイルの計算です。Infrastructure Monitoringのプロットでは、ロールアップは、Infrastructure Monitoringがチャートや分析計算で使用するデータポイントをどのように準備するかを決定します。
例えば、時間範囲を-1m（過去1分）から-1w（過去1週間）に変更した場合、Averageなどのロールアップ関数を使って複数のデータポイントを1つにまとめ、より広い時間枠のデータポイントを効果的に表示することができます。
詳細は、ロールアップ を参照してください。
- ルール 🔗
detector には、ディテクターが alert をトリガーする条件と、アラートの重大度、そして、条件の発生時と条件のクリア時に送信される 通知 の受信者を指定する1つまたは複数のルールが含まれます。
詳細は、ディテクターのアラートルールを作成する を参照してください。
S 🔗
- シグナル 🔗
Infrastructure Monitoringのチャートの文脈においてシグナルとは、チャートにプロットするメトリック時系列、または、ディテクターまたは追加の分析の入力として使用するメトリック時系列です。
- スタックトレース 🔗
スタックトレースとは、コールスタックのスナップショットをサンプリングしたものです。スタックトレースには、指定したスレッドのコールスタック内のクラス名、メソッド名、行番号が含まれます。たとえば、AlwaysOn Profilingでは、Java仮想マシンで実行されているすべてのスレッドのスタックトレースがキャプチャされます。スタックトレースがすべてのVMスレッドにわたってサンプリングされると、その結果はスレッドダンプとなります。
- スパン 🔗
スパンとは、トレース内の単一の操作です。セッションは、スパンとトレースの集合で構成されます。
- Splunk Distribution of OpenTelemetry Collector 🔗
Splunk Distribution of OpenTelemetry Collectorは、Splunk Distribution of OpenTelemetry Collectorと追加コンポーネントをバンドリングし、特定のプラットフォーム向けにトレース、メトリクス、ログの統合的収集と転送を提供するパッケージです。Splunk Distribution of OpenTelemetry Collectorの設定には、エージェントのデプロイ方法 を使用します。
T 🔗
- タグ 🔗
タグは、ディメンション、メトリクス、およびその他のオブジェクトに割り当てられたラベルまたはキーワードと考えることができます。キーと値のペアではありません。
タグの主な用途は、タグとタグの割り当て先のオブジェクトとの間に1対多の関係がある場合です。例えば、複数のアプリを実行しているホストがあるとします。各アプリのタグを作成すると、各ホストに複数のタグを適用して、そのホストで実行中のアプリを指定することができます。
- トレース 🔗
トレースとは、アプリケーションとそれを構成するサービスによって処理される一意のトランザクションを表す操作の集合です。トレースは、スパン（マイクロサービスが互いに実行し合うコール）で構成されます。
Z 🔗
- zero-code instrumentation 🔗
Zero-code instrumentation allows you to instrument your applications and export telemetry data without having to modify the application source files. The language-specific instrumentation agent configures the source application to export data in a supported format to an OTLP endpoint, on either an OTLP receiver or the Splunk Observability Cloud back end. Zero-code instrumentation is available for applications written in Java, Node.js, .NET, Go, Python, Ruby, and PHP and automatically collects telemetry data for code written using supported libraries in each language. For more information, see バックエンドアプリケーションをインストルメンテーションして、スパンを Splunk APM に送信する.