Monitors.txt - lazy webapp monitoring • Hacker News Board

Re: Monitors.txt - lazy webapp monitoring

#11

Post by gojomo » Sat, Nov 05, 2011, 6:30 PM UTC

Interesting idea. The proliferation of convention-dictated top-level URLs offends the design sense of many web architects. Possible alternatives are to:

• shoehorn a pointer to a varying URL inside an existing convention-dictated place – as for example with sitemap pointers inside robots.txt files.

• let the resource live anywhere but specify its location to consuming services via some out-of-band mechanism. That is, you still have to tell any monitoring provider where your particular monitoring-spec lives, probably via its signup interface, but you can still use the same format and unmoving file with multiple providers.

Re: Monitors.txt - lazy webapp monitoring

#12

Post by rednaught » Sat, Nov 05, 2011, 6:31 PM UTC

nikcub wrote: post #10

I thought this was going to be as easy as 'if you can't reach /monitors.txt, then the site is down' but seriously, does nobody else see a problem with your monitoring configuration being hosted on the site being monitored? It is a bit like asking a hospital patient to keep an eye on his own charts and to let you know if anything goes wrong .. do people really switch monitoring companies often enough to justify having…

It is meant to be used mostly as a configuration tool for the monitoring host. If the developer has recently updated/deployed then they are probably working on the site and can ensure monitors.txt is available.

Re: Monitors.txt - lazy webapp monitoring

#13

Post by gojomo » Sat, Nov 05, 2011, 6:32 PM UTC

nikcub wrote: post #10

I thought this was going to be as easy as 'if you can't reach /monitors.txt, then the site is down' but seriously, does nobody else see a problem with your monitoring configuration being hosted on the site being monitored? It is a bit like asking a hospital patient to keep an eye on his own charts and to let you know if anything goes wrong .. do people really switch monitoring companies often enough to justify having…

Seems like a service would want/need to cache older versions of monitors.txt, and continue running them for some configurable persistence period before accepting a missing/new/possibly-malicious monitors.txt as giving a true read.

Re: Monitors.txt - lazy webapp monitoring

#14

Post by eliot_sykes » Sat, Nov 05, 2011, 6:33 PM UTC

nikcub wrote: post #10

I thought this was going to be as easy as 'if you can't reach /monitors.txt, then the site is down' but seriously, does nobody else see a problem with your monitoring configuration being hosted on the site being monitored? It is a bit like asking a hospital patient to keep an eye on his own charts and to let you know if anything goes wrong .. do people really switch monitoring companies often enough to justify having…

Lol yes I'll add something on this to the site...

My thoughts are the monitoring provider would keep a copy of monitors.txt and work from that, and check for changes regularly. If they can't get to monitors.txt that would trigger an alert.

Re: Monitors.txt - lazy webapp monitoring

#15

Post by politician » Sat, Nov 05, 2011, 6:34 PM UTC

eliot_sykes wrote: post #7

So far people seem to like the idea, but not so keen on cucumber for the language. Please contribute any pseudo code ideas below as I want to get this right

Honestly, I like the cucumber format, but what you ought to do is publish an API of phrases so that monitoring providers can target a standard set of monitoring operations. Right know, I don't see how they can execute a generic spec as described.

Re: Monitors.txt - lazy webapp monitoring

#16

Post by gojomo » Sat, Nov 05, 2011, 6:35 PM UTC

eliot_sykes wrote: post #7

So far people seem to like the idea, but not so keen on cucumber for the language. Please contribute any pseudo code ideas below as I want to get this right

Something Javascript-based might work. Perhaps the site-wanting-monitoring supplies a collection of JS scripts to run, each of which will be provided a standard object providing assertions/conclusions/reporting about specific features/URLs/scenarios.

Re: Monitors.txt - lazy webapp monitoring

#17

Post by bmurphy » Sat, Nov 05, 2011, 6:37 PM UTC

eliot_sykes wrote: post #4

crawshaw wrote: post #2

Brilliant. Given the target audience, I think a more concise description language that pseudo natural language would work better. Regardless, such a service can bring basic alerting to the huge number of sites which currently have nothing.

Thanks for the feedback. I'd love to hear any ideas on language alternatives.

I agree with the parent. Something very simplistic in json or yaml would be preferred.

Re: Monitors.txt - lazy webapp monitoring

#18

Post by politician » Sat, Nov 05, 2011, 6:39 PM UTC

kanwisher wrote: post #5

Really love the idea of text file based monitoring, hate the cucumber interface. I stomach it in rails but I'm not a big fan of English in my code

I'm curious about this -- don't you use APIs which use largely, if not universally, English identifiers? Or is there a version of, say, the .NET Framework where the API itself is written in French, German, or Spanish? Or what language has a custom parser for each language so that you can write keywords ("if", "for", "do") in your native language?

Re: Monitors.txt - lazy webapp monitoring

#19

Post by eliot_sykes » Sat, Nov 05, 2011, 6:41 PM UTC

politician wrote: post #15

eliot_sykes wrote: post #7

So far people seem to like the idea, but not so keen on cucumber for the language. Please contribute any pseudo code ideas below as I want to get this right

Honestly, I like the cucumber format, but what you ought to do is publish an API of phrases so that monitoring providers can target a standard set of monitoring operations. Right know, I don't see how they can execute a generic spec as described.

Cucumber devs might not like this, but at the moment I'm taking cues for the API phrases from cucumber-rails-training-wheels (web_steps.rb for capybara) - I see why the devs wanted it removed, but it works great for something like this that needs wide support.

Re: Monitors.txt - lazy webapp monitoring

#20

Post by eliot_sykes » Sat, Nov 05, 2011, 6:44 PM UTC

gojomo wrote: post #11

Interesting idea. The proliferation of convention-dictated top-level URLs offends the design sense of many web architects. Possible alternatives are to: • shoehorn a pointer to a varying URL inside an existing convention-dictated place – as for example with sitemap pointers inside robots.txt files. • let the resource live anywhere but specify its location to consuming services via some out-of-band mechanism. That is,…

I'm keen on your idea for an out-of-band mechanism, and would be needed for the obfuscated URL idea

"For the more gung-ho, obfuscate the URL and use SSL (e.g. https://yoursite.tld/something-unguessable/monitors.txt) and tell your provider where to find your monitors.txt"