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

51–60 of 109 posts

Re: Riemann – A network monitoring system

#51

Post by falcolas »

dozzie wrote: post #40
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…

> 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.

Re: Riemann – A network monitoring system

#52

Post by AdamN »

dozzie wrote: post #40
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…

> 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…

It seems like having a small tool to turn yaml files into basic clojure code for easy rulesets would be an easy extension. It might encourage Bad behavior and of course it couldn't do everything ... just an idea.

Re: Riemann – A network monitoring system

#53

Post by zgohr »

Monitoring request - dynamic configuration. Using Nagios requires configuration file changes and service reload Would prefer dynamic, on the fly configuration. Even better, configuration that can be adjusted externally, possibly from a web API endpoint. Better still, configuration that IS external, where the monitoring service queries an external service every X minutes to determine what to monitor.

Performant - In the realm of 6 oid monitoring of 50,000+ devices in 5 minute intervals

Re: Riemann – A network monitoring system

#54

Post by bbrazil »

zimpenfish wrote: post #44
bbrazil wrote: post #37

Earlier quoted context omitted.

You need a place with all that information anyway, otherwise how do you alert on something being missing? If you can't easily do that with your existing infrastructure, you should fix that first. I've written about this at http://www.robustperception.io/you-look-good-have-you-lost-m...

If a stream of data stops appearing, then you can alert. You don't need to pre-configure the existence of that stream (although if you might never get data from an object, this obviously is a failure you won't catch.) Your article is a good one but in my experience, many companies are still many years from being able to implement that kind of database:machine knowledge consistency.

You can only alert in that case if the data starts, and there's no transient issues preventing your monitoring working around the time it stops.

Alerting based on state changes is fragile, it's better to compare against what you expect to see.

Re: Riemann – A network monitoring system

#55

Post by dorfsmay »

Anderkent wrote: post #22
dozzie wrote: post #20

Earlier quoted context omitted.

It's actually a disadvantage, since it's Clojure, and Riemann requires that its operator actually knows Clojure (knowledge of dozen languages, even when some of them are functional, is not enough).

Is requiring someone to learn a programming language worse than requiring someone to learn a custom DSL? Seems a strange assertion.

The problem with immature DSLs are that you spend a lot if time figuring out if the bug is in the DSL or in your use of it, and lesser network effect: because they are less used, they are more buggy, there is less information and help about them out there, there are less tools you can use.

Re: Riemann – A network monitoring system

#56

Post by lmm »

falcolas wrote: post #50
lmm wrote: post #32

Earlier quoted context omitted.

IME configs often end up being turing-complete; if so, better to have them in a real programming language where you at least have tools available to manage the complexity.

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. With my programmer's hat on, they're also harder to populate programmatically, so I have a hard time justifying their use.

> 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 in the regular code (subject to the normal review/release process), with the only thing on the server being a one-line "which config to use" setting (e.g. dev/stag/prod). Of course that has its own problems.

> With my programmer's hat on, they're also harder to populate programmatically, so I have a hard time justifying their use.

Not at all true in the case of Clojure - it's just S-expressions, very easy to write, parse or modify programatically. I agree that a config structure should have good programmatic access, but to my mind that's an argument for using a language with a good metamodel rather than anything else.

Re: Riemann – A network monitoring system

#57

Post by Cyph0n »

foolano wrote: post #31

Riemann is great. We use it at work. I like it so much that I did an experiment to implement it in C++ https://github.com/juruen/cavalieri My implementation sucks, but I had a lot of fun working on it and I got to learn how Riemann works better.

Good job on the README!

Re: Riemann – A network monitoring system

#58

Post by softawre »

Cyph0n wrote: post #57
foolano wrote: post #31

Riemann is great. We use it at work. I like it so much that I did an experiment to implement it in C++ https://github.com/juruen/cavalieri My implementation sucks, but I had a lot of fun working on it and I got to learn how Riemann works better.

Good job on the README!

No joke.

Re: Riemann – A network monitoring system

#59

Post by falcolas »

lmm wrote: post #56
falcolas wrote: post #50

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. With my programmer's hat on, they're also harder to populate programmatically, so I have a hard time justifying their use.

> 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 to break out of the sandbox, but it's the difference between giving the thief a set of master keys and $50 for a U-Haul and making them work to enter every safe you have on the premises.

/me takes off the tinfoil hat

Post reply on HN