Compare/contrast with Prometheus about kubesnap HOT 1 OPEN

Hi @binarybana, I'm glad that you like the post -thank you.

Some general introduction. Snap architecture and design was meant to be easy and comprehensible, it's highly pluginable - but under the hood quite simple - you have snap daemon to which you add different plugins, which are responsible for collecting, processing and publishing data. It can be run on the target from which you collect the metrics, or it can communicate with target remotely - it's just the matter of whether collector plugin support remote mode.

So comparing snap with prometheus I would say that:

• metrics don't have to be exposed in specific format - snap plugins deal with metrics case by case
• snap has plugins for gathering low level metrics, like the ones for Linux perf events subsystem, to OpenStack metrics, and application level metrics - like Apache HTTP. The list of plugins is maintained in main snap repo.
• snap uses pull model for retrieving data (that's similar to prometheus), then snap is able to process collected metrics in-place, for example encrypting them or changing format, and then pushes metrics to places like databases (SQL, No-SQL, time-series), message queues, etc.
• there is no eventing/alerting component in snap, but it could be simply done with publisher plugin.
• set of metrics to be collect is declarative, you specify them in so called task manifest (a json or yaml file), and you are able to collect them dynamically - meaning that when you, for example, specify that you'd like to collect all metrics from all CPUs, you just put this in task manifest: /intel/cpu/*.
• snap doesn't come with builtin data store, this is handled by publisher plugins
• our metrics tagging feature allows you to put tags so that they can be used later on, for example in time-series DB
• our goal with kubesnap was to show that adding custom (for example application level metrics) can be easy in Kubernetes - not requiring any code changes, but rather loading a plugin and starting a task.

Some other things worth mentioning I think are:

• in snap we have tribe feature that simplifies operations - you create agreements, attach nodes to them, so that you can collect metrics according to the agreements. For example you create ceph and mysql agreements, then assign some nodes to ceph agreement and some to mysql agreement. Loading a plugin on one node belonging to ceph agreement will trigger loading this plugin automatically on all other node in ceph agreement. Then similarly you can start task to collect metrics on one node and others in this agreement will follow.
• the idea behind snap was to make Intel telemetry available, because we believe it may be useful to improve monitoring capabilities, operations, scheduling, etc. Hence in our plugins catalog you'll find plugins collecting Intel telemetry.

And finally our goal is making telemetry available to everyone and in every cases - we are not competing with other solutions - we are just new option :)

from kubesnap.