OpenTelemetry.Processor.LogRecord

Documentation

data LogRecordProcessor

LogRecordProcessor is an interface which allows hooks for LogRecord emitting.

Built-in processors are responsible for batching and conversion of LogRecords to exportable representation and passing batches to exporters.

LogRecordProcessors can be registered directly on SDK LoggerProvider and they are invoked in the same order as they were registered.

Each processor registered on LoggerProvider is part of a pipeline that consists of a processor and optional exporter. The SDK MUST allow each pipeline to end with an individual exporter.

The SDK MUST allow users to implement and configure custom processors and decorate built-in processors for advanced scenarios such as enriching with attributes.

The following diagram shows LogRecordProcessor’s relationship to other components in the SDK:

+-----+------------------------+ +------------------------------+ +-------------------------+ | | | | | | | | | | | Batching LogRecordProcessor | | LogRecordExporter | | | +---> Simple LogRecordProcessor +---> (OtlpExporter) | | | | | | | | | SDK | Logger.emit(LogRecord) | +------------------------------+ +-------------------------+ | | | | | | | | | | | | | | | +-----+------------------------+

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 (Async 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 ()

  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 ShutdownResult

Constructors

ShutdownSuccess

ShutdownFailure

ShutdownTimeout