Liking cljdoc? Tell your friends :D

com.brunobonacci.mulog

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 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
raw docstring

com.brunobonacci.mulog.buffer

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.

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.
raw docstring

com.brunobonacci.mulog.flakes

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 and Flake and you create a new one, the Flake is going to be larger than the previous one. Therefore 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
    
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
   and Flake and you create a new one, the Flake is going to be larger
   than the previous one.
   Therefore 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

 
raw docstring

cljdoc is a website building & hosting documentation for Clojure/Script libraries

× close