Implementing AWS CloudWatch Synthetics for Real-Time Application URL Monitoring

Hello Medium Readers,

I’m nearing the culmination of my DevOps learning journey, and today marks the penultimate post in my plan to delve deeper into DevOps. In this installment, I’m excited to explore two new services within AWS: AWS CloudWatch and AWS Chatbot.

In this iteration, I’ve replicated the deployment process detailed in a previous post. The aim this time around isn’t to develop something entirely new, but rather to establish alerts for monitoring the application’s status using CloudWatch. In the event of failures, I’ll be configuring AWS Chatbot to notify specific contacts. Let’s dive in.

Task of the day

In this hands-on project, I delved into the advanced features of AWS CloudWatch, with a particular focus on implementing CloudWatch Synthetics for real-time monitoring of application URLs. This involved integrating CloudWatch Alarms, SNS, and AWS Chatbot to facilitate immediate alerts via Slack. The objective was to establish a robust monitoring system for the HumanGov application, ensuring its high availability and performance.

As mentioned previously, the image below illustrates the services utilized to create the CloudWatch alarms and establish communication with external environments of AWS, specifically a Slack channel.

Services used in this implementation.

The proposed solution architecture closely resembles that outlined in my last two posts, found here and here. The additions are highlighted on the right side of the image below, incorporating CloudWatch and AWS Chatbot. Now, let me guide you through the process of setting up these components.

Solution Architecture proposed.

Implementation

CloudWatch

After the application deployment is complete, I navigate to the CloudWatch console and access the “Application Signals” section, specifically selecting “Synthetics Canaries.” The concept of Canaries draws its inspiration from the mining industry, where these birds were historically employed to warn miners of changes in the mine environment. For instance, if there was a presence of undetectable gas, the canaries would succumb. AWS has adopted this concept, creating its own version known as Synthetics Canaries.

The premise remains the same, albeit without the grim connotations. Within CloudWatch, Synthetics Canaries serve to alert Site Reliability Engineers (SREs) about the application’s status. They essentially “visit” your application and capture application logs. Upon accessing this section in the console, here’s what you’ll encounter.

Creating Synthetics Canaries Overview.

So, currently, I don’t have any canaries set up. Clicking on “Create Canary” will open a new view where you can begin configuring your canary. Canaries have a wide range of capabilities, and I’ve only scratched the surface. Below, I’ll outline the options I selected. It’s worth noting that I opted for Heartbeat monitoring, where your application is monitored just like a user would interact with your web application.

Create Synthetic Canaries, Part I.

In the Canary builder, you can give a name to your new “pet” and provide the endpoint URL of your application that needs monitoring. I also enabled the “Take screenshots” option, which proves valuable because in the event of a failure, you’ll see the same image as a user would. However, it’s important to note that if a failure occurs between the “heartbeat” checks of the canary, CloudWatch won’t be able to detect it. Other options, such as the Script editor, exist but are beyond the capabilities of the free tier, so we’ll leave them as they are.

Create Synthetic Canaries, Part II.

The third part of the setup is the Schedule, which is incredibly important. I opted for a continuous schedule, set to run every 5 minutes, starting as soon as the creation process is completed. However, as depicted in the image, there are other scheduling options available. If you require specific configurations, the CRON expression feature is there to accommodate those needs.

Create Synthetic Canaries, Part III.

In the final part of my configuration, I set up the permissions. The Canary automatically generated a new role in IAM, and I proceeded to create a CloudWatch alarm, as depicted in the image below. Additionally, I activated notifications by creating an SNS topic specifically for this purpose. In this post, I demonstrated how to create a topic using an SNS topic.

Create Synthetic Canaries, Part IV.

After completing these steps, proceed with the confirmation and wait for the canary creation process to finish. Do not close the page during this time. If everything has been configured correctly, you will eventually see an image like the one below.

Created Synthetic Canaries Overview.

Slack’s integration

The next step is a bit more complex than the first one. Before delving into Chatbot configuration, it’s essential to have access to a Slack workspace where you have permissions to add integrations. If you don’t already have access, don’t worry — you can easily create a new workspace for free on the Slack website. Once you’ve completed the workspace creation, you’ll need to create a channel. I chose to name mine “sre-team.” If all steps were completed correctly, you’ll see an image similar to the one below.

Slack’s workspace and channel created.

After creating the workspace and channel, navigate to channel configuration and proceed to integrations. You’ll encounter the view depicted in the image below.

Slack’s channel configuration.

You can click on “Add an App,” and the following image will appear. From there, search for AWS Chatbot, and the option to install will become available for you.

Slack’s integration app view.

AWS Chatbot

Now, let’s return to AWS Chatbot. Navigate to the AWS console and search for AWS Chatbot. Once the page loads, you can select the type of chat client you want to configure, in this case, Slack.

AWS Chatbot “Get start” screen.

Once you click it, the next page will display as shown below. I opted to name the configuration the same as the channel in Slack, although this is optional. Following that, I selected the Channel type and provided the name of the channel, which must match exactly.

AWS Chatbot Configure Slack channel view.

You can proceed to create, and a new page will open to request your permission to allow AWS to connect with your Slack channel. If you are logged in using the same browser, simply click on “Allow.”

AWS request connection to Slack workspace

Once the stage is completed, you will be redirected to the configured client’s page, where you will be able to see if your Workspace is configured correctly. You can click on it to send a test message. Open the channel in your Slack workspace, and you’ll see a test message similar to the one below.

Slack’s channel test message.

Simulated failure

The final stage of the deployment involved simulating a failure, which I achieved by deleting the Kubernetes deployment, scaling the number of replicas to zero. Within minutes, I received an error message in my “sre-team” channel on Slack, as depicted in the image below, thus concluding this successful deployment powered by CloudWatch, Chatbot, and SNS.

Slack’s channel error message.

Conclusion

Implementing AWS CloudWatch Synthetics for real-time application URL monitoring involves setting up canaries in CloudWatch to monitor application URLs, configuring schedules for monitoring, and creating CloudWatch alarms for alerting.

Integrating Slack with AWS Chatbot allows me receiving notifications in Slack channels. To test all these configurations, involved simulating failures to ensure alerts are triggered correctly. At the end, this deployment demonstrates the effectiveness of AWS services in monitoring application health and facilitating real-time responses to issues.

I hope you liked, follow me to stay updated on the next posts.