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

61–70 of 83 posts

Re: Monitors.txt - lazy webapp monitoring

#62

Post by [deleted] »

eCa wrote: post #26
politician wrote: post #18

Earlier quoted context omitted.

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?

Believe it or not, VisualBasic (and every built in function) in Excel is translated in localized versions, and of course the English keywords are not kept. It's a mess.

[deleted]

Re: Monitors.txt - lazy webapp monitoring

#63

Post by eliot_sykes »

Big thanks to HNers for the encouraging feedback. Based on it I'm going to:

- Put some monitors.txt examples in JSON, YAML, Gherkin and XML up on http://monitorstxt.org to help get the syntax right and satisfy the majority of language preferences. Feedback/contributions welcome, fork on github here: https://github.com/eliotsykes/monitorstxt

- Continue work on prototype monitoring app, with support for the above formats

- Open up the prototype to interested devs

Re: Monitors.txt - lazy webapp monitoring

#64

Post by prodigal_erik »

fleitz wrote: post #50

English is an incredibly crappy language for writing tight specs in. The only appeal of english as a programming language is that people who cut big checks speak it. It's completely inappropriate for expressing formal logic. The problem is when people think "Hey, I have a computer science problem. I know, I'll express that problem in English!" and now they have two problems

Only until they "parse" the English using regexes. Then they have three problems. Four if you count "there are lots of trivial variations on the correct English phrasing, but none of them work, so you have to refer to the exact grammar anyway, this just made it bulkier."

Re: Monitors.txt - lazy webapp monitoring

#65

Post by delano »

cheald wrote: post #49

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…

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

Re: Monitors.txt - lazy webapp monitoring

#66

Post by cheald »

delano wrote: post #65
cheald wrote: post #49

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…

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

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

Re: Monitors.txt - lazy webapp monitoring

#67

Post by debaserab2 »

icebraining wrote: post #54
cheald wrote: post #49

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…

Exposing 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?

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

Re: Monitors.txt - lazy webapp monitoring

#68

Post by prodigal_erik »

"Should see the page assets" is kind of vague. You don't want to get 3 AM alerts because somebody else's transcluded widget is slow, if you can't do anything about it and the page is usable without it anyway. You probably want to distinguish your resources and third parties which may or may not have their own monitors.txt, as well as your resources that are expected to be slow because they're not static.

And is this presuming a headless browser? There are a lot of poorly-authored documents which blow up if their js can't get certain resources, even though the URLs don't appear in the markup where a scraper would see them. I'm all for having a pure-HTML mode that always works, because that's basic competence, but I'd want my progressive enhancements monitored as well at a lower priority.

Re: Monitors.txt - lazy webapp monitoring

#69

Post by lparry »

jebblue wrote: post #53
nicpottier wrote: post #48

Why make it human readable? Especially if you want lots of providers to support it, pick something super easy to parse.. JSON is the obvious choice there: [{ method: "GET", url: "index.html", tests: [ contains: "nyaruka", response_in_ms: 500, status: 200 ] }, { method: "POST", url: "login.html", params: { foo: "bar" } tests: [ "status": 200 ] }]

JSON is harder to read than XML, to my human eyes.

Wow, first time I've ever heard someone say that. Most people I know think XML is horrid to read, myself included. I'd take json or yaml over XML any day

Re: Monitors.txt - lazy webapp monitoring

#70

Post by merlincorey »

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…

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.

Post reply on HN