marbot, our submission to the AWS Serverless Chatbot Competition
Three things Michael and I love to do most: prototyping innovative products, playing around with the latest technology and learning new things. That is why we decided to take part in the AWS Serverless Chatbot Competition. We’d like to introduce marbot, our chatbot, to you and share the backstory of its creation.
The AWS Serverless Chatbot Competition started on August 10 with the following conditions:
Create a working bot for Slack that runs on AWS Lambda. Applications must use AWS Lambda and Amazon API Gateway for bot logic and integration. Applications cannot be hosted on any other hosting platform. Use of Slack APIs, such as the Slack Events API, is encouraged but not required.
On top of that AWS provided the following submission recommendations:
- Integrate Slack APIs, such as the Slack Events API
- Utilize additional AWS services
- Submit application to the Slack App Directory
- Showcase natural language processing of chat conversations
But what to build?
Working as DevOps engineers in various teams we have always been looking for a tool to share on-call duty among many shoulders without the need for organizational overhead. We came up with the idea of building a chatbot to combine Amazon CloudWatch with Slack.
We defined the following feature set as minimum viable product:
- Receiving alerts from Amazon CloudWatch via Amazon SNS
- Escalating alerts if a team member isn’t acknowledging within 5 minutes
- Managing alerts by accepting, passing or closing them
- Analyzing alerts in a daily summary
- Grouping alerts with a dedicated alarm gateway for each channel
How did we implement the chatbot?
The following figure is showing an architectural overview of marbot. We used a bunch of services and APIs.
Find the blind spots in your AWS monitoring!
Setting up monitoring on AWS is hard. AWS provides countless features and sources of events. Overlooking the important settings is easy. Our prioritized checklist includes all parts of a basic monitoring setup for AWS. Additionally, use our mind map to map your monitoring goals to AWS services. Download Free Monitoring Checklist + Mind Map!
The diagram was created with Cloudcraft - Visualize your cloud architecture like a pro.
Are you interested in the details? Read on!
The Serverless Framework simplified the provisioning and deployment of all the resources needed to setup the environment.
We used the API Gateway and Lambda for creating our backend and implemented endpoints for incoming events from Slack as well as from CloudWatch via SNS.
DynamoDB is our favorite NoSQL database on AWS. marbot is storing channel endpoints, alarms together with their escalation state, and Slack authentication credentials.
To provide daily team statistics marbot is analyzing event data with the help of Kinesis Streams and Kinesis Analytics. The statistics generated by Kinesis Analytics include the number of received alarms, time to acknowledge, time to close and much more.
marbot needs to escalate alarms to the next level if a team member is not responding. We implemented the needed scalable timer with SQS and Lambda. The solution is similar to what I’ve already described in Integrate SQS and Lambda: serverless architecture for asynchronous workloads.
All you have to do as a marbot user is to send your CloudWatch alarms to an SNS topic. The SNS topic is then forwarding the alarm to the marbot backend.
No EC2 instances needed. The whole architecture relies on highly available and scalable AWS services.
marbot is accessible to the public and free to use. More and more teams are using marbot to connect Amazon CloudWatch and Slack to spread alerts among their team members.
Try marbot now! We are looking forward to your feedback.