I'd like to add to this: Riemann is more opinionated than Esper. While you can use it as a general event processing system, it makes some assumptions about event structure which are geared towards application monitoring. For instance, Riemann events have a fixed schema with fields like 'host'. You can treat them as open maps and add arbitrary kv pairs in your streams, but that extra information won't necessarily be serialized to fixed-schema formats like the protocol buffers interface.

Riemann is also more general than Esper, in that you can define arbitrary operations on events. It sacrifices having an up-front query language in favor of composable functions with stateful side effects. If you want to write a stream that restarts an EC2 instance on failure, it'll be a composable first-class citizen and you can write it right in the config file. Same goes for a stream that pulls in, say, parallel colt to do some heavy statistical lifting. On the other hand, Riemann doesn't include the full range of Esper queries as builtin streams yet, and the ones that are there haven't been optimized to the same degree.

Hope this helps clarify things. :)

From the mouth of the project's owner:

From skimming the docs, it looks like Esper is much bigger, much cooler, and with a more abstract version of events. It implements a lot of the primitives I've been considering but haven't built yet. It looks more difficult to set up, and has a commercial offering for support and HA; neither of which are present in Riemann right now.[1]

I recently finished building a monitoring system using Esper and JRuby since the client asked specifically for that, but I wished I had used Riemann from the beginning.

[1] https://groups.google.com/forum/#!msg/riemann-users/GhVMYJow...