Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monitors.txt - lazy webapp monitoring

monitorstxt.org

Post reply on HN
Print view View original

31–40 of 83 posts

Re: Monitors.txt - lazy webapp monitoring

#31

Post by tptacek »

inconditus wrote: post #25

Interesting idea, I'm not so sure I agree about "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'. http://en.wikipedia.org/wiki/Security_through_obscurity

If "something unguessable" is a 64 bit number from /dev/random, and it's disclosed only to monitoring providers, and indexes are turned off on the server, it's not "security through obscurity"; it's a key.

Virtually every web app in the world relies on a similar security system. You just don't notice, because we call the "key" in those systems a "cookie", not a "dynamic URL path component".

There are reasons why the URL key is inferior to other keys used by web applications, but they are fiddley. If monitors are unlikely to have extremely sensitive information in them (and you'd hope they wouldn't given their intent), it's fine to use URL keys.

Re: Monitors.txt - lazy webapp monitoring

#32

Post by CJefferson »

eliot_sykes wrote: post #9
rednaught wrote: post #8

Fantastic idea. I see humans.txt ( http://humanstxt.org/ ) was an influence. Why not stay in a concise format like that?

I've not been able to figure out an alternative to cucumber that has the same flexibility and readability. For example, I've not a clue yet on how to improve on this example: Feature: DuckDuckGo Search It should continue to kick ass And I should be able to search Scenario: Homepage performance When I go to http://www.duckduckgo.com Then I should see the page downloaded in less than 0.5 seconds And I should see the pa…

The problem is that this looks tempting, but what if I change:

    Then I should see the page downloaded in less than 0.5 seconds
to

    Then I want the page to download in under a second.
The natural English looks very tempting, but the actual terms you can use are very restrictive.

Re: Monitors.txt - lazy webapp monitoring

#33

Post by eliot_sykes »

CJefferson wrote: post #32
eliot_sykes wrote: post #9

Earlier quoted context omitted.

I've not been able to figure out an alternative to cucumber that has the same flexibility and readability. For example, I've not a clue yet on how to improve on this example: Feature: DuckDuckGo Search It should continue to kick ass And I should be able to search Scenario: Homepage performance When I go to http://www.duckduckgo.com Then I should see the page downloaded in less than 0.5 seconds And I should see the pa…

The problem is that this looks tempting, but what if I change: Then I should see the page downloaded in less than 0.5 seconds to Then I want the page to download in under a second. The natural English looks very tempting, but the actual terms you can use are very restrictive.

Thinking monitors.txt would need a validator, plus the monitoring providers can alert customers when they've entered something invalid.

Re: Monitors.txt - lazy webapp monitoring

#34

Post by delano »

I like the idea. What about if the definition was in the form of HTTP requests, something like:

    GET /

    GET /login

    POST /login
    user={{CUSTID}}&pass={{PWORD}}

    GET /search?q={{QUERY}}
The monitors.txt file could contain pointers to the definition files (one file per usecase), ideally with arbitrary metadata.

If there's some kind of consensus, now or later on, I'll implement it in our monitoring service (blamestella.com).

Re: Monitors.txt - lazy webapp monitoring

#35

Post by eliot_sykes »

delano wrote: post #34

I like the idea. What about if the definition was in the form of HTTP requests, something like: GET / GET /login POST /login user={{CUSTID}}&pass={{PWORD}} GET /search?q={{QUERY}} The monitors.txt file could contain pointers to the definition files (one file per usecase), ideally with arbitrary metadata. If there's some kind of consensus, now or later on, I'll implement it in our monitoring service (blamestella.com).

Thanks for the psuedo code and the consideration of implementing it if there's consensus, much appreciated.

I'm working on implementing monitors.txt for my own sites and will open it up to a few devs to get the API sculpted just right. After then I hope they'll be other monitoring services as keen as blamestella to have a go at it.

Re: Monitors.txt - lazy webapp monitoring

#36

Post by mseebach »

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…

> but seriously, does nobody else see a problem with your monitoring configuration being hosted on the site being monitored?

So, if the file is unreachable, something is probably very very wrong.

Malicious changing of the file could be addressed by firing an alarm when the file changes.

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

No, it's a bit like leaving the chart with the patient, trusting that he won't destroy it.

> do people really switch monitoring companies often enough to justify having a standard configuration format?

Do people really switch monitoring companies rarely enough to justify keeping a myriad of incompatible configuration formats?

This also has the benefit of you owning all of your own data.

> ps. cucumber syntax is horrible because it perpetuates a 'everybody speaks english' view of the world

Cucumber syntax is great because a lot of people are already used to it. Oh, and it's completely language independent too. https://github.com/cucumber/cucumber/tree/master/examples/i1...

Re: Monitors.txt - lazy webapp monitoring

#37

Post by mseebach »

eliot_sykes wrote: post #20
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"

Another approach could be to support HTTP Basic auth.

Re: Monitors.txt - lazy webapp monitoring

#38

Post by huhtenberg »

Ah, that sort of monitoring... I was hoping it'd be something like a sitemap with pages' timestamps, so that monitoring sites like http://www.followthatpage.com wouldn't need to poll actual pages and needlessly pollute my access.log (completely disrespecting robots.txt along the way).

Re: Monitors.txt - lazy webapp monitoring

#39

Post by ricardobeat »

I'd much rather have something akin to an appcache.manifest file:

    # monitors.txt - see http://monitorstxt.org for more info

    GET:
        http://monitors.txt
        http://otherservice.monitors.txt
    
    POST:
        http://monitors.txt/service q:lalala user:trololol
        http://monitors.txt/service2 id:250
    
    RESOLVE:
        monitorstxt.org 207.97.227.245
    
    PERFORMANCE:
        http://duckduckgo
IMO feature testing should be part of your test suite pre-deploy, not the monitoring service.

Re: Monitors.txt - lazy webapp monitoring

#40

Post by eliot_sykes »

ricardobeat wrote: post #39

I'd much rather have something akin to an appcache.manifest file: # monitors.txt - see http://monitorstxt.org for more info GET: http://monitors.txt http://otherservice.monitors.txt POST: http://monitors.txt/service q:lalala user:trololol http://monitors.txt/service2 id:250 RESOLVE: monitorstxt.org 207.97.227.245 PERFORMANCE: http://duckduckgo IMO feature testing should be part of your test suite pre-deploy, not the…

Thanks for the suggestion, I like how succinct it is.

monitors.txt's purpose isn't to replace testing new features during development. Monitors.txt replaces the process of logging on to a 3rd party's app to configure the monitoring for the new feature.

Post reply on HN