hs-opentelemetry-api
Copyright(c) Ian Duncan 2026
LicenseBSD-3
Stabilityexperimental
Safe HaskellNone
LanguageHaskell2010

OpenTelemetry.Internal.Log.Types

Description

 
Synopsis

UMaybe re-export for consumers of ImmutableLogRecord fields

data UMaybe a Source #

An unboxed optional value. Single-constructor wrapper around an unboxed sum, so {-# UNPACK #-} can flatten it into a parent record.

Since: 0.0.1.0

Constructors

UMaybe (# (# #) | a #) 

Bundled Patterns

pattern UJust :: a -> UMaybe a 
pattern UNothing :: UMaybe a 

umaybe :: b -> (a -> b) -> UMaybe a -> b Source #

Since: 0.0.1.0

toBaseMaybe :: UMaybe a -> Maybe a Source #

Since: 0.0.1.0

data TracingDetails Source #

Optional trace context attached to a log record. Uses a dedicated ADT instead of UMaybe (TraceId, SpanId, TraceFlags) so GHC can unpack all fields flat into the constructor — no intermediate boxed tuple.

Since: 0.4.0.0

data LogRecordExporter Source #

Exports log records to a telemetry backend. Thread-safe: the internal MVar serializes concurrent logRecordExporterExport calls.

Spec: https://opentelemetry.io/docs/specs/otel/logs/sdk/#logrecordexporter

Since: 0.0.1.0

data LogRecordExporterArguments Source #

See LogRecordExporter for documentation

Since: 0.0.1.0

Constructors

LogRecordExporterArguments 

Fields

logRecordExporterExport :: LogRecordExporter -> Vector ReadableLogRecord -> IO ExportResult Source #

Exports a batch of ReadableLogRecords. Protocol exporters that will implement this function are typically expected to serialize and transmit the data to the destination.

Export will never be called concurrently for the same exporter instance. Depending on the implementation the result of the export may be returned to the Processor not in the return value of the call to Export but in a language specific way for signaling completion of an asynchronous task. This means that while an instance of an exporter will never have it Export called concurrently it does not mean that the task of exporting can not be done concurrently. How this is done is outside the scope of this specification. Each implementation MUST document the concurrency characteristics the SDK requires of the exporter.

Export MUST NOT block indefinitely, there MUST be a reasonable upper limit after which the call must time out with an error result (Failure).

Concurrent requests and retry logic is the responsibility of the exporter. The default SDK’s LogRecordProcessors SHOULD NOT implement retry logic, as the required logic is likely to depend heavily on the specific protocol and backend the logs are being sent to. For example, the OpenTelemetry Protocol (OTLP) specification defines logic for both sending concurrent requests and retrying requests.

Result: Success - The batch has been successfully exported. For protocol exporters this typically means that the data is sent over the wire and delivered to the destination server. Failure - exporting failed. The batch must be dropped. For example, this can happen when the batch contains bad data and cannot be serialized.

Since: 0.0.1.0

logRecordExporterForceFlush :: LogRecordExporter -> IO FlushResult Source #

This is a hint to ensure that the export of any ReadableLogRecords the exporter has received prior to the call to ForceFlush SHOULD be completed as soon as possible, preferably before returning from this method.

ForceFlush SHOULD provide a way to let the caller know whether it succeeded, failed or timed out.

ForceFlush SHOULD only be called in cases where it is absolutely necessary, such as when using some FaaS providers that may suspend the process after an invocation, but before the exporter exports the ReadlableLogRecords.

ForceFlush SHOULD complete or abort within some timeout. ForceFlush can be implemented as a blocking API or an asynchronous API which notifies the caller via a callback or an event. OpenTelemetry SDK authors MAY decide if they want to make the flush timeout configurable.

Since: 0.0.1.0

logRecordExporterShutdown :: LogRecordExporter -> IO () Source #

Shuts down the exporter. Called when SDK is shut down. This is an opportunity for exporter to do any cleanup required.

Shutdown SHOULD be called only once for each LogRecordExporter instance. After the call to Shutdown subsequent calls to Export are not allowed and SHOULD return a Failure result.

Shutdown SHOULD NOT block indefinitely (e.g. if it attempts to flush the data and the destination is unavailable). OpenTelemetry SDK authors MAY decide if they want to make the shutdown timeout configurable.

Since: 0.0.1.0

data LogRecordProcessor Source #

Receives callbacks when log records are emitted. Built-in processors batch log records and pass them to exporters.

Spec: https://opentelemetry.io/docs/specs/otel/logs/sdk/#logrecordprocessor

Since: 0.0.1.0

Constructors

LogRecordProcessor 

Fields

  • logRecordProcessorOnEmit :: ReadWriteLogRecord -> Context -> IO ()

    Called when a LogRecord is emitted. This method is called synchronously on the thread that emitted the LogRecord, therefore it SHOULD NOT block or throw exceptions.

    A LogRecordProcessor may freely modify logRecord for the duration of the OnEmit call. If logRecord is needed after OnEmit returns (i.e. for asynchronous processing) only reads are permitted.

  • logRecordProcessorShutdown :: IO ShutdownResult

    Shuts down the processor. Called when SDK is shut down. This is an opportunity for processor to do any cleanup required.

    Shutdown SHOULD be called only once for each LogRecordProcessor instance. After the call to Shutdown, subsequent calls to OnEmit are not allowed. SDKs SHOULD ignore these calls gracefully, if possible.

    Shutdown SHOULD provide a way to let the caller know whether it succeeded, failed or timed out.

    Shutdown MUST include the effects of ForceFlush.

    Shutdown SHOULD complete or abort within some timeout. Shutdown can be implemented as a blocking API or an asynchronous API which notifies the caller via a callback or an event. OpenTelemetry SDK authors can decide if they want to make the shutdown timeout configurable.

  • logRecordProcessorForceFlush :: IO FlushResult

    This is a hint to ensure that any tasks associated with LogRecords for which the LogRecordProcessor had already received events prior to the call to ForceFlush SHOULD be completed as soon as possible, preferably before returning from this method.

    In particular, if any LogRecordProcessor has any associated exporter, it SHOULD try to call the exporter’s Export with all LogRecords for which this was not already done and then invoke ForceFlush on it. The built-in LogRecordProcessors MUST do so. If a timeout is specified (see below), the LogRecordProcessor MUST prioritize honoring the timeout over finishing all calls. It MAY skip or abort some or all Export or ForceFlush calls it has made to achieve this goal.

    ForceFlush SHOULD provide a way to let the caller know whether it succeeded, failed or timed out.

    ForceFlush SHOULD only be called in cases where it is absolutely necessary, such as when using some FaaS providers that may suspend the process after an invocation, but before the LogRecordProcessor exports the emitted LogRecords.

    ForceFlush SHOULD complete or abort within some timeout. ForceFlush can be implemented as a blocking API or an asynchronous API which notifies the caller via a callback or an event. OpenTelemetry SDK authors can decide if they want to make the flush timeout configurable.

data LoggerProvider Source #

Factory for creating Logger instances. Holds processors, resource, attribute limits, and shutdown state.

All operations on LoggerProvider are safe for concurrent use from multiple threads.

Spec: https://opentelemetry.io/docs/specs/otel/logs/sdk/#loggerprovider

Since: 0.0.1.0

Constructors

LoggerProvider 

Fields

data Logger Source #

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.

All operations on Logger are safe for concurrent use from multiple threads.

Since: 0.0.1.0

Constructors

Logger 

Fields

data ReadWriteLogRecord Source #

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.

Since: 0.0.1.0

mkReadableLogRecord :: ReadWriteLogRecord -> IO ReadableLogRecord Source #

Snapshot the current state of a ReadWriteLogRecord into an immutable ReadableLogRecord. Exporters that receive a ReadableLogRecord are guaranteed to see a consistent point-in-time view.

Since: 0.0.1.0

class IsReadableLogRecord r where Source #

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.

Since: 0.0.1.0

Methods

readLogRecord :: r -> IO ImmutableLogRecord Source #

Reads the current state of the LogRecord from its internal IORef. The implementation mirrors readIORef.

readLogRecordInstrumentationScope :: r -> InstrumentationLibrary Source #

Reads the InstrumentationScope from the Logger that emitted the LogRecord

readLogRecordResource :: r -> MaterializedResources Source #

Reads the Resource from the LoggerProvider that emitted the LogRecord

class IsReadableLogRecord r => IsReadWriteLogRecord r where Source #

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)
  • EventName
  • TraceId
  • SpanId
  • TraceFlags

Since: 0.0.1.0

Methods

readLogRecordAttributeLimits :: r -> AttributeLimits Source #

Reads the attribute limits from the LoggerProvider that emitted the LogRecord. These are needed to add more attributes.

modifyLogRecord :: r -> (ImmutableLogRecord -> ImmutableLogRecord) -> IO () Source #

Atomically modifies the LogRecord using its internal IORef. Uses atomicModifyIORef' (strict) to avoid thunk buildup and ensure thread safety under concurrent mutation.

atomicModifyLogRecord :: r -> (ImmutableLogRecord -> (ImmutableLogRecord, b)) -> IO b Source #

Atomically modifies the LogRecord and returns a value. Uses atomicModifyIORef' (strict) for thread safety.

data ImmutableLogRecord Source #

Point-in-time snapshot of a log record's fields.

Spec: https://opentelemetry.io/docs/specs/otel/logs/data-model/

Since: 0.0.1.0

Constructors

ImmutableLogRecord 

Fields

  • logRecordTimestamp :: !(UMaybe Timestamp)

    Time when the event occurred. UNothing when unknown.

  • logRecordObservedTimestamp :: !Timestamp

    Time when the event was observed by the collection system. For events that originate in OpenTelemetry (e.g. using OpenTelemetry Logging SDK) this timestamp is typically set at the generation time and is equal to Timestamp. For events originating externally and collected by OpenTelemetry (e.g. using Collector) this is the time when OpenTelemetry’s code observed the event measured by the clock of the OpenTelemetry code. This field SHOULD be set once the event is observed by OpenTelemetry.

    For converting OpenTelemetry log data to formats that support only one timestamp or when receiving OpenTelemetry log data by recipients that support only one timestamp internally the following logic is recommended: - Use Timestamp if it is present, otherwise use ObservedTimestamp

  • logRecordTracingDetails :: !TracingDetails

    Trace context for log-trace correlation.

    • Request trace id as defined in W3C Trace Context. Can be set for logs that are part of request processing and have an assigned trace id.
    • Span id. Can be set for logs that are part of a particular processing span.
    • Trace flag as defined in W3C Trace Context specification. At the time of writing the specification defines one flag - the SAMPLED flag.
  • logRecordSeverityText :: !(UMaybe Text)

    Severity text (log level). Original string representation from the source.

  • logRecordSeverityNumber :: !(UMaybe SeverityNumber)

    Severity number (1-24). See spec for severity ranges (TRACEDEBUGINFOWARNERROR/FATAL). +-----------------------+-------------+------------------------------------------------------------------------------------------+ | 17-20 | ERROR | An error event. Something went wrong. | +-----------------------+-------------+------------------------------------------------------------------------------------------+ | 21-24 | FATAL | A fatal error such as application or system crash. | +-----------------------+-------------+------------------------------------------------------------------------------------------+ Smaller numerical values in each range represent less important (less severe) events. Larger numerical values in each range represent more important (more severe) events. For example SeverityNumber=17 describes an error that is less critical than an error with SeverityNumber=20.

    Mappings from existing logging systems and formats (or source format for short) must define how severity (or log level) of that particular format corresponds to SeverityNumber of this data model based on the meaning given for each range in the above table. More Information

    These short names can be used to represent SeverityNumber in the UI

    In the contexts where severity participates in less-than / greater-than comparisons SeverityNumber field should be used. SeverityNumber can be compared to another SeverityNumber or to numbers in the 1..24 range (or to the corresponding short names).

  • logRecordBody :: AnyValue

    A value containing the body of the log record. Can be for example a human-readable string message (including multi-line) describing the event in a free form or it can be a structured data composed of arrays and maps of other values. Body MUST support any type to preserve the semantics of structured logs emitted by the applications. Can vary for each occurrence of the event coming from the same source. This field is optional.

    Type any Value of type any can be one of the following: - A scalar value: number, string or boolean, - A byte array, - An array (a list) of any values, - A mapany.

  • logRecordAttributes :: LogAttributes

    Additional information about the specific event occurrence. Unlike the Resource field, which is fixed for a particular source, Attributes can vary for each occurrence of the event coming from the same source. Can contain information about the request context (other than Trace Context Fields). The log attribute model MUST support any type, a superset of standard Attribute, to preserve the semantics of structured attributes emitted by the applications. This field is optional.

  • logRecordEventName :: !(UMaybe Text)

    Optional event name. When set, this identifies the log record as an event.

data LogRecordArguments Source #

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.

Since: 0.0.1.0

data SeverityNumber Source #

Log severity level per the OTel log data model.

Spec: https://opentelemetry.io/docs/specs/otel/logs/data-model/#severity-fields

Since: 0.0.1.0