diff options
author | Ivan Topolnak <itopolnak@despegar.com> | 2014-03-31 18:22:27 -0300 |
---|---|---|
committer | Ivan Topolnak <itopolnak@despegar.com> | 2014-03-31 18:22:27 -0300 |
commit | 503752564267d784b15d3b0d12e45a3c190fdd54 (patch) | |
tree | 72f93eb4ee8446cbdc6657d2bf30de1e912abc8e /site/src/main/jekyll | |
parent | 1f6a3f3bb9c59da198df302193ddf5c29c4e42d6 (diff) | |
download | Kamon-503752564267d784b15d3b0d12e45a3c190fdd54.tar.gz Kamon-503752564267d784b15d3b0d12e45a3c190fdd54.tar.bz2 Kamon-503752564267d784b15d3b0d12e45a3c190fdd54.zip |
starting metrics documentation
Diffstat (limited to 'site/src/main/jekyll')
-rw-r--r-- | site/src/main/jekyll/core/metrics.md | 43 |
1 files changed, 43 insertions, 0 deletions
diff --git a/site/src/main/jekyll/core/metrics.md b/site/src/main/jekyll/core/metrics.md new file mode 100644 index 00000000..ab144d13 --- /dev/null +++ b/site/src/main/jekyll/core/metrics.md @@ -0,0 +1,43 @@ +--- +title: Kamon | Core | Documentation +layout: default +--- + +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 analyze 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 lives 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. + +SIMPLE CLASS DIAGRAM WITH COLLECTION AND FLUSHING SIDES + |