AWS CloudWatch Synthetics Canary
Synthetic monitoring — often
called synthetic canaries — is your system’s way of sending fake users through your
application to make sure everything is working, even when no real users are
around. It’s proactive, predictable, and designed to catch issues before
customers feel the pain.
Synthetic monitoring is automated, scripted traffic that
runs on a schedule to test your application’s key flows.
A “synthetic canary” is simply:
A small, automated script that runs repeatedly to detect problems
early — like a canary in a coal mine.
It’s not tied to deployments. It’s not real user traffic. It’s not
a canary release.
It’s a monitoring probe.
Creating Canary in AWS:
I am going to configure canary for this demo endpoint
Click on “Create Canary”.
Select “Heartbeat monitoring”.
If you would like to save the screenshot of the output to a S3 bucket, enable the
checkbox.
Select the regions from where API must be tested.
Select the “Script editor”.
Above is the canary script that gets automatically created.
Select the schedule to run the canary.
Select the “Timeout” if needed.
Finally, click “Create Canary”.
It takes ~ 5 mins to create canary.
Wait for the canary to move from “Starting” to “Running” state.
We could see the “Last Run Status” as Passed. Which shows our canary
is working fine.
Duration to perform the last canary was 462 ms.
Behind the scenes, it creates a lambda function which is invoked
via event bridge rule to perform the test.
Why are we having 2 lambdas?
We are doing canary via 2 browsers “Chrome” and “Firefox”. Hence, we see two lambdas.
Let’s look at the CloudWatch Metrics:
Looking at the output of the S3 bucket:

Comments
Post a Comment