diff options
author | Ivan Topolnjak <ivantopo@gmail.com> | 2014-06-11 23:05:19 -0300 |
---|---|---|
committer | Ivan Topolnjak <ivantopo@gmail.com> | 2014-06-11 23:05:19 -0300 |
commit | 63ad026b7af5e9e94471ab38cd2663e8f69d87ac (patch) | |
tree | 7ee8978500781a8d1c2be58b6f6eb946fc0c61c2 /site/src/main/jekyll/core/metrics/basics.md | |
parent | e7dbbfbffaa99bc1642ab6b01927540cabc8161f (diff) | |
download | Kamon-63ad026b7af5e9e94471ab38cd2663e8f69d87ac.tar.gz Kamon-63ad026b7af5e9e94471ab38cd2663e8f69d87ac.tar.bz2 Kamon-63ad026b7af5e9e94471ab38cd2663e8f69d87ac.zip |
- site: remove the site from this repository
Diffstat (limited to 'site/src/main/jekyll/core/metrics/basics.md')
-rw-r--r-- | site/src/main/jekyll/core/metrics/basics.md | 93 |
1 files changed, 0 insertions, 93 deletions
diff --git a/site/src/main/jekyll/core/metrics/basics.md b/site/src/main/jekyll/core/metrics/basics.md deleted file mode 100644 index 991ddf26..00000000 --- a/site/src/main/jekyll/core/metrics/basics.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Kamon | Core | Documentation -layout: documentation ---- - -Metrics -======= - -Some intro about metrics - -Philosophy ----------- - -Back in the day, the most common approach to get metrics out of an Akka/Spray application for production monitoring was -doing manual instrumentation: select your favorite metrics collection library, wrap you messages with some useful -metadata, wrap your actor's receive function with some metrics measuring code and, finally, push that metrics data out -to somewhere you can keep it, graph it and analyse it whenever you want. - -Each metrics collection library has it's own strengths and weaknesses, and each developer has to choose wisely according -to the requirements they have in hand, leading them in different paths as they progress with their applications. Each -path has different implications with regards to introduced overhead and latency, metrics data accuracy and memory -consumption. Kamon takes this responsibility out of the developer and tries to make the best choice to provide high -performance metrics collection instruments while keeping the inherent overhead as low as possible. - -Kamon tries to select the best possible approach, so you don't have to. - - -Metrics Collection and Flushing -------------------------------- - -All the metrics infrastructure in Kamon was designed around two concepts: collection and flushing. Metrics collection -happens in real time, as soon as the information is available for being recorded. Let's see a simple example: as soon as -a actor finishes processing a message, Kamon knows the elapsed time for processing that specific message and it is -recorded right away. If you have millions of messages passing through your system, then millions of measurements will be -taken. - -Flushing happens recurrently after a fixed amount of time has passed, a tick. Upon each tick, Kamon will collect all -measurements recorded since the last tick, flush the collected data and reset all the instruments to zero. Let's explore -a little bit more on how this two concepts are modeled inside Kamon. - -<img class="img-responsive" src="/assets/img/diagrams/metric-collection-concepts.png"> - -A metric group contains various individual metrics that are related to the same entity, for example, if the entity we -are talking about is an actor, the metrics related to processing time, mailbox size and time in mailbox for that -specific actor are grouped inside a single metric group, and each actor gets its own metric group. As you might disguise -from the diagram above, on the left we have the mutable side of the process that is constantly recoding measurements as -the events flow through your application and on the right we have the immutable side, containing snapshots representing -all the measurements taken during a specific period on time for a metric group. - - -Filtering Entities ------------------- - -By default Kamon will not include any entity for metrics collection and you will need to explicitly include all the -entities you are interested in, be it a actor, a trace, a dispatcher or any other entity monitored by Kamon. The -`kamon.metrics.filters` key on your application's configuration controls which entities must be included/excluded from -the metrics collection infrastructure. Includes and excludes are provided as lists of strings containing the -corresponding GLOB patterns for each group, and the logic behind is simple: include everything that matches at least one -`includes` pattern and does not match any of the `excludes` patterns. The following configuration file sample includes -the `user/job-manager` actor and all the worker actors, but leaves out all system actors and the `user/worker-helper` -actor. - -``` -kamon { - metrics { - filters = [ - { - actor { - includes = [ "user/job-manager", "user/worker-*" ] - excludes = [ "system/*", "user/worker-helper" ] - } - }, - { - trace { - includes = [ "*" ] - excludes = [] - } - } - ] - } -} -``` - -Instruments ------------ - -Talk about how HDR Histogram works and how we use it. - - -Subscription protocol ---------------------- - -Explain how to subscribe for metrics data and provide a simple example. |