パイプラインでデータを処理する 🔗
パイプラインは、インジェストされたデータがCollector内でたどる経路を定義するもので、受信から始まり、さらに処理または修正され、最後にデータがエクスポーターを通じてCollectorから出るときに定義されます。
パイプラインは、ログ、トレース、メトリクスの 3 種類のデータで動作します。Splunk Observability Cloud のデータについて詳しくは、Splunk Observability Cloud のデータ型 を参照してください。
注釈
Collector で一般的なアクションやタスクを実行する方法については、Collector を使用します：一般的なタスクの実行方法 を参照してください。
パイプラインを定義する 🔗
パイプラインは、パイプライン定義に基づいて Collector 起動時に構築されます。各コンポーネントの動作については、Collector コンポーネント を参照してください。
パイプラインを定義するには、まずパイプライン構成でデータ型を指定する必要があります。パイプラインで使用するすべてのレシーバー、エクスポーター、プロセッサーが特定のデータ型をサポートしていなければなりません。そうでない場合、コンフィギュレーションがロードされたときに ErrDataTypeIsNotSupported というエラーメッセージが表示されます。
パイプラインには1つ以上のレシーバーを含めることができます。すべてのレシーバーからのデータは、最初のプロセッサーにプッシュされ、プロセッサーはそのデータに対して処理を行い、次のプロセッサーにプッシュし、パイプラインの最後のプロセッサーがデータをエクスポーターにプッシュするまで、これを繰り返します。各エクスポーターは各データ要素のコピーを取得します。最後のプロセッサーはデータファンアウトコネクタを使用して、データを複数のエクスポーターにファンアウト（分配）します。
You can also use connectors to connect two pipelines: it consumes data as an exporter at the end of one pipeline and emits data as a receiver at the start of another pipeline. It may consume and emit data of the same data type, or of different data types. A connector may generate and emit data to summarize the consumed data, or it may simply replicate or route data. Learn more at:ref:otel-components-connectors.
パイプライン設定の例 🔗
パイプラインのコンフィギュレーションは通常次のようになります：
service:
pipelines:
# Pipelines can contain multiple subsections, one per pipeline.
traces:
# Traces is the pipeline type.
receivers: [otlp, jaeger, zipkin]
processors: [memory_limiter, batch]
exporters: [otlp, splunk_hec, jaeger, zipkin]
この例では、3つのレシーバー、2つのプロセッサー、4つのエクスポーター ーで、traces のパイプラインを定義します。次の表に、この例で使用するレシーバー、プロセッサー、およびエクスポーターを示します。詳細は、Collector コンポーネント を参照してください。
コンポーネント |
説明 |
パイプラインの種類 |
|---|---|---|
レシーバー |
|
トレース、メトリクス、ログ |
レシーバー |
|
トレース |
レシーバー |
|
トレース |
プロセッサー |
|
メトリクス、トレース、ログ |
プロセッサー |
|
メトリクス、トレース、ログ |
エクスポーター |
|
トレース、メトリクス |
エクスポーター |
|
メトリクス、ログ |
エクスポーター |
|
トレース |
エクスポーター |
|
トレース |
メタデータの変換 🔗
メタデータとは、テレメトリデータに付加される名前と値のペアを指します。OpenTelemetry はこれを Spans の Attributes 、Metrics の Labels 、Logs の Fields と呼んでいます。詳細は GitHub の リソースSDK 、メトリクスAPI 、トレースの意味上の規約 を参照してください。
属性 🔗
属性は、0個以上のキーと値のペアのリストです。属性は以下のプロパティを持たなければなりません：
属性キーで、空文字列であってはなりません。
属性値で、これらの型のいずれかです：
プリミティブ型：文字列、ブーリアン、倍精度浮動小数点（IEEE 754-1985）、符号付き64ビット整数。
プリミティブ型の値の配列。配列は均質でなければなりません。つまり、異なる型の値を含んではなりません。配列値をネイティブにサポートしていないプロトコルでは、それらの値をJSON文字列として表現します。
ゼロの数値、空の文字列、または空の配列を表現する属性値は、意味があるとみなされ、格納され、プロセッサーまたはエクスポーターに渡されなければなりません。
null の属性値は無効であり、 null の値を設定しようとすると未定義の動作となります。
null values are not allowed in arrays. However, if it is impossible to make sure that no null values are accepted (for example, in languages that do not have appropriate compile-time type checking), null values within arrays MUST be preserved as-is (that is, passed on to processors or exporters as null). If exporters do not support exporting null values, you can replace those values by 0, false, or empty strings. Changing these values is required for map and dictionary structures represented as two arrays with indices that are kept in sync (for example, two attributes header_keys and header_values, both containing an array of strings to represent a mapping header_keys[i] -> header_values[i]).
ラベル 🔗
ラベルは、メトリクスデータポイントに追加される名前/値のペアです。ラベルはOpenTelemetry仕様では非推奨です。ラベルの代わりに属性を使用してください。
フィールド 🔗
フィールドは、ログレコードに追加される名前と値のペアです。各レコードには2種類のフィールドが含まれます：
特定の型と意味を持つ名前付きトップレベルフィールド。
フィールドは
map<string, any>として保存され、様々なタイプの任意の値を含むことができます。よく知られたフィールドのキーと値は、そのフィールドを扱うすべての関係者がデータを同じように解釈できるよう、キー名と取り得る値に関する意味上の規約に従います。
次のステップ：取り込んだデータの確認と管理 🔗
Collector を使用してデータを取り込み、処理した後、Splunk Observability Cloud で最終的なエクスポートバージョンを確認できます。
ログの確認と管理 🔗
ログの確認と管理には、Splunk Log Observer Connect を使用してください。
注意
Splunk Log Observer は新規ユーザー向けには提供されなくなりました。すでに権利をお持ちの場合は、引き続き Log Observer を使用できます。詳しくは Log Observer をセットアップする を参照してください。
メトリクスの確認と管理 🔗
Splunk Observability Cloud には、メトリクスを追跡・管理するためのツールがいくつか用意されています：
メトリクスを管理するには、Splunk Infrastructure Monitoring のメトリクス パイプライン管理 を参照してください。
Splunk Observability Cloud が生成するメトリクスについては、Splunk Observability Cloudの組織のメトリクスを表示する も参照してください。