---
title: "Configuration"
source: OpenTelemetry Documentation
source_url: https://github.com/open-telemetry/opentelemetry.io
licence: CC-BY-4.0
domain: engineering
subdomain: opentelemetry-docs
date_added: 2026-04-25
---

You can configure the OpenTelemetry Collector to suit your observability needs.
Before you learn how Collector configuration works, familiarize yourself with
the following content:

- [Data collection concepts][dcc], to understand the repositories applicable to
  the OpenTelemetry Collector.
- [Security guidance for end users](/docs/security/config-best-practices/)
- [Security guidance for component developers](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md)

## Location {#location}

By default, the Collector configuration is located in
`/etc/<otel-directory>/config.yaml`, where `<otel-directory>` can be `otelcol`,
`otelcol-contrib`, or another value, depending on the Collector version or the
Collector distribution you're using.

You can provide one or more configurations using the `--config` option. For
example:

```shell
otelcol --config=customconfig.yaml
```

The `--config` flag accepts either a file path or values in the form of a config
URI `"<scheme>:<opaque_data>"`. Currently, the OpenTelemetry Collector supports
the following providers for `scheme`:

- **file** - Reads configuration from a file. E.g. `file:path/to/config.yaml`.
- **env** - Reads configuration from an environment variable. E.g.
  `env:MY_CONFIG_IN_AN_ENVVAR`.
- **yaml** - Reads configuration from a YAML string, with `::` delimiting
subpaths. E.g. `yaml:exporters::debug::verbosity: detailed`.

- **http** - Reads configuration from an HTTP URI. E.g. `http://www.example.com`
- **https** - Reads configuration from an HTTPS URI. E.g.
`https://www.example.com`


You can also provide multiple configurations using multiple files at different
paths. Each file can be a full or partial configuration, and the files can
reference components from each other. If the merger of files does not constitute
a complete configuration, the user receives an error since required components
are not added by default. Pass in multiple file paths at the command line as
follows:

```shell
otelcol --config=file:/path/to/first/file --config=file:/path/to/second/file
```

You can also provide configurations using environment variables, HTTP URIs, or
YAML paths. For example:

```shell
otelcol --config=env:MY_CONFIG_IN_AN_ENVVAR --config=https://server/config.yaml
otelcol --config="yaml:exporters::debug::verbosity: normal"
```

> [!TIP]
>
> When referring to nested keys in YAML paths, make sure to use double colons
> (`::`) to avoid confusion with namespaces that contain dots. For example:
> `receivers::docker_stats::metrics::container.cpu.utilization::enabled: false`.

To validate a configuration file, use the `validate` command. For example:

```shell
otelcol validate --config=customconfig.yaml
```

## Configuration structure {#basics}

The structure of any Collector configuration file consists of four classes of
pipeline components that access telemetry data:

