Using Watcher to check if Web service API is up

Elastic Stack Elasticsearch
1

Hi,

My application has a ping url that returns a HTTP status of 200 if the application is working correctly. I'd like to add a watcher action usinghttp input that monitors this url and alerts me via email if anything other than 200 is returned. Is this possible with http input?

I tried to check if the ctx.payload is empty when the application is down but it looks like when the http url is unavailable, any condition defined on the watch is not executed? I set a repsonse and read timeout value of 5s. Also is there a way to look at the HTTP response code through the Watcher execution context? I wasn't able to find a way listed in the documentation.

I'm using X-Pack 5.0.0 alpha4 release
Thanks,
Vinayak

2

Can you provide the watch that you currently have?

3

Hi Mark,

Sorry for the late reply. I tried a couple of different watch conditions with different painless scripts including the one below. Even if I just had a painless script of "return true", the email action wasn't executed when the server I was trying to ping was shut down. The "return true" worked when the server I was pinging was online:

PUT _xpack/watcher/watch/watch_system_availibility
{
  "trigger": {
    "schedule": {
      "interval": "10s"
    }
  },
  "input": {
    "http" : {
    "request" : {
      "host" : "x.x.x.x",
      "port" : 8080,
      "path" : "/<contextpath>/ping"
    }
  }
  },
  "condition": {
    "script": {
          "lang": "painless",
          "inline": " if(ctx.payload===null) return true; else return false;"
        }
  },
  "actions": {
    "send_email": {
      "email": {
        "from": "'xxx <xx@example.com>'",
        "to": "'abcd<vxxx.xxxxx@xxxxxxxxxxxxx.com>'",
        "subject": "<subject>",
        "body": "Server is not responding and appears to be stopped"
        
      }
    }
  }
}
4

Hey,

indeed you cant check for the HTTP response code right now, but I think that is a good feature to add. We could just add it to the payload as well, as we did with the headers in 5.0.

Do you have any header that only occurs if the request is valid, which you could use as a workaround?

--Alex