lambda-ping
lambda-ping copied to clipboard
Check response code & latency of remote endpoints and graph in CloudWatch
Lambda Ping
Lambda Ping is a small service which checks the HTTP response code and latency for one or more supplied endpoints. It returns this data both directly in the form of a JSON object that can be consumed by other applications, as well as saving the results to CloudWatch.
Because the data is in CloudWatch, you can use the results to trigger other events when an endpoint fails/recovers or performs too slowly by creating CloudWatch Alarms with the metrics recorded. For example, it becomes very easy to send alerts on endpoint health, trigger another Lambda or consume the alarm with another AWS service such as Route53 failover.
How it works
Once supplied with a JSON list of HTTP or HTTPS endpoints, this Lambda hits them concurrently and returns the status code and total query time. We take advantage of NodeJS's callback model to allow easy concurrent execution when running the tests, so the Lambda only runs for as long as it takes for the slowest query to complete. A max timeout of 10 seconds applies.
Why not ICMP?
Sadly there is no way to do ICMP pings from inside AWS Lambda currently - the
main issue is that the container environment that Lambdas run inside of lacks
the CAP_NET_RAW
capability needed to allow an application to use raw sockets.
There's no way around this, even trying to use the command line ping
utility
inside the Amazon Linux container the Lambda runs inside of won't work.
The annoyance of course is that this means anything you want to monitor needs to be running a webserver of some kind. It doesn't have to be a full-blown installation of Apache, you could use one of the many higher languages to make a one line web server or if you get really desperate, here's one in C code.
This sucks, I want better metrics
If you're really serious about your monitoring and metrics, you probably want to look at something like Smokeping which has much better stats and graphing for the purpose of packet loss and latency than this Lambda will ever be capable of with CloudWatch graphs.
Installation
The application can be deployed following the standard Serverless Framework
procedures. For example, to deploy a prod
instance
to ap-southeast-2
:
serverless deploy --stage prod --region ap-southeast-2
Usage
To use the Lambda manually, invoke the Lambda with a JSON object defining the endpoints as an array:
serverless invoke --stage prod --region ap-southeast-2 \
--function http \
--data '["http://www.google.com", "https://www.jethrocarr.com"]'
The function returns a JSON object with the results.
{
"http://www.google.com": {
"statusCode": 200,
"durationMS": 169.88141500001075
},
"https://www.jethrocarr.com": {
"statusCode": 200,
"durationMS": 6757.3228579999995
}
}
Generally you'll probably want to automatically ping the endpoints on a regular basis. To do this, create a CloudWatch event on a scheduled basis. This allows you to have complete flexibility over when and how frequently you execute your pings - for example, you might ping one endpoint every minute, whilst another might only need to be once an hour.
To do this, first install the Lambda as per the instructions above and modify the
CloudWatch Event Configuration
section in serverless.yml
.
...
memorySize: 128 # MB
timeout: 30 # seconds
# CloudWatch Event Configuration:
events:
- schedule:
name: lambda-ping-${opt:stage}-5min
description: 'Ping HTTP endpoints every 5 minutes'
rate: rate(5 minutes)
enabled: true
input:
- 'https://www.jethrocarr.com'
- 'https://www.google.com'
Or you can manually create a new CloudWatch event by:
- Access the CloudWatch Events console.
-
Create Rule
- Select the
Schedule
option forEvent Source
. - Choose your desired rate of execution.
-
Add Target
. It should default toLambda Function
. - Select the
ping-STAGE-http
Lambda from the dropdown. - Configure input to use
Constant (JSON text)
- Add the array of endpoints to test on this schedule.
For example:
["http://www.google.com", "http://github.com"]
You can create as many rules as you want, on as many different schedules as you want. Note that is is more cost effective to test as many endpoints using the fewest rules possible, since all endpoints in a single rule get tests concurrently reducing our Lambda's execution time.
Contributions
All manner of contributions are welcome in the form of a Pull Request.
License
Copyright (c) 2017 Jethro Carr
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.