Loggers can be created from LoggerProviders

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.

An identifier for the library that provides the instrumentation for a given Instrumented Library. Instrumented Library and Instrumentation Library may be the same library if it has built-in OpenTelemetry instrumentation.

The inspiration of the OpenTelemetry project is to make every library and application observable out of the box by having them call OpenTelemetry API directly. However, many libraries will not have such integration, and as such there is a need for a separate library which would inject such calls, using mechanisms such as wrapping interfaces, subscribing to library-specific callbacks, or translating existing telemetry into the OpenTelemetry model.

A library that enables OpenTelemetry observability for another library is called an Instrumentation Library.

An instrumentation library should be named to follow any naming conventions of the instrumented library (e.g. middleware for a web framework).

If there is no established name, the recommendation is to prefix packages with "hs-opentelemetry-instrumentation", followed by the instrumented library name itself.

In general, you can initialize the instrumentation library like so:

import qualified Data.Text as T
import Data.Version (showVersion)
import OpenTelemetry.Attributes (emptyAttributes)
import Paths_your_package_name (version)

instrumentationLibrary :: InstrumentationLibrary
instrumentationLibrary = InstrumentationLibrary
  { libraryName = "your_package_name"
  , libraryVersion = T.pack $ showVersion version
  , librarySchemaUrl = T.pack "" -- to specify a URL, refer to this documentation: https://opentelemetry.io/docs/specs/otel/schemas/#schema-url
  , libraryAttributes = emptyAttributes
  }

LogRecords can be created from Loggers. Loggers are uniquely identified by the libraryName, libraryVersion, schemaUrl fields of InstrumentationLibrary. Creating two Loggers with the same identity but different libraryAttributes is a user error.

This is a data type that can represent logs from various sources: application log files, machine generated events, system logs, etc. Specification outlined here. Existing log formats can be unambiguously mapped to this data type. Reverse mapping from this data type is also possible to the extent that the target log format has equivalent capabilities. Uses an IORef under the hood to allow mutability.

This is a typeclass representing LogRecords that can be read from.

A function receiving this as an argument MUST be able to access all the information added to the LogRecord. It MUST also be able to access the Instrumentation Scope and Resource information (implicitly) associated with the LogRecord.

The trace context fields MUST be populated from the resolved Context (either the explicitly passed Context or the current Context) when emitted.

Counts for attributes due to collection limits MUST be available for exporters to report as described in the transformation to non-OTLP formats specification.

This is a typeclass representing LogRecords that can be read from or written to. All ReadWriteLogRecords are ReadableLogRecords.

A function receiving this as an argument MUST additionally be able to modify the following information added to the LogRecord:

• Timestamp
• ObservedTimestamp
• SeverityText
• SeverityNumber
• Body
• Attributes (addition, modification, removal)
• TraceId
• SpanId
• TraceFlags

Arguments that may be set on LogRecord creation. If observedTimestamp is not set, it will default to the current timestamp. If context is not specified it will default to the current context. Refer to the documentation of LogRecord for descriptions of the fields.

An attribute represents user-provided metadata about a span, link, or event.

Any values are used in place of 'Standard Attributes' in logs because third-party logs may not conform to the 'Standard Attribute' format.

Telemetry tools may use this data to support high-cardinality querying, visualization in waterfall diagrams, trace sampling decisions, and more.

Convert a Haskell value to an Any value.

data Foo = Foo

instance ToValue Foo where
  toValue Foo = TextValue Foo

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.