SYNOPSIS

    In your module (producer):

     package Foo;
     use Log::ger; # will import some logging methods e.g. log_warn, log_error
    
     sub foo {
         ...
         # produce some logs
         log_error "an error occurred: %03d - %s", $errcode, $errmsg;
         ...
         log_debug "http response: %s", $http; # automatic dumping of data
     }
     1;

    In your application (consumer/listener):

     use Foo;
     use Log::ger::Output 'Screen';
    
     foo();

DESCRIPTION

    Log::ger is yet another logging framework with the following features:

      * Separation of producers and consumers/listeners

      Like Log::Any, this offers a very easy way for modules to produce
      some logs without having to configure anything. Configuring output,
      level, etc can be done in the application as log consumers/listeners.
      To read more about this, see the documentation of Log::Any or
      Log::ger::Manual (but nevertheless see Log::ger::Manual on why you
      might prefer Log::ger to Log::Any).

      * Lightweight and fast

      Slim distribution. No non-core dependencies, extra functionalities
      are provided in separate distributions to be pulled as needed.

      Low startup overhead. Only around 1-1.5ms or less, comparable with
      Log::Any 0.15, less than Log::Any 1.0x at around 4-10ms, and
      certainly less than Log::Log4perl at 20-30ms. This is measured on a
      2014-2015 PC and before doing any output configuration. For more
      benchmarks, see Bencher::Scenarios::LogGer.

      Conditional compilation. There is a plugin to optimize away unneeded
      logging statements, like assertion/conditional compilation, so they
      have zero runtime performance cost. See Log::ger::Plugin::OptAway.

      Being lightweight means the module can be used more universally, from
      CLI to long-running daemons to inside routines with tight loops.

      * Flexible

      Customizable levels and routine/method names. Can be used in a
      procedural or OO style. Log::ger can mimic the interface of Log::Any,
      Log::Contextual, Log::Log4perl, or some other popular logging
      frameworks, to ease migration or adjust with your personal style.

      Per-package settings. Each importer package can use its own format,
      output, or filter. For example, some modules that are migrated from
      Log::Any uses Log::Any-style logging, while another uses native
      Log::ger style, and yet some other uses block formatting like
      Log::Contextual. This eases code migration and teamwork. Each module
      author can preserve her own logging style, if wanted, and all the
      modules still use the same framework.

      Dynamic. Outputs and levels can be changed anytime during run-time
      and logging routines will be updated automatically. This is useful in
      situation like a long-running server application: you can turn on
      tracing logs temporarily to debug problems, then turn them off again,
      without restarting your server.

      Interoperability. There are modules to interop with Log::Any, either
      consume Log::Any logs (see Log::Any::Adapter::LogGer) or produce logs
      to be consumed by Log::Any (see Log::ger::Output::LogAny).

      Many output modules and plugins. See Log::ger::Output::*,
      Log::ger::Format::*, Log::ger::Filter::*, Log::ger::Plugin::*.
      Writing an output module in Log::ger is easier than writing a
      Log::Any::Adapter::*.

    For more documentation, start with Log::ger::Manual.

SEE ALSO

    Some other popular logging frameworks: Log::Any, Log::Contextual,
    Log::Log4perl, Log::Dispatch, Log::Dispatchouli.