101–109 of 109 posts
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. How so? Kafka is a stream processing engine that uses plain old Zookeeper data structures for config. Edit: Kafka also seems to have the missing features you mentioned if Riemann should be taken seriously as a general-purpose stream processing engine.
I'd also argue that Zookeeper nodes are anything but "plain" :)
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…
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.
Earlier quoted context omitted.
> The lack of a plugin system We have many ways to plugin to Prometheus across the ecosystem, the textfile collector you're using is one of them. > You can't run 23 different daemons, each on their own port, to collect stats from things like PostgreSQL stats or RabbitMQ. There's no fundamental challenge with this approach. If you've got good basic infrastructure, particularly configuration management, the rollout of…
> If you've got good basic infrastructure [...] We do have good basic infrastructure, thanks. We use Puppet and have a decent deploy system that performs atomic deploys from Git. We also do think in terms of services. But the exporter has to run somewhere. About half of our exporters are machine-specific (reads local stats from files or proc or whatever), about half run on the Prometheus node itself and talk to servi…
If there's useful stats from /proc we're missing, we accept PRs.
> about half run on the Prometheus node itself and talk to services like ElasticSearch or Postgres.
That doesn't sound right, those two should run on the ES/Postgres nodes.
Only things like the blackbox exporter and snmp exporter should be considered for running beside Prometheus.
> When I have time, my plan is to write a small HTTP server that spawns plugin as subprocesses that emit their metrics via stdout, which seems like a much more reasonable, low-maintenance solution, and something node_exporter ought to support in the first place.
We went with the textfile collector approach, rather than reinventing cron.
How does a system like this differ from say, the ElasticSearch+Logstash system?
Earlier quoted context omitted.
Functional means different things to different people. By all means learn Clojure, but also learn a functional language with a first-class type system (e.g. Haskell).
Ah, Haskell. I find it equal parts fascinating and scary. I definitely won't start at Haskell, although I would surely want to come to it at some point of time. Static typing looks nice.
But yeah, there's the Lisp tradition and the typed tradition and they're almost entirely separate, but through accidents of history we call them both "functional". So in the same way that you'd learn an OO language and a functional language, I'd say it's worth learning one of each.
Earlier quoted context omitted.
> If you've got good basic infrastructure [...] We do have good basic infrastructure, thanks. We use Puppet and have a decent deploy system that performs atomic deploys from Git. We also do think in terms of services. But the exporter has to run somewhere. About half of our exporters are machine-specific (reads local stats from files or proc or whatever), about half run on the Prometheus node itself and talk to servi…
> (reads local stats from files or proc or whatever) If there's useful stats from /proc we're missing, we accept PRs. > about half run on the Prometheus node itself and talk to services like ElasticSearch or Postgres. That doesn't sound right, those two should run on the ES/Postgres nodes. Only things like the blackbox exporter and snmp exporter should be considered for running beside Prometheus. > When I have time,…
> rather than reinventing cron.
But Prometheus already has a job interval setting. With text files emitted with cron jobs, you get the silly effect where metrics are produced at intervals which don't correspond with the job interval.