Status: Stable
Table of Contents
Users of OpenTelemetry need a way to disable the API from actually performing any operations. The No-Op OpenTelemetry API implementation (henceforth referred to as the No-Op) provides users with this functionally. It implements the OpenTelemetry API so that no telemetry is produced and computation resources are minimized.
All language implementations of OpenTelemetry MUST provide a No-Op.
The No-Op MUST allow the creation of multiple MeterProviders.
The MeterProviders created by the No-Op needs to hold as small a memory footprint as possible. Therefore, all MeterProviders created MUST NOT hold configuration or operational state.
Since all MeterProviders hold the same empty state, a No-Op MAY provide the same MeterProvider instances to all creation requests.
The No-Op is used by OpenTelemetry users to disable OpenTelemetry computation overhead and eliminate OpenTelemetry related output. For this reason, the MeterProvider MUST NOT return a non-empty error or log any message for any operations it performs.
All operations a MeterProvider provides MUST be safe to be run concurrently.
New Meter instances are always created with a MeterProvider. Therefore, MeterProviders MUST allow for the creation of Meters. All Meters created MUST be an instance of the No-Op Meter.
Since all Meters will hold the same empty state, a MeterProvider MAY return the same Meter instances to all creation requests.
The API specifies multiple parameters that need to be accepted by the creation operation. The MeterProvider MUST accept these parameters. However, the MeterProvider MUST NOT validate any argument it receives.
The Meters created by the No-Op need to hold as small a memory footprint as possible. Therefore, all Meters created MUST NOT hold configuration or operational state.
The Meter MUST NOT return a non-empty error or log any message for any operations it performs.
All operations a Meter provides MUST be safe to be run concurrently.
The No-Op Meter MUST allow for the creation of a Counter instrument.
Since all Counters hold the same empty state, a Meter MAY return the same Counter instance to all creation requests.
The API specifies multiple parameters that need to be accepted by the creation operation. The Meter MUST accept these parameters. However, the Meter MUST NOT validate any argument it receives.
The No-Op Meter MUST allow for the creation of a UpDownCounter instrument.
Since all UpDownCounters hold the same empty state, a Meter MAY return the same UpDownCounter instance to all creation requests.
The API specifies multiple parameters that need to be accepted by the creation operation. The Meter MUST accept these parameters. However, the Meter MUST NOT validate any argument it receives.
The No-Op Meter MUST allow for the creation of a Histogram instrument.
Since all Histograms hold the same empty state, a Meter MAY return the same Histogram instance to all creation requests.
The API specifies multiple parameters that need to be accepted by the creation operation. The Meter MUST accept these parameters. However, the Meter MUST NOT validate any argument it receives.
The No-Op Meter MUST allow for the creation of an Asynchronous Counter instrument.
Since all Asynchronous Counters hold the same empty state, a Meter MAY return the same Asynchronous Counter instance to all creation requests.
The API specifies multiple parameters that need to be accepted by the creation operation. The Meter MUST accept these parameters. However, the Meter MUST NOT validate any argument it receives and it MUST NOT hold any reference to the passed callbacks.
The No-Op Meter MUST allow for the creation of an Asynchronous UpDownCounter instrument.
Since all Asynchronous UpDownCounters hold the same empty state, a Meter MAY return the same Asynchronous UpDownCounter instance to all creation requests.
The API specifies multiple parameters that need to be accepted by the creation operation. The Meter MUST accept these parameters. However, the Meter MUST NOT validate any argument it receives and it MUST NOT hold any reference to the passed callbacks.
The No-Op Meter MUST allow for the creation of an Asynchronous Gauge instrument.
Since all Asynchronous Gauges hold the same empty state, a Meter MAY return the same Asynchronous UpDownCounter instance to all creation requests.
The API specifies multiple parameters that need to be accepted by the creation operation. The Meter MUST accept these parameters. However, the Meter MUST NOT validate any argument it receives and it MUST NOT hold any reference to the passed callbacks.
Instruments are used to make measurements and report telemetry for a system. However, the No-Op is used to disable this production of telemetry. Because of this, all instruments the No-Op provides MUST NOT hold any configuration or operational state including the aggregation of telemetry.
Counters MUST NOT return a non-empty error or log any message for any operations they perform.
All operations a Counter provides MUST be safe to be run concurrently.
The No-Op Counter MUST provide the user an interface to Add that implements the API. It MUST NOT validate or retain any state about the arguments it receives.
UpDownCounters MUST NOT return a non-empty error or log any message for any operations they perform.
All operations an UpDownCounter provides MUST be safe to be run concurrently.
The No-Op UpDownCounter MUST provide the user an interface to Add that implements the API. It MUST NOT validate or retain any state about the arguments it receives.
Histograms MUST NOT return a non-empty error or log any message for any operations they perform.
All operations a Histogram provides MUST be safe to be run concurrently.
The No-Op Histogram MUST provide the user an interface to Record that implements the API. It MUST NOT validate or retain any state about the arguments it receives.
Asynchronous Counters MUST NOT return a non-empty error or log any message for any operations they perform.
All operations an Asynchronous Counter provides MUST be safe to be run concurrently.
The No-Op Asynchronous Counter MUST NOT validate or retain any state about observations made for the instrument.
Asynchronous UpDownCounters MUST NOT return a non-empty error or log any message for any operations they perform.
All operations an Asynchronous UpDownCounter provides MUST be safe to be run concurrently.
The No-Op Asynchronous UpDownCounter MUST NOT validate or retain any state about observations made for the instrument.
Asynchronous Gauges MUST NOT return a non-empty error or log any message for any operations they perform.
All operations an Asynchronous Gauge provides MUST be safe to be run concurrently.
The No-Op Asynchronous Gauge MUST NOT validate or retain any state about observations made for the instrument.