- [Receivers](#receivers)
  
- [Processors](#processors)
  
- [Exporters](#exporters)
  
- [Connectors](#connectors)
  

After each pipeline component is configured you must enable it using the
pipelines within the [service](#service) section of the configuration file.

Besides pipeline components you can also configure [extensions](#extensions),
which provide capabilities that can be added to the Collector, such as
diagnostic tools. Extensions don't require direct access to telemetry data and
are enabled through the [service](#service) section.

<a id="endpoint-0.0.0.0-warning"></a> The following is an example of Collector
configuration with a receiver, a processor, an exporter, and three extensions.

> [!WARNING]
>
> While it is generally preferable to bind endpoints to `localhost` when all
> clients are local, our example configurations use the "unspecified" address
> `0.0.0.0` as a convenience. The Collector currently defaults to `0.0.0.0`, but
> the default will be changed to `localhost` in the near future. For details
> concerning either of these choices as endpoint configuration value, see
> [Safeguards against denial of service attacks][].

[Safeguards against denial of service attacks]:
  https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks

```yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  otlp_grpc:
    endpoint: otelcol:4317
    sending_queue:
      batch:

extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

service:
  extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp_grpc]
    metrics:
      receivers: [otlp]
      exporters: [otlp_grpc]
    logs:
      receivers: [otlp]
      exporters: [otlp_grpc]
```

Note that receivers, processors, exporters and pipelines are defined through
component identifiers following the `type[/name]` format, for example `otlp` or
`otlp/2`. You can define components of a given type more than once as long as
the identifiers are unique. For example:

```yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  otlp/2:
    protocols:
      grpc:
        endpoint: 0.0.0.0:55690

exporters:
  otlp_grpc:
    endpoint: otelcol:4317
    sending_queue:
      batch:
  otlp_grpc/2:
    endpoint: otelcol2:4317
    sending_queue:
      batch:

extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

service:
  extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp_grpc]
    traces/2:
      receivers: [otlp/2]
      exporters: [otlp_grpc/2]
    metrics:
      receivers: [otlp]
      exporters: [otlp_grpc]
    logs:
      receivers: [otlp]
      exporters: [otlp_grpc]
```

The configuration can also include other files, causing the Collector to merge
them in a single in-memory representation of the YAML configuration:

```yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters: ${file:exporters.yaml}

service:
  extensions: []
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [otlp_grpc]
```

With the `exporters.yaml` file being:

```yaml
otlp_grpc:
  endpoint: otelcol.observability.svc.cluster.local:443
```

The final result in memory will be:

```yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  otlp_grpc:
    endpoint: otelcol.observability.svc.cluster.local:443

service:
  extensions: []
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [otlp_grpc]
```

## Receivers  {#receivers}

Receivers collect telemetry from one or more sources. They can be pull or push
based, and may support one or more [data sources](/docs/concepts/signals/).

Receivers are configured in the `receivers` section. Many receivers come with
default settings, so that specifying the name of the receiver is enough to
configure it. If you need to configure a receiver or want to change the default
configuration, you can do so in this section. Any setting you specify overrides
the default values, if present.

> Configuring a receiver does not enable it. Receivers are enabled by adding
> them to the appropriate pipelines within the [service](#service) section.

The Collector requires one or more receivers. The following example shows
various receivers in the same configuration file:

```yaml
receivers:
  # Data sources: logs
  fluentforward:
    endpoint: 0.0.0.0:8006

  # Data sources: metrics
  hostmetrics:
    scrapers:
      cpu:
      disk:
      filesystem:
      load:
      memory:
      network:
      process:
      processes:
      paging:

  # Data sources: traces
  jaeger:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      thrift_binary:
      thrift_compact:
      thrift_http:

  # Data sources: traces, metrics, logs
  kafka:
    protocol_version: 2.0.0

  # Data sources: traces, metrics
  opencensus:

  # Data sources: traces, metrics, logs
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        tls:
          cert_file: cert.pem
          key_file: cert-key.pem
      http:
        endpoint: 0.0.0.0:4318

  # Data sources: metrics
  prometheus:
    config:
      scrape_configs:
        - job_name: otel-collector
          scrape_interval: 5s
          static_configs:
            - targets: [localhost:8888]

  # Data sources: traces
  zipkin:
```

> For detailed receiver configuration, see the
> [receiver README](https://github.com/open-telemetry/opentelemetry-collector/blob/main/receiver/README.md).

## Processors  {#processors}

Processors take the data collected by receivers and modify or transform it
before sending it to the exporters. Data processing happens according to rules
or settings defined for each processor, which might include filtering, dropping,
renaming, or recalculating telemetry, among other operations. The order of the
processors in a pipeline determines the order of the processing operations that
the Collector applies to the signal.

Processors are optional, although some
[are recommended](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor#recommended-processors).

You can configure processors using the `processors` section of the Collector
configuration file. Any setting you specify overrides the default values, if
present.

> Configuring a processor does not enable it. Processors are enabled by adding
> them to the appropriate pipelines within the [service](#service) section.

The following example shows several default processors in the same configuration
file. You can find the full list of processors by combining the list from
[opentelemetry-collector-contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor)
and the list from
[opentelemetry-collector](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor).

```yaml
processors:
  # Data sources: traces
  attributes:
    actions:
      - key: environment
        value: production
        action: insert
      - key: db.statement
        action: delete
      - key: email
        action: hash

  # Data sources: traces, metrics, logs
  filter:
    error_mode: ignore
    traces:
      span:
        - 'attributes["container.name"] == "app_container_1"'
        - 'resource.attributes["host.name"] == "localhost"'
        - 'name == "app_3"'
      spanevent:
        - 'attributes["grpc"] == true'
        - 'IsMatch(name, ".*grpc.*")'
    metrics:
      metric:
        - 'name == "my.metric" and resource.attributes["my_label"] == "abc123"'
        - 'type == METRIC_DATA_TYPE_HISTOGRAM'
      datapoint:
        - 'metric.type == METRIC_DATA_TYPE_SUMMARY'
        - 'resource.attributes["service.name"] == "my_service_name"'
    logs:
      log_record:
        - 'IsMatch(body, ".*password.*")'
        - 'severity_number < SEVERITY_NUMBER_WARN'

  # Data sources: traces, metrics, logs
  memory_limiter:
    check_interval: 5s
    limit_mib: 4000
    spike_limit_mib: 500

  # Data sources: traces
  resource:
    attributes:
      - key: cloud.zone
        value: zone-1
        action: upsert
      - key: k8s.cluster.name
        from_attribute: k8s-cluster
        action: insert
      - key: redundant-attribute
        action: delete

  # Data sources: traces
  probabilistic_sampler:
    hash_seed: 22
    sampling_percentage: 15

  # Data sources: traces
  span:
    name:
      to_attributes:
        rules:
          - ^\/api\/v1\/document\/(?P<documentId>.*)\/update$
      from_attributes: [db.svc, operation]
      separator: '::'
```

> For detailed processor configuration, see the
> [processor README](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/README.md).

## Exporters  {#exporters}

Exporters send data to one or more backends or destinations. Exporters can be
pull or push based, and may support one or more
[data sources](/docs/concepts/signals/).

Each key within the `exporters` section defines an exporter instance, The key
follows the `type/name` format, where `type` specifies the exporter type (e.g.,
`otlp`, `kafka`, `prometheus`), and `name` (optional) can be appended to provide
a unique name for multiple instance of the same type.

Most exporters require configuration to specify at least the destination, as
well as security settings, like authentication tokens or TLS certificates. Any
setting you specify overrides the default values, if present.

> Configuring an exporter does not enable it. Exporters are enabled by adding
> them to the appropriate pipelines within the [service](#service) section.

The Collector requires one or more exporters. The following example shows
various exporters in the same configuration file:

```yaml
exporters:
  # Data sources: traces, metrics, logs
  file:
    path: ./filename.json

  # Data sources: traces
  otlp_grpc/jaeger:
    endpoint: jaeger-server:4317
    tls:
      cert_file: cert.pem
      key_file: cert-key.pem

  # Data sources: traces, metrics, logs
  kafka:
    protocol_version: 2.0.0

  # Data sources: traces, metrics, logs
  # NOTE: Prior to v0.86.0 use `logging` instead of `debug`
  debug:
    verbosity: detailed

  # Data sources: traces, metrics
  opencensus:
    endpoint: otelcol2:55678

  # Data sources: traces, metrics, logs
  otlp_grpc:
    endpoint: otelcol2:4317
    tls:
      cert_file: cert.pem
      key_file: cert-key.pem

  # Data sources: traces, metrics
  otlp_http:
    endpoint: https://otlp.example.com:4318

  # Data sources: metrics
  prometheus:
    endpoint: 0.0.0.0:8889
    namespace: default

  # Data sources: metrics
  prometheusremotewrite:
    endpoint: http://prometheus.example.com:9411/api/prom/push
    # When using the official Prometheus (running via Docker)
    # endpoint: 'http://prometheus:9090/api/v1/write', add:
    # tls:
    #   insecure: true

  # Data sources: traces
  zipkin:
    endpoint: http://zipkin.example.com:9411/api/v2/spans
```

Notice that some exporters require x.509 certificates in order to establish
secure connections, as described in
[setting up certificates](#setting-up-certificates).

> For more information on exporter configuration, see the
> [exporter README.md](https://github.com/open-telemetry/opentelemetry-collector/blob/main/exporter/README.md).

## Connectors  {#connectors}

Connectors join two pipelines, acting as both exporter and receiver. A connector
consumes data as an exporter at the end of one pipeline and emits data as a
receiver at the beginning of another pipeline. The data consumed and emitted may
be of the same type or of different data types. You can use connectors to
summarize consumed data, replicate it, or route it.

You can configure one or more connectors using the `connectors` section of the
Collector configuration file. By default, no connectors are configured. Each
type of connector is designed to work with one or more pairs of data types and
may only be used to connect pipelines accordingly.

> Configuring a connector doesn't enable it. Connectors are enabled through
> pipelines within the [service](#service) section.

The following example shows the `count` connector and how it's configured in the
`pipelines` section. Notice that the connector acts as an exporter for traces
and as a receiver for metrics, connecting both pipelines:

```yaml
receivers:
  foo:

exporters:
  bar:

connectors:
  count:
    spanevents:
      my.prod.event.count:
        description: The number of span events from my prod environment.
        conditions:
          - 'attributes["env"] == "prod"'
          - 'name == "prodevent"'

service:
  pipelines:
    traces:
      receivers: [foo]
      exporters: [count]
    metrics:
      receivers: [count]
      exporters: [bar]
```

> For detailed connector configuration, see the
> [connector README](https://github.com/open-telemetry/opentelemetry-collector/blob/main/connector/README.md).

## Extensions  {#extensions}

Extensions are optional components that expand the capabilities of the Collector
to accomplish tasks not directly involved with processing telemetry data. For
example, you can add extensions for Collector health monitoring, service
discovery, or data forwarding, among others.

You can configure extensions through the `extensions` section of the Collector
configuration file. Most extensions come with default settings, so you can
configure them just by specifying the name of the extension. Any setting you
specify overrides the default values, if present.

> Configuring an extension doesn't enable it. Extensions are enabled within the
> [service](#service) section.

By default, no extensions are configured. The following example shows several
extensions configured in the same file:

```yaml
extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679
```

> For detailed extension configuration, see the
> [extension README](https://github.com/open-telemetry/opentelemetry-collector/blob/main/extension/README.md).

## Service section {#service}

The `service` section is used to configure what components are enabled in the
Collector based on the configuration found in the receivers, processors,
exporters, and extensions sections. If a component is configured, but not
defined within the `service` section, then it's not enabled.

The service section consists of three subsections:

- Extensions
- Pipelines
- Telemetry

### Extensions {#service-extensions}

The `extensions` subsection consists of a list of desired extensions to be
enabled. For example:

```yaml
service:
  extensions: [health_check, pprof, zpages]
```

### Pipelines

The `pipelines` subsection is where the pipelines are configured, which can be
of the following types:

- `traces` collect and processes trace data.
- `metrics` collect and processes metric data.
- `logs` collect and processes log data.

A pipeline consists of a set of receivers, processors and exporters. Before
including a receiver, processor, or exporter in a pipeline, make sure to define
its configuration in the appropriate section.

You can use the same receiver, processor, or exporter in more than one pipeline.
When a processor is referenced in multiple pipelines, each pipeline gets a
separate instance of the processor.

The following is an example of pipeline configuration. Note that the order of
processors dictates the order in which data is processed:

```yaml
service:
  pipelines:
    metrics:
      receivers: [opencensus, prometheus]
      exporters: [opencensus, prometheus]
    traces:
      receivers: [opencensus, jaeger]
      processors: [memory_limiter]
      exporters: [opencensus, zipkin]
```

As with components, use the `type[/name]` syntax to create additional pipelines
for a given type. Here is an example extending the previous configuration:

```yaml
service:
  pipelines:
    # ...
    traces:
      # ...
    traces/2:
      receivers: [opencensus]
      exporters: [zipkin]
```

### Telemetry

The `telemetry` config section is where you can set up observability for the
Collector itself. It consists of two subsections: `logs` and `metrics`. To learn
how to configure these signals, see
[Activate internal telemetry in the Collector](/docs/collector/internal-telemetry#activate-internal-telemetry-in-the-collector).

## Other Information

### Environment variables

The use and expansion of environment variables is supported in the Collector
configuration. For example to use the values stored on the `DB_KEY` and
`OPERATION` environment variables you can write the following:

```yaml
processors:
  attributes/example:
    actions:
      - key: ${env:DB_KEY}
        action: ${env:OPERATION}
```

You can pass defaults to an environment variable using the bash syntax:
`${env:DB_KEY:-some-default-var}`

```yaml
processors:
  attributes/example:
    actions:
      - key: ${env:DB_KEY:-mydefault}
        action: ${env:OPERATION:-}
```

Use `$$` to indicate a literal `$`. For example, representing
`$DataVisualization` would look like the following:

```yaml
exporters:
  prometheus:
    endpoint: prometheus:8889
    namespace: $$DataVisualization
```

### Proxy support

Exporters that use the [`net/http`](https://pkg.go.dev/net/http) package respect
the following proxy environment variables:

- `HTTP_PROXY`: Address of the HTTP proxy
- `HTTPS_PROXY`: Address of the HTTPS proxy
- `NO_PROXY`: Addresses that must not use the proxy

If set at Collector start time, exporters, regardless of the protocol, proxy
traffic or bypass proxy traffic as defined by these environment variables.

### Authentication

Most receivers exposing an HTTP or gRPC port can be protected using the
Collector's authentication mechanism. Similarly, most exporters using HTTP or
gRPC clients can add authentication to outgoing requests.

The authentication mechanism in the Collector uses the extensions mechanism,
allowing for custom authenticators to be plugged into Collector distributions.
Each authentication extension has two possible usages:

- As client authenticator for exporters, adding auth data to outgoing requests
- As server authenticator for receivers, authenticating incoming connections.

For a list of known authenticators, see the
[Registry](/ecosystem/registry/?s=authenticator&component=extension). If you're
interested in developing a custom authenticator, see
[Building an authenticator extension](/docs/collector/extend/custom-component/extension/authenticator).

To add a server authenticator to a receiver in the Collector, follow these
steps:

1. Add the authenticator extension and its configuration under `.extensions`.
2. Add a reference to the authenticator to `.services.extensions`, so that it's
   loaded by the Collector.
3. Add a reference to the authenticator under
   `.receivers.<your-receiver>.<http-or-grpc-config>.auth`.

The following example uses the OIDC authenticator on the receiver side, making
this suitable for a remote Collector that receives data from an OpenTelemetry
Collector acting as agent:

```yaml
extensions:
  oidc:
    issuer_url: http://localhost:8080/auth/realms/opentelemetry
    audience: collector

receivers:
  otlp/auth:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        auth:
          authenticator: oidc

processors:

exporters:
  # NOTE: Prior to v0.86.0 use `logging` instead of `debug`.
  debug:

service:
  extensions:
    - oidc
  pipelines:
    traces:
      receivers:
        - otlp/auth
      processors: []
      exporters:
        - debug
```

On the agent side, this is an example that makes the OTLP exporter obtain OIDC
tokens, adding them to every RPC made to a remote Collector:

```yaml
extensions:
  oauth2client:
    client_id: agent
    client_secret: some-secret
    token_url: http://localhost:8080/auth/realms/opentelemetry/protocol/openid-connect/token

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:

exporters:
  otlp_grpc/auth:
    endpoint: remote-collector:4317
    auth:
      authenticator: oauth2client

service:
  extensions:
    - oauth2client
  pipelines:
    traces:
      receivers:
        - otlp
      processors: []
      exporters:
        - otlp_grpc/auth
```

### Configuring certificates {#setting-up-certificates}

In a production environment, use TLS certificates for secure communication or
mTLS for mutual authentication. Follow these steps to generate self-signed
certificates as in this example. You might want to use your current cert
provisioning procedures to procure a certificate for production usage.

Install [`cfssl`](https://github.com/cloudflare/cfssl) and create the following
`csr.json` file:

```json
{
  "hosts": ["localhost", "127.0.0.1"],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "O": "OpenTelemetry Example"
    }
  ]
}
```

Then run the following commands:

```sh
cfssl genkey -initca csr.json | cfssljson -bare ca
cfssl gencert -ca ca.pem -ca-key ca-key.pem csr.json | cfssljson -bare cert
```

This creates two certificates:

- An "OpenTelemetry Example" Certificate Authority (CA) in `ca.pem`, with the
  associated key in `ca-key.pem`
- A client certificate in `cert.pem`, signed by the OpenTelemetry Example CA,
  with the associated key in `cert-key.pem`.

#### Using certificates in the Collector

Once you have the certificates, configure the Collector to use them.

##### TLS configuration for receivers (server-side)

Configure TLS on a receiver to encrypt incoming connections. Use `cert_file` and
`key_file` to specify the server certificate:

```yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        tls:
          cert_file: /path/to/cert.pem
          key_file: /path/to/cert-key.pem
      http:
        endpoint: 0.0.0.0:4318
        tls:
          cert_file: /path/to/cert.pem
          key_file: /path/to/cert-key.pem
```

##### TLS configuration for exporters (client-side)

Configure TLS on an exporter to encrypt outgoing connections. Use `ca_file` to
verify the server's certificate:

```yaml
exporters:
  otlp_grpc:
    endpoint: otelcol2:4317
    tls:
      ca_file: /path/to/ca.pem
```

If you also need to present a client certificate to the server:

```yaml
exporters:
  otlp_grpc:
    endpoint: otelcol2:4317
    tls:
      ca_file: /path/to/ca.pem
      cert_file: /path/to/cert.pem
      key_file: /path/to/cert-key.pem
```

##### mTLS configuration (mutual TLS)

For mTLS, both the receiver and the exporter verify each other's certificates.
On the receiver, add `client_ca_file` to verify client certificates:

```yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        tls:
          cert_file: /path/to/server-cert.pem
          key_file: /path/to/server-key.pem
          client_ca_file: /path/to/ca.pem
```

On the exporter, provide both the CA to verify the server and the client
certificate:

```yaml
exporters:
  otlp_grpc:
    endpoint: remote-collector:4317
    tls:
      ca_file: /path/to/ca.pem
      cert_file: /path/to/client-cert.pem
      key_file: /path/to/client-key.pem
```

##### Common TLS settings

The following settings are available for TLS configuration:

| Setting                | Description                                               |
| ---------------------- | --------------------------------------------------------- |
| `ca_file`              | Path to the CA certificate to verify the peer certificate |
| `cert_file`            | Path to the TLS certificate                               |
| `key_file`             | Path to the TLS private key                               |
| `client_ca_file`       | Path to the CA certificate to verify client certificates  |
| `insecure`             | Disable TLS verification (not recommended for production) |
| `insecure_skip_verify` | Skip server certificate verification (not recommended)    |
| `min_version`          | Minimum TLS version (for example, `1.2` or `1.3`)         |
| `max_version`          | Maximum TLS version                                       |
| `reload_interval`      | Duration after which the certificate is reloaded          |


> For more details on TLS configuration options, see the
> [configtls documentation](https://github.com/open-telemetry/opentelemetry-collector/blob/v{{% param vers %}}/config/configtls/README.md).


[dcc]: /docs/concepts/components/#collector

## Override settings

You can override Collector settings using the `--set` option. The settings you
define with this method are merged into the final configuration after all
`--config` sources are resolved and merged.

The following examples show how to override settings inside nested sections:

### Simple property

The `--set` option takes always one key/value pair, and it is used like this:
`--set key=value`. The YAML equivalent of that is:

```yaml
key: value
```

### Complex nested keys

Use two colons (`::`) in the pair's name as key separator to reference nested
map values. For example, `--set outer::inner=value` is translated into this:

```yaml
outer:
  inner: value
```

### Multiple values

To set multiple values specify multiple --set flags, so `--set a=b --set c=d`
becomes:

```yaml
a: b
c: d
```

### Array values

Arrays can be expressed by enclosing values in `[]`. For example,
`--set "key=[a, b, c]"` translates to:

```yaml
key:
  - a
  - b
  - c
```

If you need to represent more complex data structures, the use of YAML is highly
recommended.

> [!CAUTION]
>
> The `--set` option has the following limitations:
>
> 1. Does not support setting a key that contains a dot `.`.
> 2. Does not support setting a key that contains an equal sign `=`.
> 3. The configuration key separator inside the value part of the property is
>    "::". For example `--set "name={a::b: c}"` is equivalent with
>    `--set name::a::b=c`.

## Embedding other configuration providers

One configuration provider can make references to other config providers, like
the following:

```yaml
receivers:
  otlp:
    protocols:
      grpc:

exporters: ${file:otlp-exporter.yaml}

service:
  extensions: []
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [otlp_grpc]
```

## How to check components available in a distribution

Use the sub command build-info. Below is an example:

```bash
otelcol components
```

Sample output:

```yaml
buildinfo:
  command: otelcol
  description: OpenTelemetry Collector
  version: 0.143.0
receivers:
  - otlp
processors:
  - memory_limiter
exporters:
  - otlp_grpc
  - otlp_http
  - debug
extensions:
  - zpages
```

## How to examine the final configuration

> [!CAUTION]
>
> This command is an experimental functionality. Its behavior may change with no
> warning.

Use `print-config` in the default mode (`--mode=redacted`) and
`--feature-gates=otelcol.printInitialConfig`:

```bash
otelcol print-config --config=file:examples/local/otel-config.yaml
```

Note that by default the configuration will only print when it is valid, and
that sensitive information will be redacted. To print a potentially invalid
configuration, use `--validate=false`.

### How to view sensitive fields

Use `print-config` with `--mode=unredacted` and
`--feature-gates=otelcol.printInitialConfig`:

```bash
otelcol print-config --mode=unredacted --config=file:examples/local/otel-config.yaml
```

### How to print the final configuration in JSON format

> [!CAUTION]
>
> This command is an experimental functionality. Its behavior may change with no
> warning.

Use `print-config` with `--format=json` and
`--feature-gates=otelcol.printInitialConfig`. Note that JSON format is
considered unstable.

```bash
otelcol print-config --format=json --config=file:examples/local/otel-config.yaml
```
