Splunk Observability Cloudの用語集 🔗
A 🔗
- エージェント（デプロイの方法） 🔗
エージェントとは、Splunk Distribution of OpenTelemetry Collector のインスタンスがアプリケーションと共に、またはアプリケーションと同じホスト上で実行されるデプロイメント方法です。たとえば、Splunk Distribution of OpenTelemetry Collector をLinux、Kubernetes、またはWindows用に構成する場合は、エージェントのデプロイ方法を使用しています。
- アラート 🔗
アラートは、ディテクタールールの条件が満たされたときにトリガーされます。例えば、アプリケーションのリクエスト数を監視するあるディテクターは、リクエスト数が静的閾値（例えば1分あたり20リクエスト）を下回る場合、および／または計算された閾値（例えば過去1時間の1分あたりのリクエスト数の平均＋3標準偏差）を上回る場合にアラートを生成するルールを持っています。
When an alert is triggered, the detector also creates an event and might optionally send a notification. All currently active alerts can be viewed under Detectors & SLOs.
- 分析 🔗
分析とは、データポイントの集合に適用できる数学関数です。Splunk Infrastructure Monitoringで適用可能な分析の全リストは、Analytics reference for Splunk Observability Cloud を参照してください。
- 自動ディスカバリー 🔗
自動ディスカバリーは、Splunk Distribution of the OpenTelemetry Collectorの機能であり、お使いの環境で実行されているサードパーティのデータベースや Web サーバーなどのサービスを識別し、それらからの遠隔測定データを Splunk Application Performance Monitoring (APM) と Infrastructure Monitoring に送信します。Collectorは、各サービスで公開されているエンドポイントからデータを収集するサービス固有のレシーバーを構成します。詳細については、App とサービスのオートディスカバリー を参照してください。
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 🔗
- インテグレーション 🔗
インテグレーションとは、Splunk Observability Cloudをサードパーティのサービスに接続するSplunk Observability Cloudの設定可能なコンポーネントです。ほとんどのインテグレーションはサードパーティのデータサービスを接続しますが、Splunk Observability CloudはSSOと通知のインテグレーションも提供します。
M 🔗
- メトリクス 🔗
メトリクスは、Splunk Infrastructure Monitoringに送信するデータの主な形式です。メトリクスは数値として表される定期的な測定結果です。同じメトリクスを複数のソースまたは送信元からレポートすることができます。通常、ソースとメトリックの一意の組み合わせはそれぞれ metric time series になります。
- メトリクスカーディナリティ 🔗
メトリクスカーディナリティは、メトリクス名と関連するディメンションの組み合わせによって生成される一意のメトリック時系列（MTS）の数です。したがって、メトリクスのカーディナリティが高いのは、ディメンションキーの数が多く、それらのディメンションキーに対して取り得る一意の値の数が多い場合です。
- メトリック時系列 🔗
メトリック時系列（MTS）は、メトリクスとディメンションセット（空の場合もある）の一意の組み合わせによって定義されます。最も一般的なディメンションはソースで、インフラストラクチャメトリクスの場合はホストやインスタンス、アプリケーションメトリクスの場合はアプリケーションコンポーネントやサービス層などです。分析パイプラインの出力もメトリック時系列です。
- MTS 🔗
metric time series を参照してください。
- ミュートルール 🔗
ミュートルールは、指定した アラート の 通知 を送信しない期間を定義するものです。アラート通知のミュート を参照してください。
N 🔗
P 🔗
- プロパティ 🔗
プロパティとは、メトリクス、ディメンション、または時系列に結び付けることのできるキーと値のペアです。プロパティは、関連付けられているオブジェクトに関する追加の操作情報を提供するために使用できる任意のテキストデータを定義します。プロパティは、時系列IDの一部ではないという意味において、ディメンションとは異なります。プロパティの値を変更しても、その時系列のIDには影響しません。
プロパティ値は、チャートの動的フィルタ―として（例：場所のプロパティ値が「シアトル」のサーバーのCPU使用率の90パーセンタイルの表示）、または、グループ化のために（例：サーバーのCPU使用率の90パーセンタイルを場所の値でグループ化して表示）、最も頻繁に使用されます。
R 🔗
- レルム 🔗
あなたの組織がホストされている Splunk Observability Cloud の自己完結型デプロイメント。異なるレルムには異なる Splunk Observability Cloud API エンドポイントがあります。たとえば、us1 レルムでデータを送信するエンドポイントは https://ingest.us1.signalfx.com であり、eu0 レルムでデータを送信するエンドポイントは 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 🔗
- ゼロコードインストルメンテーション 🔗
ゼロコードインストルメンテーションにより、アプリケーションのソースファイルを変更することなく、アプリケーションをインストルメンテーションし、遠隔測定データをエクスポートすることができます。言語固有のインストルメンテーションエージェントは、OTLP 受信機または Splunk Observability Cloud バックエンドのいずれかにある OTLP エンドポイントに、サポートされている形式でデータをエクスポートするようにソースアプリケーションを設定します。ゼロコードインストルメンテーションは、Java、Node.js、.NET、Go、Python、Ruby、PHP で書かれたアプリケーションで利用でき、各言語でサポートされているライブラリを使用して書かれたコードの遠隔測定データを自動的に収集します。詳細については、バックエンドアプリケーションをインストルメンテーションして、スパンを Splunk APM に送信する を参照してください。