Integrate uptime testing

[jpike88]

https://github.com/streaka/lambda-ping

The problem is there is no 'uptime' metric naturally occurring on cloudwatch. It would be nice to package with this an optional lambda function that pings on a fixed schedule, making that available in cloudwatch for metric selection (and it can be a 'recommended metric' or something in the UI).

I'm using the above script to add 'uptime' metrics and whatever else might be handy... i'll see if I can integrate this in.

Could you make me a contributor and I can publish on another branch instead of a fork?

[jpike88]

My metrics now look like this, it's really handy. Bear in mind that I'm using two different urls for uptime of two different components... so you would need to be able to specify multiple URLs for this purpose

[ks888]

Thank you for your suggestion! Uptime checks are certainly an attractive feature, but I don't feel like supporting it as the feature of LambStatus.

• LambStatus is the status page system and its main purpose is to provide your service's current status. Monitoring features such as uptime checks are a little beyond the purpose.
• I think uptime checks themselves have several features. Some users may want customizable HTTP headers, other users may want some auth mechanism and others may want to match the text in the response body to check status. Rather than supporting them, it's simpler to integrate LambStatus with the existing uptime checks system like lambda-ping and mlavin/cloudping.

[jpike88]

Some counterpoints:

• While some users may want their 'uptime' metric to be based off a more advanced means, the health check that AWS ALB uses as well as AWS EB itself is based purely on status codes. So the ones that want to do something more advanced at least have a starting point that is packaged with LambStatus, for easy fork and testing. Also they always have the option to easily create another lambda function that can expose a URL as the health check URL, and have that function do the advanced logic that way. That way you have LambStatus -> Health Check 2xx -> Custom lambda function URL -> Custom checks.
• Also I think very few users will want/need to go beyond the 2xx check model, I think the more advanced checks are going to be quite few in number as most users would probably have adhered to the way AWS performs its health checks.
• LambStatus's main value is that it can be a one-click setup, with only the most minimum configuring needed. Uptime is usually the number one metric any status page would put on it as it's an easy metric to portray to users, from my experience it seems to be the bare minimum you'd have on any status page. While it's important that not to get carried away with extra features, I still think this would be worth integrating...

Of course, your repo, your rules :)