Logging library designed to log data events instead of plain words.

This namespace provides the core functions of ***μ/log***.

The purpose of ***μ/log*** is provide the ability to generate events
directly from your code. The instrumentation process is very simple
and similar to add a traditional log line, but instead of logging
a message which hardly anyone will ever read, your can log an
event, a data point, with all the attributes and properties which
make sense for that particular event and let the machine use it
in a later time.

***μ/log*** provides the functions to instrument your code with minimal
impact to performances (few nanoseconds), to buffer events and manage
the overflow, the dispatching of the stored events to downstream
systems where they can be processed, indexed, organized and queried to
provide rich information (quantitative and qualitative) about your
system.

Once you start using event-based metrics you will not want to use
traditional metrics any more.

Additionally, ***μ/log*** offer the possibility to trace execution with
a micro-tracing function called **μ/trace**.  It provides in app
distributed tracing capabilities with the same simplicity.

The publisher sub-system makes extremely easy to write new publishers
for new downstream system. ***μ/log*** manages the hard parts like: the
buffering, the retries, the memory buffers and the publisher's state.
It is often required only a dozen lines of code to write a new powerful
custom publisher and use it in your system.

For more information, please visit: https://github.com/BrunoBonacci/mulog

Logging library designed to log data events instead of plain words.

This namespace contains the implementation of a ring-buffer and a
wrapper agent used to buffer the events before their are published
to the downstream systems by the publishers.

Flakes are like snowflakes, no two are the same.
------------------------------------------------

This is an implementation of a 192-bits unique ids which has the
following characteristics:

 - **Monotonic IDs**
   Every new ID is larger than the previous one. The idea is that
   the 'happens before' relationship applies to these IDs. If you
   observe a Flake and you create a new one in the same thread, the
   new Flake is going to be larger than the previous one. There is
   no synchronisation and it uses a wall clock as well as a
   monotonic clock as part of the generation, therefore Flakes
   created across processes/machines might suffer from clock skew
   and hard reset.  Generally the following condition should apply
   for all Flakes `flake0 < flake1 < flake2 < ... < flakeN`

 - **Two components: one time-based (64 bits), one random (128 bits)**
   The most significant bits are time based and they use a monotonic
   clock with nanosecond resolution. The next 128 bits are randomly
   generated.

 - **Random-based**
   The Random component is built with a PRNG for speed.
   It uses 128 full bits, more bits than `java.util.UUID/randomUUID`
   which has 6 bits reserved for versioning and type, therefore
   effectively only using 122 bits.

 - **Homomorphic representation**
   Whether you choose to have a bytes representation or string representation
   it uses an encoding which maintain the ordering.
   Which it means that:
   if `flake1 < flake2` then `flake1.toString() < flake2.toString()`
   Internally it uses a NON STANDARD base64 encoding to preserve the ordering.
   Unfortunately, the standard Base64 encoding doesn't preserve this property
   as defined in https://en.wikipedia.org/wiki/Base64.

 - **Web-safe string representation**.
   The string representation uses only characters which are web-safe and can
   be put in a URL without the need of URL encoding.

 - **Fast**, speed is important so we target under 50 nanosecond for 1 id.
   These are the performances measured with Java 1.8.0_232 for the creation
   of a new Flake.

       Evaluation count : 1570017720 in 60 samples of 26166962 calls.
       Execution time mean : 36.429623 ns
       Execution time std-deviation : 0.519843 ns
       Execution time lower quantile : 35.684111 ns ( 2.5%)
       Execution time upper quantile : 37.706974 ns (97.5%)
       Overhead used : 2.090673 ns

       Found 4 outliers in 60 samples (6.6667 %)
       low-severe 4 (6.6667 %)
       Variance from outliers : 1.6389 % Variance is slightly inflated by outliers

   These are the performances for creating an new Flake and turn it into a string

       Evaluation count : 755435400 in 60 samples of 12590590 calls.
       Execution time mean : 78.861983 ns
       Execution time std-deviation : 1.006261 ns
       Execution time lower quantile : 77.402593 ns ( 2.5%)
       Execution time upper quantile : 81.006901 ns (97.5%)
       Overhead used : 1.881732 ns