# OpenTelemetry (OTel) Source

> For the complete documentation index, see [llms.txt](/llms.txt).


Cribl Stream supports receiving trace, metric, and log events from [OTLP](https://opentelemetry.io/docs/specs/otlp/)-compliant senders.

>   Type: **Push**  |  TLS Support: **YES** | Event Breaker Support: **No**
>
{.box .info}


Looking for the OpenTelemetry Source in **Cribl Search**? See [Ingest OpenTelemetry Data into Cribl Search](/search/source-opentelemetry).
## Supported and Unsupported Input Data

The OpenTelemetry (OTel) Source supports receiving:

* Compressed inbound data (with DEFLATE or gzip compression), as well as uncompressed data.
* Telemetry data over either of the transports that the [OpenTelemetry Protocol](https://opentelemetry.io/docs/specs/otlp/) (OTLP) describes: [gRPC](https://opentelemetry.io/docs/specs/otlp/#otlpgrpc) or [HTTP](https://opentelemetry.io/docs/specs/otlp/#otlphttp). OTLP defines Protocol buffer (Protobuf) schemas for its payloads (requests and responses). With the HTTP transport, this Source supports Binary Protobuf and JSON Protobuf encoding.

The Source does not expose an encoding setting. When **Protocol** is `HTTP`, it selects the encoding from the request `Content-Type`:

- `application/x-protobuf`: Binary Protobuf.
- `application/json`: JSON Protobuf. Use this encoding when your sender is configured to emit OTLP as JSON rather than as binary Protobuf.

JSON Protobuf requires **OTLP version** `1.3.1`. If **OTLP version** is `0.10.0`, the Source rejects JSON requests with HTTP `501`. Invalid JSON, malformed OTLP payloads, and unsupported HTTP paths return HTTP `400`. Other unsupported `Content-Type` values return HTTP `501`.

JSON and binary payloads are decoded into the same internal events, so Routes and Pipelines behave the same regardless of encoding.

The OpenTelemetry Project's [Signals](https://opentelemetry.io/docs/concepts/signals/) documentation provides these hierarchical definitions of Cribl Stream's supported trace and metric event types:
- A **trace** tracks the progression of a single request.
  - Each trace is a tree of **spans**.
  - A span object represents the work being done by the individual services, or components, involved in a request as that request flows through a system.
- A **metric** provides aggreggated statistical information.
  - A metric contains individual measurements called **data points**.
- A **log** provides a recording of an event.
  - See the [OTLP Logs Function](/stream/otlp-logs-function/) topic for an explanation of OTLP logs structure.


### Breaking Changes Between OTLP 0.19.0 and 1.3.1 {#otlp-fields}

With version 0.19.0, the OTLP Protobuf spec introduced [breaking changes](https://github.com/open-telemetry/opentelemetry-proto/releases/tag/v0.19.0) in its field names. This means that if you created Routes or Pipelines that work with OTLP version 0.10.0, they may break when you use them with OTLP 1.3.1.

> To use Routes or Pipelines created before Cribl Stream 4.7 with OTLP 1.3.1, you must check their filters and logic for any use of obsolete field names, and modify them accordingly,
{.box .warning}

## Configure an OTel Source

1. On the top bar, select **Products**, and then select **Cribl Stream**. Under **Worker Groups**, select a Worker Group. Next, you have two options:
     - To configure via [QuickConnect](quickconnect), navigate to **Routing** > **QuickConnect** (Stream) or **Collect** (Edge). Select **Add Source** and select the Source you want from the list, choosing either **Select Existing** or **Add New**.
     - To configure via the [Routes](routes), select **Data** > **Sources** (Stream) or **More** > **Sources** (Edge). Select the Source you want. Next, select **Add Source**.

1. In the **New Source** modal, configure the following under **General Settings**:
    - **Input ID**: Unique ID for this Source. For example, `OTel042`.
    - **Description**: Optionally, enter a description.
    - **OTLP version**: The drop-down offers `0.10.0` and `1.3.1` (default).
    - **Protocol**: Use the drop-down to choose the protocol matching the data you will ingest: `gRPC` (default), or `HTTP`.
    - **Address**: Enter the hostname/IP to listen on. Defaults to `0.0.0.0` (all addresses, IPv4 format).
    - **Port**: By default, OTel applications send output to port `4317` when using the gRPC protocol, and port `4318` when using HTTP. This setting defaults to `4317` - you must change it if you set **Protocol** (below) to `HTTP`, or you want Cribl Stream to collect data from an OTel application that is using a different port.

       > Port `4318` is not available on Cribl-managed Worker Groups in Cribl.Cloud.
       {.box .cloud}

    - The **Extract spans**, **Extract metrics**, and **Extract logs** settings are specific to the OpenTelemetry Source. By default, these options are toggled off, allowing Cribl Stream to act as a pass-through that generates a single event for each incoming OTel payload. This is useful when you want to forward complete OTel events to downstream systems, such as persistent storage, without breaking them apart. You can enable these settings to extract and process individual records from within OTel events:
       - **Extract spans**: Generates an individual event for each span contained in an OTLP traces export payload. A single OTLP traces payload (batch) typically includes many spans.
       - **Extract metrics**: Generates an individual event for each data point in a metric event. OTel metrics often contain multiple data points per event.
       - **Extract logs**: Available only when **OTLP version** is set to `1.3.1`. Generates an individual event for each log record. Cribl recommends enabling this option to simplify log transformation and manipulation.
    - **Tags**: Optionally, add tags to help filter and group Sources within Cribl Stream's UI. Tags are not included in the event data. Separate tag names using a tab or hard return.

1. Optionally, you can adjust the [Authentication](#auth), [TLS](#tls), [Persistent Queue Settings](#pq), [Processing](#processing), and [Advanced](#advanced-settings) settings, or [Connected Destinations](#connected) outlined in the following sections.

1. Select **Save**, then **Commit & Deploy**.

### Authentication {#auth}

Under **Auth methods**, select **Add Method** for each authentication method you want to configure, and then choose an **Authentication type**. If you don't configure any methods, the Source permits unauthenticated access.

- **Token**: Enter the bearer token that senders must include when connecting to this Source.

- **Token (secret)**: Provide a bearer token referenced by a secret. Select a stored text secret in the resulting **Token secret** drop-down, or select **Create** to configure a new secret.

- **Basic**: Displays **Username** and **Password** fields for you to enter HTTP Basic authentication credentials.

- **Basic (credentials secret)**: Provide username and password credentials referenced by a secret. Select a stored text secret in the resulting **Credentials secret** drop-down, or select **Create** to configure a new secret.

- **OAuth**: Validate bearer JSON Web Tokens (JWTs) against signing keys from a JSON Web Key Set (JWKS) endpoint. Configure these settings:
  - **Issuer**: Expected token issuer. The value must match the JWT's `iss` claim.
  - **JWKS URI**: URL of the JWKS endpoint from which the Source retrieves public signing keys.
  - **Audience**: Expected token audience. The value must match the JWT's `aud` claim.
  - **Required scopes**: Optionally, add scopes that the JWT must grant. The Source checks the token's `scope` or `scp` claim.

> On Cribl-managed Worker Groups in Cribl.Cloud, the **JWKS URI** host must be publicly reachable. The Source rejects a JWKS endpoint that resolves to a private or link-local address.
{.box .cloud}

#### Configure Sender Credentials {#client-credentials}

When configuring an upstream OTLP sender (such as the OpenTelemetry Collector, Azure Monitor, or an application SDK), map your **Authentication** selection to the key-value pair the sender asks for. When **General Settings** > **Protocol** is set to `HTTP`, senders include credentials in HTTP request headers. When **Protocol** is set to `gRPC`, senders include credentials as [gRPC Metadata](https://grpc.io/docs/guides/metadata/) entries. Metadata entries are key-value pairs that work similarly to HTTP headers.

| **Authentication** | **Key** | **Value** |
| --- | --- | --- |
| No authentication methods configured | N/A | N/A |
| **Token** or **Token (secret)** | `authorization` | `Bearer <your-configured-token>` |
| **Basic** or **Basic (credentials secret)** | `authorization` | `Basic <base64-encoded-username:password>` |
| **OAuth** | `authorization` | `Bearer <JWT>` |

Use lowercase `authorization` for the key. The key and value are the same for both transports.

#### Multiple Authentication Methods {#multiple-auth}

You can configure more than one authentication method on a single Source, in any combination. For example, you can accept a static auth token from a legacy sender while requiring OAuth from the rest. The Source accepts a request whose credentials match any enabled method, so different senders can send data to the same Source using different credentials.

Select **Add Method** for each sender that should authenticate to this Source, or select **Clone** on an existing method to copy its settings. Each method has an **Enable** toggle, so you can retire a credential without deleting its configuration.

Configure multiple methods when you want to:

- Receive OTLP data from multiple applications, services, projects, or tenants through one Source.
- Assign different credentials to each sender.
- Add sender-specific metadata that you can use later in Routes or Pipelines.

#### Authentication Fields {#auth-fields}

Use **Fields** on an authentication method to associate that method with sender metadata, such as an application, project, environment, or tenant.

This is useful when multiple senders share one OTel Source and you want to:

- Route events differently by sender.
- Apply different Pipelines based on the sending app or project.
- Search or analyze OTel data by sender-specific metadata.

For example, you might give one method a Field such as `app=checkout` and another a Field such as `app=payments`.

Each Field is a name/value pair. When a sender authenticates with a given method, Cribl Stream adds that method's Fields to the resulting events.

### TLS Settings (Server Side) {#tls}

> In OTel terminology, your Cribl Stream OTel Source will receive OTel data from a **Collector** running on a local **agent**. In Cribl Stream's terminology, the Collector is the **client** and the OTel Source is the **server**. This is why this Source's UI identifies the Source's TLS Settings as "server-side."
>
> For more about this client-server relationship, see the [TLS Configuration Example](#tls-example) below.
>
> On Cribl.Cloud, you can [enable TLS using Cribl-provided certficates](securing-sources-destinations-tls#enable-tls-sources-cloud) if desired.
>
{.box .success}

**Enabled**: Defaults to toggled off.

#### Server Certificate

Select a certificate from the store to auto-fill the paths below, or enter them manually.

**Certificate**: Name of the predefined certificate.

**Certificate path**: Server path containing certificates (in PEM format) to use. Path can reference `$ENV_VARS`.

**Private key path**: Server path containing the private key (in PEM format) to use. Path can reference `$ENV_VARS`.

**Passphrase**: Passphrase to use to decrypt private key.

#### Mutual Authentication (mTLS)

**Authenticate client (mutual auth)**: Require clients to present their certificates. Used to perform mutual authentication using SSL certs. Default is toggled off. When toggled on:

- **Trusted client CA path**: Server path containing CA certificates (in PEM format) to use when verifying client certificates. Path can reference `$ENV_VARS`. The certificate(s) to trust as the chain root when verifying the client's identity. This is typically the root CA that anchors the client's certificate chain. If you disable **Authenticate client (mutual auth)**, this field is hidden in the UI, but any value already saved remains on disk.

- **Validate client certificates**: Reject certificates that are not authorized by a CA in the **Trusted client CA path**, or by another trusted CA (for example, the system's CA). Default is toggled on.

- **Common name**: Regex that a peer certificate's subject attribute must match in order to connect. Defaults to `.*`. Matches on the substring after `CN=`. As needed, escape regex tokens to match literal characters. (For example, to match the subject `CN=worker.cribl.local`, you would enter: `worker\.cribl\.local`.) The CN and SAN fields in the client certificate are matched against this regex. Clients are rejected unless at least one match is found. If the subject attribute contains Subject Alternative Name (SAN) entries, the Source checks the regex against all of those but ignores the Common Name (CN) entry (if any). If the certificate has no SAN extension, the Source checks the regex against the single name in the CN.

#### TLS Version

Reject clients using TLS versions below or above these thresholds.

**Minimum TLS version**: Optionally, select the minimum TLS version to accept from connections. Selecting `TLSv1` or `TLSv1.1` shows a deprecation warning.

**Maximum TLS version**: Optionally, select the maximum TLS version to accept from connections.

### Persistent Queue Settings {#pq}

In the **Persistent Queue Settings** tab, you can optionally specify persistent queue storage, using the following controls. Persistent queue buffers and preserves incoming events when a downstream Destination has an outage or experiences backpressure.

Before enabling persistent queue, learn more about persistent queue behavior and how to optimize it with your system:

- [About Persistent Queues](persistent-queues)
- [Optimize Source Persistent Queues](persistent-queues-sources)

> On Cribl-managed [Cloud](deploy-cloud) Workers (with an [Enterprise plan](cloud-enterprise)), this tab exposes only the **Enable persistent queue** toggle. If enabled, PQ is automatically configured in `Always On` mode, with a maximum queue size of 1 GB disk space allocated per PQ-enabled Source, per Worker Process.
>
> The 1 GB limit is on uncompressed inbound data, and the queue does not perform any compression. This limit is not configurable. For configurable queue size, compression, mode, and other options below, use a [hybrid Group](cloud-enterprise#hybrid).
>
> All other settings described in this section apply to on-prem and hybrid deployments only.
>
{.box .cloud}

**Enable persistent queue**: Default is toggled off. When toggled on:

**Mode**: Select a condition for engaging persistent queues.

- `Always On`: This default option will always write events to the persistent queue, before forwarding them to the Cribl Stream data processing engine.
- `Smart`: This option will engage PQ only when the Source detects backpressure from the Cribl Stream data processing engine. `Smart` mode only engages when necessary, such as when a downstream Destination becomes blocked *and* the **Buffer size limit** reaches its limit. When persistent queue is set to `Smart` mode, Cribl Stream attempts to flush the queue when every new event arrives. The only time events stay in the buffer is when a downstream Destination becomes blocked.

> **Deprecation Notice**
>
> To improve data integrity, **Smart** mode is deprecated for Source persistent queue on hybrid and on-prem deployments. In January 2027, affected configurations will automatically migrate to **Always On** mode. Consider updating existing configurations to **Always On** mode prior to the automatic migration date. Before changing the configuration:
>
> - [Monitor](persistent-queues-sources#monitoring) your persistent queue usage so that you can [allocate enough disk space](persistent-queues-sources#queue-disk-space).
> - Before making changes to your persistent queue, remember to [drain the queues](persistent-queues#clear-pq) first to avoid orphaned data.
> - Verify that [data routing and filtering](routes) behaves as expected in a test environment before rolling out the new configuration to production.
>
{.box .warning}

**Buffer size limit (bytes)**: The maximum memory to buffer events before flushing them to persistent queue on disk. Enter a value with a unit suffix. For example: `64KB`, `1MB`, or `10MB`. Spaces between the number and unit are allowed (such as `64 KB`). Units are case-insensitive. Plain byte values (like `65536`) are accepted, but decimals (like `0.5MB`) are not. The valid range is `64KB` to `10MB`. Values outside this range are rounded to the nearest limit. Defaults to `1MB`.

> **Deprecation Notice**
>
>The **Buffer size limit (bytes)** setting replaces the deprecated **Buffer size limit (events)** setting as of version 4.18.0 to provide more predictable memory management. For upgraded Worker Groups and Fleets, the new byte-based limit defaults to `1MB`. Update your configurations to use the byte-based limit to ensure optimal memory stability.
>
{.box .warning}

**Commit frequency**: The number of events to send downstream before committing that Cribl Stream has read them. Defaults to `42`.

**File size limit**: The maximum data volume to store in each queue file before closing it and (optionally) applying the configured **Compression**. Enter a numeral with units of KB, MB, and so on. If not specified, Cribl Stream applies the default `10 MB`. When you save the configuration, **File size limit** must be greater than or equal to **Buffer size limit (bytes)**. Cribl Stream rejects invalid combinations.

**Queue size limit**: The maximum amount of disk space that the queue is allowed to consume on each Worker Process. Once this limit is reached, this Source stops queueing data and applies the **Queue-full behavior**. Required, and defaults to `5` GB. Accepts positive numbers with units of `KB`, `MB`, `GB`, and so on. Can be set as high as `1 TB`, unless you've [configured](group-settings#storage) a different **Worker Process PQ size limit** in Group or Fleet settings.

**Queue file path**: The location for the persistent queue files. Defaults to `$CRIBL_HOME/state/queues`. To this field's specified path, Cribl Stream appends `/<worker-id>/inputs/<input-id>`.

**Compression**: Optional codec to compress the persisted data after a file closes. Defaults to `None`; `Gzip` is also available.

**Queue-full behavior**: Whether to block or drop events when the queue begins to exert backpressure. A queue begins to exert backpressure when the disk is low or at full capacity.

  - **Block** (Default): Does not accept new data until the queue has capacity. When the sender supports backpressure signaling, Cribl Stream returns block signals to the sender.
  - **Drop new data**: Discards incoming events while leaving the contents of the persistent queue unchanged.

> In Cribl Stream 4.1 and newer, the Source persistent queue default **Mode** is `Always on`, to best ensure events' delivery. For details on optimizing this selection, see [Optimize Source Persistent Queues](persistent-queues-sources).
>
> You can optimize Workers' startup connections and CPU load at **Group/Fleet settings** > [Worker Processes](group-settings#processes).
>
{.box .info}

### Processing Settings {#processing}

#### Fields

In this section, you can define new fields or modify existing ones using JavaScript expressions, similar to the [Eval](eval-function) function. 

* The **Field Name** can either be a new field (unique within the event) or an existing field name to modify its value.
* The **Value** is a JavaScript expression (enclosed in quotes or backticks) to compute the field's value (can be a constant). Select this field's advanced mode icon (far right) if you'd like to open a modal where you can work with sample data and iterate on results.

This flexibility means you can:

* Add new fields to enrich the event.
* Modify existing fields by overwriting their values.
* Compute logic or transformations using JavaScript expressions.

#### Pre-Processing

In this section's **Pipeline** drop-down list, you can select a single existing [Pipeline](pipelines) or [Pack](packs) to process data from this input before the data is sent through the Routes.

### Advanced Settings {#advanced-settings}

When **General Settings** > **Protocol** is set to `gRPC`, the UI displays one additional setting:

- **Active connection limit**: Maximum number of active connections allowed per Worker Process. Defaults to `1000`. Set a lower value if connection storms are causing the Source to hang. Set `0` for unlimited connections.

- **Environment**: Optionally, specify a single Git branch on which to enable this configuration. If this field is empty, the config will be enabled everywhere.

When **General Settings** > **Protocol** is set to `HTTP`, the UI displays these additional settings:

- **Health check endpoint**: Toggle on to enable a health check endpoint specific to this Source, `http(s)://<host>:<port>/cribl_health`. A `200` HTTP response code is returned when the Source is healthy. Otherwise, two errors you could receive are:
  - `ECONNRESET` where the Source failed to initialize due to not having listeners on the port.
  - `503` or `Server is busy, max active connections reached` indicate there are too many connections per Worker Process.

- **Active request limit (on-prem only)**: Maximum number of active requests allowed for this Source, per Worker Process. Defaults to `256`. Enter `0` for unlimited.

> Raising this limit can increase throughput by allowing more concurrent data requests, but increases resource usage and load on both your Cribl Stream infrastructure and on downstream Destinations. Before raising this limit, ensure:
>
> - Your Cribl Stream deployment has sufficient capacity to support higher request concurrency, including CPU, memory, or number of Worker Processes.
> - Downstream Destinations are correctly sized and tuned to accept the higher data ingest rate, preventing backpressure. See [Manage Backpressure](manage-backpressure) for more information.
>
> Improper sizing on either side can result in dropped events, delayed processing, or overall system instability.
{.box .warning}

- **Requests-per-socket limit**: The maximum number of requests Cribl Stream should allow on one socket before instructing the client to close the connection. Defaults to `0` (unlimited). See [Balancing Connection Reuse Against Request Distribution](#max-requests-per-socket) below.

- **Socket timeout (seconds)**: How long Cribl Stream should wait before assuming that an inactive socket has timed out. The default `0` value means wait forever.

- **Request timeout (seconds)**: How long to wait for an incoming request to complete before aborting it. The default `0` value means wait indefinitely.

- **Keep-alive timeout (seconds)**: After the last response is sent, Cribl Stream will wait this long for additional data before closing the socket connection. Defaults to `5` seconds; minimum is `1` second; maximum is `600` seconds (10 minutes).

- **IP allowlist regex**: Grants access to requests originating from specific IP addresses that match a defined pattern. Unmatched requests are rejected with a 403 (Forbidden) status code. Defaults to `.*` (allow all).

- **IP denylist regex**: Blocks requests originating from specific IP addresses that match a defined pattern, even if they would be allowed by default. Rejected requests receive a 403 (Forbidden) status code. Defaults to `^$` (allow all).

- **Environment**: Optionally, specify a single Git branch on which to enable this configuration. If this field is empty, the config will be enabled everywhere.

**Cross-Origin Resource Sharing (CORS)** lets a browser send OTLP/HTTP to this Source. CORS is enabled when either **CORS allowed origins** or **CORS allowed headers** is non-empty. Leave both empty to disable CORS. If you set one and leave the other empty, Cribl Stream defaults the empty setting to `*`. **IP allowlist** and **IP denylist** rules are applied before CORS. Requests blocked by those rules do not receive CORS headers.

- **CORS allowed origins**: List the HTTP origins to which Cribl Stream sends CORS response headers. You can enter multiple domains and use wildcards.

- **CORS allowed headers**: List the HTTP headers that Cribl Stream allows in a CORS preflight response. Enter `*` to allow all headers.

- **CORS allowed methods**: List HTTP methods that Cribl Stream allows on CORS preflight responses. Defaults to `OPTIONS` and `POST`.

- **CORS exposed headers**: Optionally list response headers that browsers are allowed to access.

- **CORS include credentials**: Toggle on to include credentials in cross-origin requests. Defaults to toggled off. Per the CORS specification, Cribl Stream does not include credentials when **CORS allowed origins** is set to `*`.

- **CORS max age (seconds)**: Optionally set how long browsers should cache the preflight response.

#### Balancing Connection Reuse Against Request Distribution {#max-requests-per-socket}

**Requests-per-socket limit** allows you to limit the number of HTTP requests an upstream client can send on one network connection. Once the limit is reached, Cribl Stream uses HTTP headers to inform the client that it must establish a new connection to send any more requests. (Specifically, Cribl Stream sets the HTTP `Connection` header to `close`.) After that, if the client disregards what Cribl Stream has asked it to do and tries to send another HTTP request over the existing connection, Cribl Stream will respond with an HTTP status code of `503 Service Unavailable`.

Use this setting to strike a balance between connection reuse by the client, and distribution of requests among one or more Worker Node processes by Cribl Stream:

* When a client sends a sequence of requests on the same connection, that is called connection reuse. Because connection reuse benefits client performance by avoiding the overhead of creating new connections, clients have an incentive to **maximize** connection reuse.

* Meanwhile, a single process on that Worker Node will handle all the requests of a single network connection, for the lifetime of the connection. When receiving a large overall set of data, Cribl Stream performs better when the workload is distributed across multiple Worker Node processes. In that situation, it makes sense to **limit** connection reuse.

There is no one-size-fits-all solution, because of variation in the size of the payload a client sends with a request and in the number of requests a client wants to send in one sequence. Start by estimating how long connections will stay open. To do this, multiply the typical time that requests take to process (based on payload size) times the number of requests the client typically wants to send.

If the result is 60 seconds or longer, set **Requests-per-socket limit** to force the client to create a new connection sooner. This way, more data can be spread over more Worker Node processes within a given unit of time.

For example: Suppose a client tries to send thousands of requests over a very few connections that stay open for hours on end. By setting a relatively low **Requests-per-socket limit**, you can ensure that the same work is done over more, shorter-lived connections distributed between more Worker Node processes, yielding better performance from Cribl Stream.

A final point to consider is that one Cribl Stream Source can receive requests from more than one client, making it more complicated to determine an optimal value for **Requests-per-socket limit**.

### Connected Destinations {#connected}

Select **Send to Routes** to enable conditional routing, filtering, and cloning of this Source's data via the Routing table.

Select **QuickConnect** to send this Source's data to one or more Destinations via independent, direct connections.

## Internal Fields

OTel internal fields are metadata fields added to events processed by the OTel Source. These fields provide essential context about the event's origin and processing details and can be referenced in filters, Routes, and Pipelines to apply specific logic based on the event's metadata. These fields are not included in the final output unless explicitly configured at the Pipeline or Destination stage.

Fields for this Source:

  * `__otlp.version` - The OTLP version used to parse the event. For example, `0.10.0` or `1.3.1`. This helps ensure compatibility with upstream systems and configurations.
  * `__otlp.type` - The type of telemetry data. For example, `logs`, `metrics`, or `traces`. This is crucial for distinguishing between different signal types in Pipelines.
  * `__otlp.extracted` - A boolean flag that denotes whether individual records were extracted from a batch event. If `true`, the event represents an extracted record. This behavior is directly governed by the **Extract spans**, **Extract metrics**, and **Extract logs** general settings of the OTel Source.

## TLS Configuration Example {#tls-example}

Here's a simple example for using TLS to secure the communication between an OpenTelemetry client and your Cribl Stream OTel Source.

1. Choose or generate a certificate and key.
    If you need to generate a certificate/key pair, you can adapt the following OpenSSL command:

    ```shell
    openssl req -nodes -new -x509 -newkey rsa:2048 -keyout myKey.pem -out myCert.pem -days 420
    ```
    This example command will generate both a self-signed cert named `myCert.pem` (certified for 420 days), and an unencrypted, 2048-bit RSA private key named `myKey.pem`.

2. Configure the **TLS Settings (Server Side)**.
    Toggle **Enabled** on. In **Server Certificate**, select a certificate from the **Certificate** dropdown, or select **Create** to create a new certificate. You can also manually enter **Private key path** and **Certificate path**. 
    Leave **Authenticate client (mutual auth)** toggled off.

3. Configure the OTel client.
    See the OTel Collector TLS Configuration Settings [README](https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/configtls/README.md) for an explanation of the relevant settings. The [config file](https://opentelemetry.io/docs/collector/configuration/) might be named `otel-config.yaml`, `otel-local-config.yaml`, or just `config.yaml`, depending on your environment. This YAML file will have an `exporters` section, which you must edit to include an `otlp` sub-section, as follows:
    * Add an `endpoint` whose value is the IP address of either (a) the Cribl Stream Worker Node on which your OTel Source is running, or (b) the IP address of the load balancer for the relevant Worker Group. In the example snippet below, this is the `<Cribl_IP_address>`. Specify the port on which Cribl Stream's OTel Source is listening; port `4317` is the OTLP default for gRPC (`4318` for HTTP).
    * Set `tls` > `insecure` to `false`. This matches your setting **TLS Settings (Server Side)** > **Enabled** to toggled on for the Cribl Stream OTel Source.
    * Set `tls` > `insecure_skip_verify` to `true`. This matches your setting **TLS Settings (Server Side)** > **Authenticate client (mutual auth)** to toggled off for the Cribl Stream OTel Source. Setting `insecure_skip_verify` to `true` is also required if you're using a self-signed certificate.

    Here's how the section you edited should look:

    ```yaml
    exporters:
      otlp:
        endpoint: "https://<Cribl_IP_address>:4317"
        tls:
          insecure: false
          insecure_skip_verify: true
    ```
## Troubleshooting

The Source's configuration modal has helpful tabs for troubleshooting:

**Live Data**: Try capturing [live data](sources#capture-source-data) to see real-time events as they are ingested. On the **Live Data** tab, click **Start Capture** to begin viewing real-time data.

**Logs**: Review and search the logs that provide detailed information about the ingestion process, including any errors or warnings that may have occurred.

You can also view the [Monitoring](monitoring) page that provides a comprehensive overview of data volume and rate, helping you identify ingestion issues. Analyze the graphs showing events and bytes in/out over time.

### Common Issue

When your upstream sender is the [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) and its logs show the error `Exporting failed. Will retry the request after interval`, try increasing the duration specified in **Advanced Settings** > **Keep-alive timeout (seconds)**. Choose a duration that aligns with your OpenTelemetry Collector configuration, such that the OpenTelemetry Collector has enough time to send its events before the keep-alive timeout elapses.