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
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.
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
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close