Logger Configuration

Default Logger configuration

The exception limit for backend exceptions is 10 and the wait time between exceptions is 1000. This means that in case of a defunctioned backend the logger will exist by throwing an exception after at least one second. When the logger is terminated it is granted 1 second to flush the queue and deliver all remaining log messages.

A version of pLoggerConfig that takes a prefix for the command line option.

Since: yet-another-logger-0.2

Create a new logger. A logger created with this function must be released with a call to releaseLogger and must not be used after it is released.

The logger calls the backend function exactly once for each log message. If the backend throws an exception, the message is discarded and the exception is dealt with as follows:

1. The exception is logged. First it is attempt to log to the backend itself. If that fails, due to another exception, the incident is logged to an alternate log sink, usually T.putStrLn or just const (return ()).
2. The message is discarded. If the backend exception is of type BackendTerminatedException the exception is rethrown by the logger which causes the logger to exit. Otherwise the exception is appended to the exception list.
3. If the length of the exception list exceeds a configurable threshold a BackendTooManyExceptions exception is thrown (which causes the logger to terminate).
4. Otherwise the logger waits for a configurable amount of time before proceeding.
5. The next time the backend returns without throwing an exception the exception list is reset to [].

Backends are expected to implement there own retry logic if required. Backends may base their behavoir on the LogPolicy that is effective for a given message. Please refer to the documentation of LoggerBackend for more details about how to implement and backend.

Backends are called synchronously. Backends authors must thus ensure that a backend returns promptly in accordance with the LogPolicy and the size of the logger queue. For more elaborate failover strategies, such as batching retried messages with the delivery of new messages, backends may implement there only internal queue.

Exceptions of type BlockedIndefinitelyOnSTM and NestedAtomically are rethrown immediately. Those exceptions indicate a bug in the code due to unsafe usage of createLogger. This exceptions shouldn't be possible when withLogger is used to provide the logger and the reference to the logger isn't used outside the scope of the bracket.

A version of createLogger that takes as an extra argument a function for logging errors in the logging system.

Since: yet-another-logger-0.2

Provide a computation with a Logger.

Here is an example how this can be used to run a computation with a MonadLog constraint:

withConsoleLogger
    ∷ (MonadIO m, MonadBaseControl IO m)
    ⇒ LogLevel
    → LoggerT T.Text m α
    → m α
withConsoleLogger level inner = do
   withHandleBackend (config ^. logConfigBackend) $ \backend →
       withLogger (config ^. logConfigLogger) backend $ runLoggerT inner
 where
   config = defaultLogConfig
       & logConfigLogger ∘ loggerConfigThreshold .~ level

For detailed information about how backends are executed refer to the documentation of createLogger.

A version of withLogger that takes as an extra argument a function for logging errors in the logging system.

Since: yet-another-logger-0.2

For simple cases, when the logger threshold and the logger scope is constant this function can be used to directly initialize a log function.

For simple cases, when the logger threshold and the logger scope is constant this function can be used to directly initialize a log function.

Since: yet-another-logger-0.2

Convenience function that unwraps a MonadLog computation over a newly created Logger