You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 2, 2025. It is now read-only.
:description: Learn how to process data collected with the Splunk Distribution of OpenTelemetry Collector.
8
+
:description: Learn how to process data collected with the Splunk Distribution of the OpenTelemetry Collector.
9
9
10
-
A pipeline defines the path the ingested data follows in the Collector, starting from reception, then further processing or modification, and finally when data exits the Collector through exporters.
10
+
Use pipelines in your Collector's config file to define the path you want your ingested data to follow. Specify which components you want to use, starting from data reception using :ref:`receivers <otel-components-receivers>`, then data processing or modification with :ref:`processors <otel-components-processors>`, until data finally exits the Collector through :ref:`exporters<otel-components-exporters>`. For an overview of all available components and theire behavior refer to :ref:`otel-components`.
11
11
12
12
Pipelines operate on three data types: logs, traces, and metrics. To learn more about data in Splunk Observability Cloud, see :ref:`data-model`.
13
13
@@ -16,13 +16,36 @@ Pipelines operate on three data types: logs, traces, and metrics. To learn more
16
16
Define the pipeline
17
17
=========================================
18
18
19
-
The pipeline is constructed during Collector startup based on the pipeline definition. See :ref:`otel-components` to understand the behavior of each component.
19
+
The pipeline is constructed during Collector startup based on your Collector's config file.
20
20
21
-
To define the pipeline, first you need to specify a data type in your pipeline configuration. All the receivers, exporters, and processors you use in a pipeline must support the particular data type, otherwise you'll get the ``ErrDataTypeIsNotSupported`` error message when the configuration is loaded.
21
+
See more at:
22
22
23
-
A pipeline can contain one or more receivers. Data from all receivers is pushed to the first processor, which performs processing on it and then pushes it to the next processor and so on until the last processor in the pipeline pushes the data to the exporters. Each exporter gets a copy of each data element. The last processor uses a data fan-out connector to fan out (distribute) the data to multiple exporters.
23
+
* :ref:`Collector for Kubernetes <collector-kubernetes-intro>`
24
+
* :ref:`Collector for Linux <collector-linux-intro>`
25
+
* :ref:`Collector for Windows <collector-windows-intro>`
24
26
25
-
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`.
27
+
The following applies:
28
+
29
+
* You need to specify a data type in your pipeline configuration. All the receivers, exporters, and processors you use in a pipeline must support the particular data type, otherwise you'll get the ``ErrDataTypeIsNotSupported`` error message when the configuration is loaded.
30
+
31
+
* A pipeline can contain one or more receivers.
32
+
33
+
* Data from all receivers is pushed to the first processor, which performs processing on it and then pushes it to the next processor and so on until the last processor in the pipeline uses a data fan-out connector to fan out (distribute) the data to multiple exporters.
34
+
35
+
* Note that some types of processor "mutate" (duplicate) data before they pass it on to the next processor.
36
+
37
+
* If a pipeline uses more than one exporter, each exporter receives a copy of each data element from the last processor.
38
+
39
+
* In case of failure, the rest of exporters continue to work independently.
40
+
41
+
* You can configure exporters to "mutate" (duplicate) the data they receive. In the Splunk OTel Collector this option is not enabled.
You can use connectors to connect two pipelines. Connectors consume data as an exporter at the end of one pipeline and emit data as a receiver at the start of another pipeline. They can consume and emit data of the same data type, or of different data types. Use connectors to generate and emit data which summarizes the data you've already consumed, or to simply replicate or route data.
@@ -40,7 +63,7 @@ A pipeline configuration typically looks like this:
40
63
processors: [memory_limiter, batch]
41
64
exporters: [otlp, splunk_hec, jaeger, zipkin]
42
65
43
-
This example defines a pipeline for ``traces``, with three receivers, two processors, and four exporters. The following table describes the receivers, processors, and exporters used in this example. For more details, see :ref:`Collector components <otel-components>`.
66
+
This example defines a pipeline for ``traces``, with three receivers, two processors, and four exporters. The following table describes the receivers, processors, and exporters used in this example.
44
67
45
68
.. list-table::
46
69
:widths: 25 50 25
@@ -80,37 +103,7 @@ This example defines a pipeline for ``traces``, with three receivers, two proces
80
103
Metadata transformations
81
104
============================================
82
105
83
-
Metadata refers to the name/value pair added to telemetry data. OpenTelemetry calls this ``Attributes`` on ``Spans``, ``Labels`` on ``Metrics``, and ``Fields`` on ``Logs``. See :new-page:`Resource SDK <https://github.com/open-telemetry/opentelemetry-specification/blob/49c2f56f3c0468ceb2b69518bcadadd96e0a5a8b/specification/resource/sdk.md>`, :new-page:`Metrics API <https://github.com/open-telemetry/opentelemetry-specification/blob/49c2f56f3c0468ceb2b69518bcadadd96e0a5a8b/specification/metrics/api.md>`, and :new-page:`Trace Semantic Conventions <https://github.com/open-telemetry/opentelemetry-specification/blob/52cc12879e8c2d372c5200c00d4574fa73996369/specification/trace/semantic_conventions/README.md>` in GitHub for additional details.
84
-
85
-
Attributes
86
-
--------------------------
87
-
88
-
Attributes are a list of zero or more key-value pairs. An attribute must have the following properties:
89
-
90
-
* The attribute key, which must be a non-null and non-empty string.
91
-
* The attribute value, which is one of these types:
92
-
93
-
* A primitive type: string, boolean, double precision floating point (IEEE 754-1985) or signed 64-bit integer.
94
-
* An array of primitive type values. The array must be homogeneous. That is, it must not contain values of different types. For protocols that do not natively support array values, represent those values as JSON strings.
95
-
96
-
Attribute values expressing a numerical value of zero, an empty string, or an empty array are considered meaningful and must be stored and passed on to processors or exporters.
97
-
98
-
Attribute values of ``null`` are not valid and attempting to set a ``null`` value is undefined behavior.
99
-
100
-
``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]``).
101
-
102
-
Labels
103
-
-----------------------------------------
104
-
105
-
Labels are name/value pairs added to metric data points. Labels are deprecated from the OpenTelemetry specification. Use attributes instead of labels.
106
-
107
-
Fields
108
-
---------------------------------------
109
-
110
-
Fields are name/value pairs added to log records. Each record contains two kinds of fields:
111
-
112
-
* Named top-level fields of specific type and meaning.
113
-
* Fields stored as ``map<string, any>``, which can contain arbitrary values of different types. The keys and values for well-known fields follow semantic conventions for key names and possible values that allow all parties that work with the field to have the same interpretation of the data.
106
+
Metadata refers to the name/value pair added to telemetry data. Learn more at :ref:`otel-tags`.
:description: Add tags to your Splunk Distribution of OpenTelemetry Collector configuration. You can include span tags in settings for the batch processor in your configuration YAML file.
8
+
:description: Add tags to your Splunk Distribution of the OpenTelemetry Collector configuration. You can include span tags in settings for the batch processor in your configuration YAML file.
9
9
10
10
Tags are key-value pairs of data associated with recorded measurements to provide contextual information, distinguish, and group metrics during analysis and inspection.
11
11
@@ -162,3 +162,11 @@ For example, suppose your application sends in data for a metric named ``custom.
162
162
163
163
Splunk Observability Cloud provides a report that allows for management of metrics usage, and you can create rules to drop undesirable dimensions. See more at :ref:`subscription-overview`.
* :new-page:`Metrics API <https://github.com/open-telemetry/opentelemetry-specification/blob/49c2f56f3c0468ceb2b69518bcadadd96e0a5a8b/specification/metrics/api.md>`
All customers who have both Splunk Cloud Platform and Splunk Observability Cloud can access Unified Identity. Users must be on Splunk Cloud Platform version 9.x and higher. The AWS region for your Splunk Cloud Platform instance must be the same as your Splunk Observability Cloud instance realm. Unified Identity is not supported in GovCloud regions.
24
+
All customers who have both Splunk Cloud Platform and Splunk Observability Cloud can access Unified Identity. Users must be on Splunk Cloud Platform version 9.x and higher. The AWS or GCP region for your Splunk Cloud Platform instance must map to your Splunk Observability Cloud instance realm as shown in the following table:
25
+
26
+
.. list-table::
27
+
:header-rows: 1
28
+
:width: 100%
29
+
30
+
* - :strong:`Splunk Observability Cloud realm`
31
+
- :strong:`AWS Region`
32
+
- :strong:`GCP Region`
33
+
* - us0
34
+
- AWS US East Virginia (us-east-1)
35
+
-
36
+
* - us1
37
+
- AWS US West Oregon (us-west-2)
38
+
-
39
+
* - us2
40
+
-
41
+
- GCP US Oregon (us-west-1)
42
+
* - eu0
43
+
- AWS EU Dublin (eu-west-1)
44
+
-
45
+
* - eu1
46
+
- AWS EU Frankfurt (eu-central-1)
47
+
-
48
+
* - eu2
49
+
- AWS EU London (eu-west-2)
50
+
-
51
+
* - au0
52
+
- AWS AP Sydney (ap-southeast-2)
53
+
-
54
+
* - jp0
55
+
- AWS AP Tokyo (ap-northeast-1)
56
+
-
57
+
58
+
.. note:: Unified Identity is not supported in GovCloud regions.
The following table describes the types of steps you can include:
49
+
Assertions are checks to see what state an object exists in, for example if text is present or an element is visible.
50
+
The following table describes the types of steps you can include for actions:
50
51
51
52
.. list-table::
52
53
:header-rows: 1
@@ -58,15 +59,15 @@ The following table describes the types of steps you can include:
58
59
* - Accept alert
59
60
- Accept an alert that appears on the page.
60
61
61
-
* - Dismiss alert
62
-
- Dismiss an alert that appears on the page.
63
-
64
62
* - Clear
65
63
- Clear an element you identify under :guilabel:`Selector`. Optionally, wait for navigation.
66
64
67
65
* - Click
68
66
- Click on an element you identify under :guilabel:`Selector`. Optionally, wait for navigation.
69
67
68
+
* - Dismiss alert
69
+
- Dismiss an alert that appears on the page.
70
+
70
71
* - Fill in field
71
72
- Fill a field you identify under :guilabel:`Selector` with a value you provide under :guilabel:`Value`. Optionally, wait for navigation. For security and reusability, use a built-in, custom, or global variable to provide the value. See :ref:`global-variables` to learn more.
72
73
@@ -88,26 +89,9 @@ The following table describes the types of steps you can include:
88
89
* - Switch to main
89
90
- Switch focus back to the main frame of the webpage.
90
91
91
-
* - Wait for text present
92
-
- Wait until the text identified in the key-value pair under :guilabel:`Value` appears on the webpage.
93
-
94
-
* - Wait for text present
95
-
- Wait until the text identified in the key-value pair under :guilabel:`Value` appears on the webpage.
96
-
97
-
* - Wait for text not present
98
-
- Wait until the text identified in the key-value pair under :guilabel:`Value` is not present on the webpage.
99
-
100
-
* - Wait for element present
101
-
- Wait until the element you identify under :guilabel:`Selector` is present on the webpage.
102
-
103
-
* - Wait for element not present
104
-
- Wait until the element you identify under :guilabel:`Selector` is not present on the webpage.
105
-
106
-
* - Wait for element visible
107
-
- Wait until the element you identify under :guilabel:`Selector` is visible on the webpage.
92
+
* - Wait
93
+
- Wait a certain number of minutes. See, :ref:`configurable-wait-times`.
108
94
109
-
* - Wait for element not visible
110
-
- Wait until the element you identify under :guilabel:`Selector` is not visible on the webpage.
0 commit comments