3 ms·
I am also pondering this problem literally right now, and working on it today. It's an issue with several of the new 'push' aka 'webhook' systems: user/key man
by doublerebel 13y ago
I am also pondering this problem literally right now, and working on it today. It's an issue with several of the new 'push' aka 'webhook' systems: user/key management is slim to none. Riemann server and dash setup is also cumbersome. Isn't the point of a monitoring server that I have to do less manual configuration and management?
Riemann is also a rather heavy server load just to push webhook events to a database. Requires some effort to scale. Godot (Node app that aims to be Riemann API-compatible) seems to be a better option for smaller scale operations.
Right now the solution for many CI and webhook servers is to push events to Hipchat. That does not seem to be the most reliable or efficient way to triage issues.
How are other small to midsize businesses (i.e. those without dedicated devops) managing this architecture?
- dbuxton 13y agoIt's not clear from your comment exactly what you're looking to do, but difficulty of configuration was more or less why we built Cabot (https://github.com/arachnys/cabot https://github.com/arachnys/cabot) internally for monitoring our infrastructure. However very possibly you're trying to do something more complicated.
- doublerebel 13y agoThanks! I skimmed the docs, but I'm not sure I see the strong differentiating qualities. Cabot seems to be a polling (not push) solution? Meaning that each service has to be manually set from within Cabot. I also see several settings are hand-set in the foreman environment. With Riemann/Godot, I can simply POST JSON (with any metrics) to the Riemann webhook from any number and type of services and servers. Riemann/Godot also make it easy to push data back out, to further analyze or aggregate. In a way, I'm looking for something less complicated -- a 1GB VPS should be overkill for a small instance. But I'd also like it to accept JSON POST from anything with a matching API key. And store it in a database not run on localhost. With this configuration it should be able to scale as the services scale. Cabot does make some good points about distributed infrastructure and external testing. Best wishes with the project!