Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Riemann – A network monitoring system

riemann.io

Post reply on HN
Print view View original

61–70 of 109 posts

Re: Riemann – A network monitoring system

#61

Post by donaldguy »

Since the theme of this thread seems to be non-clojure alternatives, I'll point in the direction of InfluxData (formerly InfluxDB)'s new-ish Kapacitor project.

While I'm unconvinced their custom JavaScripty DSL (TICKscript) is actually preferable to Clojure or even can be read without careful, quite LISP-like indentation, it is pretty similar in basic functionality to Riemann and is definitely not-Clojure*

see: https://influxdata.com/blog/announcing-kapacitor-an-open-sou...

https://docs.influxdata.com/kapacitor/v0.2/tick/

https://github.com/influxdata/kapacitor

*at worst, it's a mangled subset of clojure with extraneous dots and the parentheses in the wrong places :-)

Re: Riemann – A network monitoring system

#63

Post by vruiz »

zimpenfish wrote: post #26
MayMuncher wrote: post #24

Earlier quoted context omitted.

I don't like it since the master basically does a curl on each server to get the info, so it doesn't work behind a firewall without tons of issues

That's the reason I haven't bothered with Prometheus - pull systems make no sense to me since you have to configure a single place with perfect* knowledge of your system rather than just pushing local knowledge to a collector. (Ok, you do need some knowledge at the parent if you want to raise alerts but you'd need that anyway.)

You can leverage service discovery to make your configuration dynamic: http://prometheus.io/blog/2015/06/01/advanced-service-discov...

Re: Riemann – A network monitoring system

#64

Post by charlieflowers »

shizcakes wrote: post #29

We've been using Riemann since 2013 and love it! If you're coming from Nagios (or not), and you'd like something that will schedule Nagios event scripts (and others) and send them to Riemann, I have been using this in production since mid-2013: https://github.com/bmhatfield/riemann-sumd It allows you to tap into the huge ecosystem that is Nagios monitors, without requiring any other Nagios component at all. It just t…

We also use Riemann in prod and love it. It is pretty much the perfect switchboard/aggregator for stat streams.

It's only part of the stack, but it's great for routing some stats to this TSDB and other stats to that TSDB. It's also great for detecting anomalies and sending updates to wherever you want them to go.

For us, this happens in 150 lines of clojure plus 150 lines of unit tests. I know that's fairly meaningless without knowing more about our system -- but the point is, it's very expressive so you get a lot done in a few lines of code. And therefore, don't worry too much about it being clojure.

Re: Riemann – A network monitoring system

#65

Post by dozzie »

falcolas wrote: post #51
dozzie wrote: post #40

Earlier quoted context omitted.

> Config file isn't a config file, it's an executed bit of Clojure code For stream processing engines, configuration will be code. Unfortunate, but unavoidable. > Riemann is not a replacement for an alerting mechanism > Riemann is not a replacement for a trend graphing mechanism. Indeed it is not. It's misadvertised as a monitoring solution, while it's a stream processing engine. What I think of it is that you're sup…

> For stream processing engines, configuration will be code. Unfortunate, but unavoidable. I honestly don't think it's unavoidable, so long as you separate the configuration (i.e. hosts, thresholds, outputs, etc) from your processing logic. Of course, this requires additional development work from within the "configuration" file.

But for a stream engine the processing logic is configuration.

There aren't many examples of when code is a configuration parameter for service (generic RPC server for sysadmins being another example I've encountered), but there are some.

Re: Riemann – A network monitoring system

#67

Post by lmm »

falcolas wrote: post #59
lmm wrote: post #56

Earlier quoted context omitted.

> The problem with configs (and this is with my operations hat on), is that they are rarely as well secured (or reviewed) as regular code, so code based configuration files pose a significant privilege escalation threat on production servers. Any complex config file runs that kind of risk though, whether it's in a well-known programming language or an ad-hoc DSL. My preferred approach is to include most of the config…

> Any complex config file runs that kind of risk though, whether it's in a well-known programming language or an ad-hoc DSL. The major difference is that Clojure (Python, Lua, Perl, et al) gives you all the tools right out of the box, whereas with a DSL you should be severely restricted from doing things like reading/writing to disk, making network calls, or executing other binaries. Granted, there are possibly ways…

That sounds like a security-through-obscurity approach to me. (No doubt others would call it defense in depth).

Re: Riemann – A network monitoring system

#69

Post by djhworld »

falcolas wrote: post #30

Evaluated it, and ultimately rejected it for a couple of reasons: - You must pick up Clojure to understand and configure Riemann (we're not a Clojure shop, so this is a non-trivial requirement) - Config file isn't a config file, it's an executed bit of Clojure code - Riemann is not a replacement for an alerting mechanism, it's another signal for alerting mechanisms (though since it's Clojure and the configuration fil…

I spent over a day wrestling to get Skyline to work, but it's so outdated, and all of its dependencies have moved on since it was launched, that it's an absolute nightmare to even get running.

to be fair though it does say it's no longer maintained.

Re: Riemann – A network monitoring system

#70

Post by jsmthrowaway »

lmm wrote: post #67
falcolas wrote: post #59

Earlier quoted context omitted.

> Any complex config file runs that kind of risk though, whether it's in a well-known programming language or an ad-hoc DSL. The major difference is that Clojure (Python, Lua, Perl, et al) gives you all the tools right out of the box, whereas with a DSL you should be severely restricted from doing things like reading/writing to disk, making network calls, or executing other binaries. Granted, there are possibly ways…

That sounds like a security-through-obscurity approach to me. (No doubt others would call it defense in depth).

How is "don't give a config file an arbitrary writable open() call" security by obscurity? What is being hidden? That's not really how that term works. I also don't understand your invocation of defense in depth or the (wrong) comparison you are trying to make. Can you reframe your rebuttal without loaded security terms that don't fit what you're saying?

The point GP is making, and with which I agree, is that executable configurations can be dangerous if not sandboxed and even then still carry an elevated risk versus a parser. We are speaking relatively; it is absolutely still a risk to parse user input as a config, but less so than a full programming environment being immediately available to a malicious config writer.

Stepping back and identifying the malicious vector is worth it here, though, as there's a case to be made that configurations are the domain of administrators and should be secured accordingly via external means. Then the problem is recentered.

Post reply on HN