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 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 Automatic discovery of apps and services.
C 🔗
- コールスタック 🔗
コールスタックとは、現在呼び出されているメソッドを追跡するためにマシンが使用するデー タ構造のことです。アクティブなコールスタックがサンプリングされると、その結果はスタックトレースになります。
- カウンターメトリクス 🔗
The counter metric type represents data that is a count of occurrences in a time interval. It measures occurrences of an activity or event, for example, the number of web pages served by a website or the number of exceptions in a process. Summing counters over a period of time produces the net activity in that interval. Counters can only take integer values of zero or greater and are reset to zero at the conclusion of each reporting interval.
- 累積カウンターメトリクス 🔗
The cumulative counter metric type represents a running count of occurrences. It typically represents the total activity in the lifetime of an application or process. Cumulative counters are NOT reset with each reporting interval. Examples of cumulative counters include the total number of Splunk Infrastructure Monitoring API calls served since a web server started up, or the total number of bytes transmitted by an interface since it started up. Cumulative counters can also be used to derive incremental values, just as counters can.
D 🔗
- ディテクター 🔗
ディテクターは、ユーザーの関心対象の条件について信号をモニターします。
これらの条件は、条件が満たされたときにアラートをトリガーする1つまたは複数のルールとして表されます。ディテクター内の個々のルールは、重大度に応じて「情報」、「警告」、「マイナー」、「メジャー」、「クリティカル」のラベルを付されます。
例えば、APIコールのレイテンシを監視するあるディテクターは、ディテクタールールで定義されている「通常」よりもレイテンシが著しく高い場合に「クリティカル」のアラートをトリガーします。
詳細は、Splunk Observability Cloudのアラートとディテクターの概要 を参照してください。
- ディメンション 🔗
ディメンションとは、メトリクス名とともに時系列のIDの一部となるキーと値のペアです。Infrastructure Monitoring全体で、これらのディメンションによって時系列をフィルタリングおよび集計できます。
E 🔗
- イベント 🔗
An event is a periodic occurrence that can be represented as a structured log line to Splunk Infrastructure Monitoring. For example, the values could be represented as any combination of key/value pairs. Events are secondary to metrics in Infrastructure Monitoring and are meant to provide context for the metric data. Events can be displayed on charts and viewed in the Events sidebar. See イベントを使用してメトリクスにコンテキストを追加する.
- イベント時系列 🔗
イベント時系列(ETS)は、イベント名およびオプションの追加ディメンションによって一意に識別されるイベントのシーケンスです。例えば、
code push
という名前でrepository
というディメンションを持つイベント時系列を作成して、あるリポジトリのコードプッシュイベントを記録することができます。このようなETSの例としては、sf_eventType:code push `` や `` repository:ui-code-base
があります。
F 🔗
- フレームグラフ 🔗
The flame graph is a visual representation of a collection of stack traces. For every line of code in the stack trace, there is a corresponding line in the flame graph. The width of each bar in the flame graph represents the number of times the respective line of code appears in the stack traces that have been collected in the time range of the flame graph. For example, if a line of code occupies 100% of the width of the flame graph, then that line of code appears in all of the stack traces in the collection. The y-axis of the flame graph shows the depth of the stack trace. The colors of the flame graph are random. The x-axis is not ordered by time. The ordering of stack traces from left to right is random and it does not correlate to a time-based sequence.
- フラッピー 🔗
A detector is said to be 「flappy」 when it triggers and clears alerts too frequently. For example, if you have a detector set to trigger an alert when a value reaches 90%, and the signal you are monitoring regularly spikes and dips around this value, alerts will be triggered and cleared too often to be of value. To reduce this flappiness, you might want to specify that the value must remain at 90% for a specified amount of time before triggering an alert.
G 🔗
- ゲートウェイ(デプロイの方法) 🔗
ゲートウェイとは、Splunk Distribution of OpenTelemetry Collector が単独で実行されるデプロイメントの方法です。Splunk Distribution of OpenTelemetry Collectorをスタンドアロンパッケージとして構成する場合は、ゲートウェイのデプロイ方法を使用しています。
- ゲージメトリクス 🔗
The gauge metric type represents data that has a specific value at each point in time. It measures the value of something over time. Examples of gauges used in monitoring include CPU utilization percentage, % free JVM heap, or the size of an internal queue in an application. Reporting frequency (in other words, how often you take a reading) is most important for gauges, as higher frequency is typically associated with higher accuracy.
たとえば、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 🔗
- プロパティ 🔗
Properties are key-value pairs that can be bound to metrics, dimensions, or time series. They define arbitrary text data that can be used to provide additional operational information on the objects they are associated with. Properties are different from dimensions in the sense that they do not take part in the identity of a time series; changing the value of a property does not affect the identity of that time series.
プロパティ値は、チャートの動的フィルタ―として(例:場所のプロパティ値が「シアトル」のサーバーの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 🔗
- 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 に送信する.