Proactive Monitoring

Good for You!

Frugal

Riemann takes an interesting approach, but definitely has its weaknesses. The configuration Clojure syntax is likely the biggest obstacle; if you are not familiar with it, you will need to allow for a longer training period. Thanks to the documentation on the project site and the examples, this task can be mastered.

Another issue is certainly the client design – one process per metric is not very smart; in fact, it can even distort the acquired values depending on the scope of the setup. Therefore, a setup that bundles Riemann with a statistics daemon like Collectd [18], which collects the metrics and then sends them to Riemann, makes sense.

High availability (e.g., synchronization between multiple nodes, failover, or load balancing) is not addressed. If you do not want to follow the example here, with multiple servers that report to a central instance, you can follow the developer's recommendation. In the how-to, they suggest using two servers with a floating IP. The evaluation is then based on events that are sent to one of the two servers depending on the floating IP status.

One genuine benefit is that Riemann outsources threshold values to the clients to handle, which simplifies the deployment of new systems – and not just in large organizations. For the notification problem during a nightly backup, mentioned in the first paragraph of this article, the backup software could report to Riemann via its internal metrics and temporarily adapt thresholds to the changed situation.

Infos