Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 < 2s
        http://duckduckgo/images < 3s
IMO feature testing should be part of your test suite pre-deploy, not the monitoring service.


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.


This syntax seems a lot less confusing and more powerful than the subset of English presented.

Another bit of syntax that I think is missing is something like:

GUAGE:

  http://domain/stats/logins 60s
COUNTER:

  http://domain/stats/logins 60s
AVG:

  http://domain/stats/logins 24h
Something like this would allow you to setup not only with simple external monitoring systems, but with internal systems like Nagios, Ganglia, ZenOSS, etc.

Of course, I do have to agree with many people that I am a bit uneasy PUBLISHING all of this data for all to see.


Interesting, incorporated this into the YAML sample: https://github.com/eliotsykes/monitorstxt/blob/gh-pages/moni...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: