hs-opentelemetry-api
Stabilityexperimental
Safe HaskellNone
LanguageHaskell2010

OpenTelemetry.Processor.LogRecord

Description

 
Synopsis

Documentation

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 FlushResult Source #

The outcome of a call to OpenTelemetry.Trace.forceFlush or OpenTelemetry.Log.forceFlush

Since: 0.0.1.0

Constructors

FlushTimeout

One or more spans or LogRecords did not export from all associated exporters within the alotted timeframe.

FlushSuccess

Flushing spans or LogRecords to all associated exporters succeeded.

FlushError

One or more exporters failed to successfully export one or more unexported spans or LogRecords.

Instances

Instances details
Show FlushResult Source # 
Instance details

Defined in OpenTelemetry.Internal.Common.Types

Eq FlushResult Source # 
Instance details

Defined in OpenTelemetry.Internal.Common.Types