Skip to content
Open
Show file tree
Hide file tree
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,9 @@ release.

### SDK Configuration

- Clarifies that guidance related to boolean environment variables is not applicable
to other configuration interfaces. ([#4723](https://github.com/open-telemetry/opentelemetry-specification/pull/4723))

### Common

### Supplementary Guidelines
Expand Down
126 changes: 126 additions & 0 deletions specification/configuration/common.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,126 @@
<!--- Hugo front matter used to generate the website version of this page:
title: Common Configuration Specification
linkTitle: Env var
aliases:
- /docs/reference/specification/common
- /docs/specs/otel/common-configuration
--->

# OpenTelemetry Common Configuration Specification

**Status**: [Stable](../document-status.md) except where otherwise specified

<details>
<summary>Table of Contents</summary>

<!-- toc -->

- [Type-specific guidance](#type-specific-guidance)
* [Numeric](#numeric)
+ [Integer](#integer)
+ [Duration](#duration)
+ [Timeout](#timeout)
* [String](#string)
+ [Enum](#enum)

<!-- tocstop -->

</details>

The goal of this specification is to describe common guidance that is applicable
to all OpenTelemetry SDK configuration sources.

Implementations MAY choose to allow configuration via any source in this specification, but are not required to.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"via any source in this specification" What does this refer to? The other configuration interfaces?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It appears that this sentence was adapted from the env var spec:

Implementations MAY choose to allow configuration via the environment variables in this specification, but are not required to. If they do, they SHOULD use the names listed in this document.

In which case, "source" refers to a data type?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any 'configuration source' was the intended meaning. Do you have suggestions on how to reword this to make it clearer?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added 'configuration' to that sentence let me know if that is clearer

If they do, they SHOULD follow the guidance listed in this document.

## Type-specific guidance

### Numeric

Configuration sources accepting numeric values are sub-classified into:

* [Integer](#integer)
* [Duration](#duration)
* [Timeout](#timeout)

The following guidance applies to all numeric types.

> The following paragraph was added after stabilization and the requirements are
> thus qualified as "SHOULD" to allow implementations to avoid breaking changes.
> For new
> implementations, these should be treated as MUST requirements.

For sources accepting a numeric value, if the user provides a value the
implementation cannot parse, or which is outside the valid range for the
configuration item, the implementation SHOULD generate a warning and gracefully
ignore the setting, i.e., treat them as not set. In particular, implementations
SHOULD NOT assign a custom interpretation e.g. to negative values if a negative
value does not naturally apply to a configuration and does not have an
explicitly specified meaning, but treat it like any other invalid value.

For example, a value specifying a buffer size must naturally be non-negative.
Treating a negative value as "buffer everything" would be an example of such a
discouraged custom interpretation. Instead the default buffer size should be
used.

Note that this could make a difference even if the custom interpretation is
identical with the default value, because it might reset a value set from other
configuration sources with the default.

#### Integer

If an implementation chooses to support an integer-valued configuration source,
it SHOULD support non-negative values between 0 and 2³¹ − 1 (inclusive).
Individual SDKs MAY choose to support a larger range of values.

#### Duration

Any value that represents a duration MUST be an integer representing a number of
milliseconds. The value is non-negative - if a negative value is provided, the
implementation MUST generate a warning, gracefully ignore the setting and use
the default value if it is defined.

For example, the value `12000` indicates 12000 milliseconds, i.e., 12 seconds.

#### Timeout

Timeout values are similar to [duration](#duration) values, but are treated as a
separate type because of differences in how they interpret timeout zero values (
see below).

Any value that represents a timeout MUST be an integer representing a number of
milliseconds. The value is non-negative - if a negative value is provided, the
implementation MUST generate a warning, gracefully ignore the setting and use
the default value if it is defined.

For example, the value `12000` indicates 12000 milliseconds, i.e., 12 seconds.

Implementations SHOULD interpret timeout zero values (i.e. `0` indicating 0
milliseconds) as no limit (i.e. infinite). In practice, implementations MAY
treat no limit as "a very long time" and substitute a very large duration (
e.g. the maximum milliseconds representable by a 32-bit integer).

### String

String values are sub-classified into:

* [Enum][].

Normally, string values include notes describing how they are interpreted by
implementations.

#### Enum

Enum values SHOULD be interpreted in a case-insensitive manner.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might not be possible in declarative config. In JSON schema, an enum type is specified as part of the schema (for example). The validation of a config file's adherence to the schema is often done with 3rd party JSON schema tools, and since there is no way to specify a case-insensitive enum in JSON schema, there's (likely) no way for the 3rd party JSON schema tools to ignore case.

Case insensitive enums are also problematic for the programmatic config interface.

Consider moving this back to the env var specific section.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I also move the sentence that says:

When reporting configuration errors, implementations SHOULD display the original
user-provided value to aid debugging.

It seems to be there only because of the case in-sensitiveness and I think it is hard to apply in all contexts (does it mean that if I set a: "foo" I should get a different message than when I set a: 'foo' or a: !!str foo?)


For configuration sources which accept a known value out of a set, i.e., an enum
value, implementations MAY support additional values not listed here.

For sources accepting an enum value, if the user provides a value
the implementation does not recognize, the implementation MUST generate
a warning and gracefully ignore the setting.
When reporting configuration errors, implementations SHOULD display the original
user-provided value to aid debugging.

If a null object (empty, no-op) value is acceptable, then the enum value
representing it MUST be `"none"`.
105 changes: 12 additions & 93 deletions specification/configuration/sdk-environment-variables.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,14 +17,9 @@ aliases:

- [Implementation guidelines](#implementation-guidelines)
- [Parsing empty value](#parsing-empty-value)
- [Configuration types](#configuration-types)
- [Type-specific guidance](#type-specific-guidance)
* [Boolean](#boolean)
* [Numeric](#numeric)
+ [Integer](#integer)
+ [Duration](#duration)
+ [Timeout](#timeout)
* [String](#string)
+ [Enum](#enum)
- [General SDK Configuration](#general-sdk-configuration)
- [Batch Span Processor](#batch-span-processor)
- [Batch LogRecord Processor](#batch-logrecord-processor)
Expand All @@ -46,10 +41,11 @@ aliases:

</details>

The goal of this specification is to unify the environment variable names between different OpenTelemetry implementations.
The goal of this specification is to unify the environment variable names and value parsing between different OpenTelemetry implementations.

Implementations MAY choose to allow configuration via the environment variables in this specification, but are not required to.
If they do, they SHOULD use the names listed in this document.
If they do, they SHOULD use the names and value parsing behavior specified in this document.
They SHOULD also follow the [common configuration specification](common.md).

## Implementation guidelines

Expand All @@ -61,7 +57,7 @@ The environment-based configuration MUST have a direct code configuration equiva

The SDK MUST interpret an empty value of an environment variable the same way as when the variable is unset.

## Configuration types
## Type-specific guidance

### Boolean

Expand All @@ -79,12 +75,6 @@ upgrade.

### Numeric

Variables accepting numeric values are sub-classified into:

* [Integer](#integer)
* [Duration](#duration)
* [Timeout](#timeout)

The following guidance applies to all numeric types.

> The following paragraph was added after stabilization and the requirements are
Expand All @@ -93,79 +83,8 @@ The following guidance applies to all numeric types.
> implementations, these should be treated as MUST requirements.

For variables accepting a numeric value, if the user provides a value the
implementation cannot parse, or which is outside the valid range for the
configuration item, the implementation SHOULD generate a warning and gracefully
ignore the setting, i.e., treat them as not set. In particular, implementations
SHOULD NOT assign a custom interpretation e.g. to negative values if a negative
value does not naturally apply to a configuration and does not have an
explicitly specified meaning, but treat it like any other invalid value.

For example, a value specifying a buffer size must naturally be non-negative.
Treating a negative value as "buffer everything" would be an example of such a
discouraged custom interpretation. Instead the default buffer size should be
used.

Note that this could make a difference even if the custom interpretation is
identical with the default value, because it might reset a value set from other
configuration sources with the default.

#### Integer

If an implementation chooses to support an integer-valued environment variable,
it SHOULD support non-negative values between 0 and 2³¹ − 1 (inclusive).
Individual SDKs MAY choose to support a larger range of values.

#### Duration

Any value that represents a duration MUST be an integer representing a number of
milliseconds. The value is non-negative - if a negative value is provided, the
implementation MUST generate a warning, gracefully ignore the setting and use
the default value if it is defined.

For example, the value `12000` indicates 12000 milliseconds, i.e., 12 seconds.

#### Timeout

Timeout values are similar to [duration](#duration) values, but are treated as a
separate type because of differences in how they interpret timeout zero values (
see below).

Any value that represents a timeout MUST be an integer representing a number of
milliseconds. The value is non-negative - if a negative value is provided, the
implementation MUST generate a warning, gracefully ignore the setting and use
the default value if it is defined.

For example, the value `12000` indicates 12000 milliseconds, i.e., 12 seconds.

Implementations SHOULD interpret timeout zero values (i.e. `0` indicating 0
milliseconds) as no limit (i.e. infinite). In practice, implementations MAY
treat no limit as "a very long time" and substitute a very large duration (
e.g. the maximum milliseconds representable by a 32-bit integer).

### String

String values are sub-classified into:

* [Enum][].

Normally, string values include notes describing how they are interpreted by
implementations.

#### Enum

Enum values SHOULD be interpreted in a case-insensitive manner.

For variables which accept a known value out of a set, i.e., an enum value,
implementations MAY support additional values not listed here.

For variables accepting an enum value, if the user provides a value
the implementation does not recognize, the implementation MUST generate
a warning and gracefully ignore the setting.
When reporting configuration errors, implementations SHOULD display the original
user-provided value to aid debugging.

If a null object (empty, no-op) value is acceptable, then the enum value
representing it MUST be `"none"`.
implementation cannot parse, the implementation SHOULD generate a warning and gracefully
ignore the setting, i.e., treat them as not set.

## General SDK Configuration

Expand Down Expand Up @@ -424,8 +343,8 @@ OTEL_{LANGUAGE}_{FEATURE}

[Boolean]: #boolean
[Float]: #float
[Integer]: #integer
[Duration]: #duration
[Timeout]: #timeout
[String]: #string
[Enum]: #enum
[Integer]: common.md#integer
[Duration]: common.md#duration
[Timeout]: common.md#timeout
[String]: common.md#string
[Enum]: common.md#enum
2 changes: 1 addition & 1 deletion specification/metrics/sdk_exporters/otlp.md
Original file line number Diff line number Diff line change
Expand Up @@ -72,4 +72,4 @@ The recognized (case-insensitive) values for `OTEL_EXPORTER_OTLP_METRICS_DEFAULT

- [OTEP0131 OTLP Exporters Configurable Export Behavior](../../../oteps/metrics/0131-otlp-export-behavior.md)

[Enum]: ../../configuration/sdk-environment-variables.md#enum
[Enum]: ../../configuration/common.md#enum
6 changes: 3 additions & 3 deletions specification/protocol/exporter.md
Original file line number Diff line number Diff line change
Expand Up @@ -217,9 +217,9 @@ MyDistribution/x.y.z OTel-OTLP-Exporter-Python/1.2.3
```

[Boolean]: ../configuration/sdk-environment-variables.md#boolean
[Timeout]: ../configuration/sdk-environment-variables.md#timeout
[String]: ../configuration/sdk-environment-variables.md#string
[Enum]: ../configuration/sdk-environment-variables.md#enum
[Timeout]: ../configuration/common.md#timeout
[String]: ../configuration/common.md#string
[Enum]: ../configuration/common.md#enum

[resource-semconv]: https://github.com/open-telemetry/semantic-conventions/blob/main/docs/resource/README.md#telemetry-sdk
[otlphttp-req]: https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/specification.md#otlphttp-request
Expand Down
Loading