Documentation

Options for creating a LoggerProvider with no resources and default limits.

In effect, logging is a no-op when using this configuration and no-op Processors.

Initialize a new LoggerProvider

You should generally use getGlobalLoggerProvider for most applications.

Overwrite the globally configured LoggerProvider.

Loggers acquired from the previously installed LoggerProviders will continue to use that LoggerProviders settings.

Access the globally configured LoggerProvider. This LoggerProvider is no-op until initialized by the SDK

This method provides a way for provider to do any cleanup required.

This will also trigger shutdowns on all internal processors.

This method provides a way for provider to immediately export all LogRecords that have not yet been exported for all the internal processors.

Emits a LogRecord with properties specified by the passed in Logger and LogRecordArguments. If observedTimestamp is not set in LogRecordArguments, it will default to the current timestamp. If context is not specified in LogRecordArguments it will default to the current context.

The emitted LogRecord will be passed to any LogRecordProcessors registered on the LoggerProvider that created the Logger.

Add an attribute to a LogRecord.

This is not an atomic modification

As an application developer when you need to record an attribute first consult existing semantic conventions for Resources, Spans, and Metrics. If an appropriate name does not exists you will need to come up with a new name. To do that consider a few options:

The name is specific to your company and may be possibly used outside the company as well. To avoid clashes with names introduced by other companies (in a distributed system that uses applications from multiple vendors) it is recommended to prefix the new name by your company’s reverse domain name, e.g. 'com.acme.shopname'.

The name is specific to your application that will be used internally only. If you already have an internal company process that helps you to ensure no name clashes happen then feel free to follow it. Otherwise it is recommended to prefix the attribute name by your application name, provided that the application name is reasonably unique within your organization (e.g. 'myuniquemapapp.longitude' is likely fine). Make sure the application name does not clash with an existing semantic convention namespace.

The name may be generally applicable to applications in the industry. In that case consider submitting a proposal to this specification to add a new name to the semantic conventions, and if necessary also to add a new namespace.

It is recommended to limit names to printable Basic Latin characters (more precisely to 'U+0021' .. 'U+007E' subset of Unicode code points), although the Haskell OpenTelemetry specification DOES provide full Unicode support.

Attribute names that start with 'otel.' are reserved to be defined by OpenTelemetry specification. These are typically used to express OpenTelemetry concepts in formats that don’t have a corresponding concept.

For example, the 'otel.library.name' attribute is used to record the instrumentation library name, which is an OpenTelemetry concept that is natively represented in OTLP, but does not have an equivalent in other telemetry formats and protocols.

Any additions to the 'otel.*' namespace MUST be approved as part of OpenTelemetry specification.

A convenience function related to addAttribute that adds multiple attributes to a LogRecord at the same time.

This function may be slightly more performant than repeatedly calling addAttribute.

This is not an atomic modification

This can be useful for pulling data for attributes and using it to copy / otherwise use the data to further enrich instrumentation.

WARNING: this function should only be used to emit logs from the hs-opentelemetry-api library. DO NOT USE this function in any other context.

WARNING: this function should only be used to emit logs from the hs-opentelemetry-api library. DO NOT USE this function in any other context.