#monitoringlove sprint takeaway

A few weeks ago I co-organised and participated in a #monitoringlove sprint in Berlin.

My personal plan was to play with more modern utilities that can potentially replace our existing Nagios monitoring chain. The result of what I think would be a good setup would probably look like this:

monitoringlove2

Most of those parts already exist. The new thing in there is what I called “riemann-actual” – something that generates new events based on existing events from the index. I call this “higher order” monitoring – in Nagios these would be known as “business processes”.

The word “business processes” is a bit misleading as nothing is really about processes there: it means taking previously taken monitoring data and subsuming it into a more dense expression. Ideally you can recombine any of your metrics to make an overall statement of “everything is good if more than 80% of the appservers are up and we have less than 5% of error response rate and the frontpage is reachable from at least 3 outside systems”.

Data gathering

First, I tried to setup something for data gathering. I already got the recommendation to look at scales for in-app metrics and found it easy to get started. I like the notion that metrics in your app behave a little bit like logging: you don’t care where they go and you expect the user of your system to configure an actual target. The built-in webserver is nice to get started and graphite as a protocol seams fair enough nowadays to forward data.

To gather system-level metrics I guess both collectd and statsd are fine points to start from. I used collectd to begin with as it actually had a riemann output plugin.

Central processing

We want to be able to take all of the data we acquire into account on making decisions quickly. Riemann seems to be the most suitable tool for this task. After playing around for a while trying to implement “business process” monitoring in clojure I found it easier to provide a Python-environment that can talk to riemann and do those decisions. I made this available as “riemann-actual” on bitbucket.

I noticed that this setup would require only a very generic riemann configuration and could perform on a per-customer or per-project basis by just adding more of those loops on top of riemann.

Performance-wise I was extremely happy. I could have a 10Hz monitoring loop resulting in about 1k events per second on my computer. With that resolution all business processes would notice an outage with no visible delay.

A nice feat is that Riemann can generate events when old events reach their TTL. This way you can make sure that you notice when a system you are monitoring “goes dark”.

Also, it seems that Riemann configuration can be unit-tested easily: feed events in, watch the index, or see events coming out. It doesn’t get much simpler than that.

The configurable dashboard in Riemann 0.2 is already very helpful: responsive, flexible, and fast  – until you try to display 10k metrics at once. 😉 It needs a little more finishing but it’s on a good way.

Distributed consumers

My understand of Riemann is that it wants to be a nexus for “central, volatile, shared state”. This means you get a lot of updates going through and that it needs to be good with I/O. OTOH it means that it shouldn’t do much and just make it easy for you to router your data somewhere else.

Actually looking at further consumers didn’t happen as 3 days aren’t that long. 🙂 I see graphite on the horizon (with the setup becoming easier over time) as well as more custom tooling to turn events into notifications, etc.

A look at OpenTSDB seemed promising at first but it turns out to have an even more complex setup requirement than graphite. I got it running but it seemed extremly hard to control, so I dropped it after a few hours.

Overall it seems that since the outcry of #monitoringsucks a lot has happened and I’m faithful that there’s a way out of Nagiosland in the near future.

More notes from our sprint are available at pysprints.de. (Although in German.)

 

August, 15th–17th: Sprinting on Pyramid

After Zope “-the-Framework” reaching the end of its lifecycle during the last few years, we did a bunch of new projects with Pyramid, a nice web framework primarily authored by long-term Zope developer Chris McDonough.

We think it’s about time to give something back to the community, and become more involved in Pyramid development. We therefore happily announce to host a large Pyramid sprint organised in cooperation with the pysprints.de team. You find more information and sprint topics at GitHub.

The sprint starts on Thu, August 15th 10:00h CEST, and ends on Sat, August 17th with a garden party in the evening! Expect BBQ, beer and (most likely) live music!

If you would like to attend, please sign up on lanyrd.

Notizen aus dem Norden

Unsere Herberge auf Rügen 2012
Unsere Herberge auf Rügen 2012

Heute neigt sich unser diesjähriger Sprint dem Ende. Am Dienstag sind wir gen Norden auf die Insel Rügen gefahren, um uns für 3 Tage intensiv darüber zu unterhalten, wie wir in Zukunft Software entwickeln wollen. Der Fokus lag dabei auf der Client-Seite, also dem Teil der Anwendung, der im Browser ausgeführt wird. Hier wollen wir weitere Erfahrung sammeln und Konzepte suchen, wie man wart- und testbaren, strukturierten Code schreibt.

