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

51–60 of 83 posts

Re: Monitors.txt - lazy webapp monitoring

#51

Post by fleitz »

politician wrote: post #18
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?

When you specify and equation do you use english or mathematical notation?

five times twenty divided by three to the power of twenty eight is a lot harder to understand, much less defined than:

(5*20/3)^28

Also, most imperative languages are crap because of the very tight name binding and difficulty in aliasing as well as insanely large number of unnecessary keywords.

In many functional languages if you speak spanish simply put:

let si = if

and voila you don't have silly keyword issues. (Yes, you can't redefine let easily, but it's a far better situation than the keyword smorgasbord that most imperative languages have)

Cucumber solves the problem of: "My manager with an MBA can't read my unit tests" and exchanges it for the problem of "Programmers don't know what the fuck the test does"

Re: Monitors.txt - lazy webapp monitoring

#52

Post by [deleted] »

eliot_sykes wrote: post #33
CJefferson wrote: post #32

Earlier quoted context omitted.

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.

[deleted]

Re: Monitors.txt - lazy webapp monitoring

#53

Post by jebblue »

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.

Re: Monitors.txt - lazy webapp monitoring

#54

Post by icebraining »

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?

Re: Monitors.txt - lazy webapp monitoring

#55

Post by eliot_sykes »

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.

Maybe need to support JSON, XML, and YAML.

Re: Monitors.txt - lazy webapp monitoring

#56

Post by cheald »

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?

Not true. I can have a service monitor "http://foo:bar@mysite.com/password/protected/endpoint/ or "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.

Re: Monitors.txt - lazy webapp monitoring

#57

Post by icebraining »

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 ] }]

I rather use YAML:

    - 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

Re: Monitors.txt - lazy webapp monitoring

#58

Post by icebraining »

cheald wrote: post #56
icebraining wrote: post #54

Earlier quoted context omitted.

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?

Not true. I can have a service monitor " http://foo:bar@mysite.com/password/protected/endpoint/ or " 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.

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

Re: Monitors.txt - lazy webapp monitoring

#59

Post by sylvinus »

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.

depends if it's pretty printed or not (like the example above)
Post reply on HN