Components ๐
The OpenTelemetry Collector is made up of the following components:
Receivers: How to get data in. Receivers can be push or pull based. See Available host and application monitors for the list of receivers.
Processors: What to do with received data.
Exporters: Where to send received data. Exporters can be push or pull based. See Configure OpenTelemetry exporters for the list of exporters.
Extensions: Provide capabilities on top of the primary functionality of the Splunk Distribution of OpenTelemetry Collector.
You can enable these components through pipelines. You can also define multiple instances of components as well as pipelines with a YAML configuration.
The Splunk Distribution of OpenTelemetry Collector offers support for the components described in the following tables.
Note
We are in the process of updating the documentation for each component. You can find additional information for each component in the Splunk Distribution of OpenTelemetry Collector GitHub repository.
Receivers ๐
Name |
Description |
Supported pipeline type |
---|---|---|
|
Runs a TCP server that accepts events through the Fluentd Forward protocol. |
Logs |
Host metrics receiver ( |
Generates metrics about the host system scraped from various sources. Use this receiver when the Collector is deployed as an agent. |
Metrics |
|
Receives trace data in Jaeger format. |
Traces |
Kubernetes Cluster Receiver ( |
Collects cluster-level metrics from the Kubernetes API server. It uses the Kubernetes API to listen for updates. You can use a single instance of this receiver to monitor a cluster. |
Metrics |
Kubelet Stats Receiver ( |
Pulls pod metrics from the API server on a kubelet. |
Metrics |
|
Receives data through gRPC or HTTP using OTLP format. |
Metrics, logs, traces |
|
Instantiates other receivers at runtime based on whether observed endpoints match a configured rule. To use the receiver creator, you must first configure one or more observer extensions to discover networked endpoints that you might be interested in. |
N/A |
Splunk APM (SAPM) ( |
Builds on the Jaeger proto. Use this exporter to receive traces from other collectors. |
Traces |
|
Accepts metrics and logs in the proto format. |
Metrics, logs |
|
Provides a simple configuration interface to configure the Prometheus receiver to scrape metrics from a single target. |
Metrics |
|
Utilizes the existing Smart Agent monitors as OpenTelemetry Collector metric receivers. |
Metrics |
|
Accepts metrics in the Splunk HEC format. |
Metrics, logs, traces |
|
Receives spans from Zipkin versions 1 and 2. |
Traces |
Processors ๐
Name |
Description |
Supported pipeline type |
---|---|---|
|
Modifies attributes of a span or log record. |
Logs, traces |
|
Accepts spans, metrics, or logs and places them into batches. Batching helps better compress the data and reduce the number of outgoing connections required to transmit the data. This processor supports both size-based and time-based batching. |
Metrics, logs, traces |
|
Reassociates spans, log records, and metric data points to a resource that matches with the specified attributes. As a result, all spans, log records, or metric data points with the same values for the specified attributes are โgroupedโ under the same resource. |
Metrics, logs, traces |
|
Can be configured to include or exclude metrics based on metric name in the case of the |
Metrics |
|
Allows automatic tagging of spans, metrics, and logs with Kubernetes metadata. |
Metrics, logs, traces |
|
Prevents out of memory situations on the Splunk Distribution of OpenTelemetry Collector. |
Metrics, logs, traces |
|
Renames metrics, and adds, renames, or deletes label keys and values. |
Metrics |
|
Provides samples based on hash values determined by trace IDs. |
Traces |
|
Applies changes to resource attributes. Attributes represent actions that can be applied on resources. OpenCensus has defined standard attributes for resources, including services, environments, and hosts. Do not change the host name, as this can cause issues with infrastructure correlation. |
Metrics, logs, traces |
|
Detects resource information from the host, in a format that conforms to the OpenTelemetry resource semantic conventions, and appends or overrides the resource value in telemetry data with this information. |
Metrics, logs, traces |
|
Reads a header from the incoming HTTP request (gRPC or plain HTTP) or reads a resource attribute, and then directs the trace information to specific exporters based on the value read. |
Metrics, logs, traces |
|
Modifies either the span name or attributes of a span based on the span name. |
Traces |
Exporters ๐
Name |
Description |
Supported pipeline type |
---|---|---|
|
Writes pipeline data to a JSON file. The data is written in Protobuf JSON encoding using OpenTelemetry protocol. |
Metrics, logs, traces |
|
Exports data to the console through zap.Logger. This exporter does not send its output to Windows Event Viewer by default. Run the Splunk Distribution of OpenTelemetry Collector directly from the PowerShell terminal to send output to Windows Event Viewer. |
Metrics, logs, traces |
|
Exports data through gRPC using OTLP format. By default, this exporter requires TLS and offers queued retry capabilities. |
Metrics, traces |
|
Exports traces and/or metrics via HTTP using OTLP format. |
Metrics, traces |
|
Builds on the Jaeger proto and adds additional batching on top, which allows the Splunk Distribution of OpenTelemetry Collector to export traces from multiple nodes or services in a single batch. |
Traces |
|
Sends metrics, events, and trace correlation to Infrastructure Monitoring. |
Logs (events), metrics, traces (trace to metric correlation only) |
|
Sends metrics to a Splunk HEC endpoint. |
Metrics, logs, traces |
Extensions ๐
Name |
Description |
---|---|
|
Detects and reports container endpoints discovered through the Docker API. Only containers that are in the state of |
|
Uses the ECS/EC2 API to discover Prometheus scrape targets from all running tasks and filter them based on service names, task definitions, and container labels. If you run the Collector as a sidecar, consider using the ECS resource detector instead of the ECS observer. The ECS resource detector does not have services or EC2 instances because it only queries the local API. |
|
Enables an HTTP URL that can be probed to check the status of the OpenTelemetry Collector. You can use this extension as a liveness or readiness probe on Kubernetes. |
|
Accepts HTTP requests and optionally adds headers to them and forwards them. The RequestURIs of the original requests are preserved by the extension. |
|
Looks at the current host for listening network endpoints. Uses the /proc filesystem and requires the SYS_PTRACE and DAC_READ_SEARCH capabilities so that it can determine what processes own the listening sockets. |
|
Uses the Kubernetes API to discover pods running on the local node. This extension assumes the Splunk Distribution of OpenTelemetry Collector is deployed in Agent mode where it is running on each individual node or host instance. |
|
Enables the golang |
|
Provides a mechanism to specify configuration options that are not specific only to a single instance of the Smart Agent Receiver but are applicable to all instances. This component provides a means of migrating your existing Smart Agent configuration to the Splunk Distribution of OpenTelemetry Collector. |
|
Enables an extension that serves zPages, an HTTP endpoint that provides live data for debugging different components that were properly instrumented for such. |