3 ms·
I don't think I like this idea. * Exposing a "monitors.txt" is a potential security hole that reveals more about your infrastructure than you meant to. * Rest
by cheald 15y ago
I don't think I like this idea.
* Exposing a "monitors.txt" is a potential security hole that reveals more about your infrastructure than you meant to.
* Restricting monitors.txt to a given service (by htaccess IP restriction?) is brittle and gets you out of "write feature"-land and into "do sysadmin"-land, which you're trying to avoid anyhow.
* Cucumber is an unnecessary extra layer that doesn't do much besides just frustrate the user who has to write just the right English syntax to get what he wants. See also: Monit config definitions. The files read nicely once you get them configured, but it can be a downright bear to find out what just the right magic combination of keywords and phrases is to get it to do what you want.
* If you want client-side managed monitoring, why not have some interface to your chosen monitoring service that you invoke via your Cap deploy? That's something that you can make reality today, rather than waiting on service providers to implement it.
The concept of being able to define your monitoring as a part of your application and then just deploying it with the rest of the package is really appealing, but you still have to go tell monitoring services where to find your monitoring file, you still have to wait on monitoring services to implement support for it, and monitoring just isn't that difficult of a problem. How often do you change your monitoring rules?
- icebraining 15y agoExposing a "monitors.txt" is a potential security hole that reveals more about your infrastructure than you meant to. Everything you put in monitors.txt has to be publicly accessibly anyhow. What could is reveal that the actual website doesn't?
- cheald 15y agoNot true. I can have a service monitor "http://foo:bar@mysite.com/password/protected/endpoint/ http://foo:bar@mysite.com/password/protected/endpoint/ or "http://mysite.com/protected?auth_token=2caf5e77cfa057ad2f36e6fafd2b95787dd5a5edfdbeae8f73a5f7a7f892fb0a5f83d http://mysite.com/protected?auth_token=2caf5e77cfa057ad2f36e... just fine. Passwords are security by obscurity, sure, but putting them in a world-readable file at a common known location is the height of ridiculous.
- icebraining 15y agoThen you can put monitor.txt behind that password protected endpoint too. My point is that whoever you need to give access to the file also has access to the actual website, which has all the information (it has to, since it's supposed to be able to test against it).
- debaserab2 15y agoJust because it's all public does not mean I want one single source that in plain English (err.. cucumber?) defines key areas of my website that I want to ensure are always up. Seems to me this just gives potentials hackers a map to the public end points of my most important areas.
- delano 15y agomonitoring just isn't that difficult of a problem. Monitoring is a very difficult problem when you consider false positives, notifications (repetition, escalation etc), and reporting. Monitoring isn't just about whether a service is up or down. It's about the quality of that service right now and over time.
- cheald 15y agoI should have been more clear. Monitoring configuration isn't a very difficult problem. It doesn't change very often, and isn't difficult to set up with a decent UI. It's certainly not hard enough to require the establishment of a new standard.