OTLP receiver 🔗
The OTLP receiver allows the Collector to receive data over gRPC or HTTP using the OTLP format. The supported pipelines are traces
, metrics
, and logs
. See Process your data with pipelines for more information.
Read more about the OTLP format at the OTel repo OpenTelemetry Protocol Specification .
Note
For information on the OTLP exporter, see OTLP exporter.
Get started 🔗
Note
This component is included in the default configuration of the Splunk Distribution of the OpenTelemetry Collector.
For details about the default configuration, see Configure the Collector for Kubernetes with Helm, Collector for Linux default configuration, or Collector for Windows default configuration. You can customize your configuration any time as explained in this document.
Follow these steps to configure and activate the component:
Deploy the Splunk Distribution of the OpenTelemetry Collector to your host or container platform. See Get started: Understand and use the Collector.
Configure the OTLP receiver as described in the next section.
Restart the Collector.
Sample configurations 🔗
To activate the OTLP receiver add otlp
to the receivers
section of your collector configuration file, as in the following example configuration:
receivers:
otlp:
protocols:
grpc:
endpoint: "${HOST_LISTEN_INTERFACE}:1234"
http:
endpoint: "${HOST_LISTEN_INTERFACE}:5678"
You can specify the endpoint
, or the host:port
to which the receiver is going to receive data.
endpoint
defaults to0.0.0.0:4317
for gRPCendpoint
defaults to0.0.0.0:4318
for HTTP
Read about valid syntax at gRPC Name Resolution .
Next, add the receiver to the service pipelines section of your configuration file for the data types you want to receive, for example:
service:
pipelines:
traces:
receivers: [otlp]
metrics:
receivers: [otlp]
Advanced configuration 🔗
You can use helper files to provide additional capabilities automatically. For more information see Common configuration options.
Protobuf payloads 🔗
OTLP is implemented over gRPC and HTTP using a Protocol Buffers schema for the payloads.
Protocol Buffers is an agnostic mechanism that serializes structured data. You can define how you want your data to be structured once, then you can use special generated source code to write and read your structured data using a variety of languages.
Learn more at Protocol Buffers documentation .
Work with OTLP/gRPC 🔗
If you use gRPC, after establishing the underlying gRPC transport, the OTLP receiver will start to continoulsy receive requests with telemetry data, and needs to respond to each request. For more information, refer to the official OpenTelemetry documentation at OTLP/gRPC Specification . This includes details on requests, responses, and OTLP/gRPC throttling.
Work with OTLP/HTTP 🔗
If you use HTTP, the Protobuf payloads can be encoded either in binary or JSON format. OTLP/HTTP uses HTTP POST
requests to send telemetry data to the receiver. For more information, refer to the official OpenTelemetry documentation at OTLP/HTTP Specification . This includes details on encoding, requests, responses, and throttling.
The OTLP/HTTP configuration also provides traces_url_path
, metrics_url_path
, and logs_url_path
configuration to allow the URL paths that signal data needs to be sent to be modified per signal type. These default to /v1/traces
, /v1/metrics
, and /v1/logs
respectively.
To write traces with HTTP, POST to [address]/[traces_url_path]
for traces, to [address]/[metrics_url_path]
for metrics, or to [address]/[logs_url_path]
for logs.
Work with the OTLP/HTTP exporter 🔗
When using the otlphttpexporter
peer to communicate with this component, use the traces_endpoint
, metrics_endpoint
, and logs_endpoint
settings in the otlphttpexporter
to set the proper URL to match the address and URL signal path on the otlpreceiver
.
See more at OTLP/HTTP exporter.
Use Cross-origin resource sharing (CORS) 🔗
The HTTP endpoint can also optionally configure CORS under cors:
:
Use
allowed_origins
to specify what origins (or wildcard patterns) to allow requests from.Set
allowed_headers
to allow additional request headers outside of the default safelist.Set
max_age
to instruct browsers to cache responses to preflight requests.
Learn more at https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS.
See the following sample config:
receivers:
otlp:
protocols:
http:
endpoint: "localhost:4318"
cors:
allowed_origins:
- http://test.com
# Origins can have wildcards with *, use * by itself to match any origin.
- https://*.example.com
allowed_headers:
- Example-Header
max_age: 7200
Settings 🔗
The following table shows the configuration options for the OTLP receiver:
Troubleshooting 🔗
If you are a Splunk Observability Cloud customer and are not able to see your data in Splunk Observability Cloud, you can get help in the following ways.
Available to Splunk Observability Cloud customers
Submit a case in the Splunk Support Portal .
Contact Splunk Support .
Available to prospective customers and free trial users
Ask a question and get answers through community support at Splunk Answers .
Join the Splunk #observability user group Slack channel to communicate with customers, partners, and Splunk employees worldwide. To join, see Chat groups in the Get Started with Splunk Community manual.