Im Vorfeld haben wir uns auf drei JavaScript Frameworks/Bibliotheken geeinigt, die wir uns dann am Mittwoch in drei Gruppen à zwei Personen intensiv angeschaut haben: Ember, Obviel und Backbone. Neben Dokumentation lesen und Tutorials ausprobieren haben wir auch gegen einen selbst-gestrickten “Spielserver” programmiert, um durch die praktische Erfahrung ein Gefühl für die Konzepte hinter dem Framework zu bekommen und einschätzen zu können, inwieweit sich das Framework in unserem Alltag einsetzen lässt.

Ember hat uns für den Einsatz bei “Grüne Wiese”-Projekten begeistert. Durch die strikte Trennung von Model, View und Controller (MVC) schreibt man nicht nur automatisch saubereren, sondern auch testbaren Code. Das Objekt-Modell bringt automatisierte, bidirektionale Aktualisierung zwischen Model und View mit, und für die Speicherung auf dem Server gibt es ein kleines, gut integriertes REST-Plugin. Der Aufwand, eine funktionierende CRUD-Anwendung, die Änderungen automatisch an den Server propagiert, zu entwickeln, ist mit Ember erstaunlich gering. Auch wie Ember es erlaubt, seine Klassen zu beerben, ist uns positiv aufgefallen. Leider haben wir es nicht geschafft, zwei Ember-Anwendungen auf einer Seite zu laden. Auch ist die Dokumentation noch recht dünn, was daran liegen dürfte, dass Ember noch ein junges Produkt ist.

Hilfreiche Links zu Ember:

Obviel ist streng genommen unser eigenes “Kind”, denn erste Ideen dazu entstanden im Jahre 2008 bei gocept. Obviel ist ein Client-seitiges Web-Framework für jQuery mit einem einfachen, aber genialen Prinzip: für ein JavaScript-Objekt rendert man einen View in einem Element. Dreh- und Angelpunkt bei Obviel sind die Interfaces, die definieren, wie ein View Objekte, die das Interface implementieren, rendert. Entwickler, die mit der Komponenten-Architektur von Zope vertraut sind, werden keine Probleme haben, Obviel zu verstehen. Weiterhin lässt sich Obviel problemlos in bestehende Projekte integrieren, es enthält Unterstützung für Internationalisierung (i18n), Forms mit Validierung, verschiedene Template-Engines, Subviews, …

Hilfreiche Links:

Backbone unterstützt den Entwickler bei der Strukturierung seiner Webanwendungen durch in Code gegossene Konventionen. Es wirkt sehr fokussiert, denn es tut nicht wirklich viel, aber das Wenige tut es sehr sinnvoll. Backbone ist, im Gegensatz zu Ember, sehr gut dokumentiert, löst aber im Moment keines unserer Probleme. Da Backbone insbesondere keine Unterstützung für data binding bietet, haben wir noch Knockout und Rivets ins Spiel gebracht. Für ersteres steht mit Knockback der „Glue-Code“, um die Frameworks miteinander zu verheiraten, schon zur Verfügung, für letzteres mussten wir ihn uns aus der Dokumentation und dem Issue-Tracker des Projekts zusammensuchen.

Weiterführende Links:

Ein Fazit zu ziehen fällt uns nicht leicht: Ember behalten wir für das nächste “Grüne Wiese”-Projekt auf jeden Fall im Auge. Da uns Backbone und Knockout/Rivets nicht überzeugen konnten, haben wir uns noch spontan AngularJS angeschaut – aber auch hier ist im Moment die Ernüchterung groß: Persistieren von Daten ist ein ungelöstes Problem, die Watcher auf dem Model (data binding) feuern nur unregelmäßig oder viel zu oft. Nach längerem Probieren haben wir herausgefunden, dass wir eine eigene Direktive schreiben müssen, die sich um die Persistierung kümmert.

Bleibt also Obviel, das wir an der einen oder anderen Stelle in unseren Projekten schon verwenden. Es wird wohl auch in Zukunft unser Werkzeug, um bestehenden JavaScript-Code zu verbessern oder neue Frontend-Einheiten zu bauen.

Das gocept-Team