The Splunk distribution of OpenTelemetry Collector provides a binary that can receive, process and export trace, metric and log data. This distribution is supported by Splunk.
The Collector currently supports:
- Splunk APM via the
sapm
exporter. More information available here. - Splunk Infrastructure
Monitoring
via the
signalfx
exporter. More information available here. - Splunk Log Observer via
the
splunk_hec
exporter. - Splunk Cloud or
Splunk
Enterprise via
the
splunk_hec
exporter.
🚧 This project is currently in BETA.
The Collector provides a single binary and two deployment methods:
- Agent: A Collector instance running with the application or on the same host as the application (e.g. binary, sidecar, or daemonset).
- Gateway: One or more Collector instances running as a standalone service (e.g. container or deployment) typically per cluster, datacenter or region.
Use of the Collector running as an agent is only supported for the Splunk Observability Suite at this time. The SignalFx Smart Agent or Splunk Unverisal Forwarder should be used for all other products.
The Collector is supported on and packaged for a variety of platforms including:
- Kubernetes
- Linux
- Windows
- Install script (coming soon!)
- Standalone
You can consult additional use cases in the examples directory.
The distribution offers support for the following components. Support is based on the OpenTelemetry maturity matrix.
Receivers | Processors | Exporters | Extensions |
---|---|---|---|
hostmetrics | attributes | file | healthcheck |
jaeger | batch | logging | httpforwarder |
k8s_cluster | filter | otlp | host_observer |
kubeletstats | k8s_tagger | sapm | k8s_observer |
opencensus | memorylimiter | signalfx | pprof |
otlp | metrictransform | splunkhec | zpages |
receiver_creator | resource | ||
sapm | resourcedetection | ||
signalfx | span | ||
simpleprometheus | |||
splunkhec | |||
zipkin |
Receivers | Processors | Exporters | Extensions |
---|---|---|---|
carbon | |||
collectd | |||
fluentdforward | |||
statsd |
The OpenTelemetry Collector can be scaled up or out as needed. Sizing is based on the amount of data per data source and requires 1 CPU core per:
- Traces: 10,000 spans per second
- Metrics: 20,000 data points per second
If a Collector handles both trace and metric data then both must be accounted for when sizing. For example, 5K spans per second plus 10K data points per second would require 1 CPU core.
The recommendation is to use a ratio of 1 CPU to 2 GB of memory. By default, the Collector is configured to use 512 MB of memory.
The Collector does not persist data to disk so no disk space is required.
For Agent instances, scale up resources as needed. Typically only a single agent runs per application or host so properly sizing the agent is important. Multiple independent agents could be deployed on a given application or host depending on the use-case. For example, a privileged agent could be deployed alongside an unprivileged agent.
For Gateway instances, allocate at least a CPU core per Collector. Note that multiple Collectors can deployed behind a simple round-robin load balancer for availability and performance reasons. Each Collector runs independently, so scale increases linearly with the number of Collectors you deploy.
The recommendation is to configure at least N+1 redundancy, which means a load balancer and a minimum of two Collector instances should be configured initially.
The default configuration automatically scrapes the Collector's own metrics and
sends the data using the signalfx
exporter. A built-in dashboard provides
information about the health and status of Collector instances.
See the Collector troubleshooting documentation. Additional troubleshooting information can be found in the getting started READMEs.