Posted on Oct 23 Amazon Devops Guru for the Serverless applications - Part 4 Anomaly Detection on API GatewayIn the 1st part of the series we introduced the Amazon DevOps Guru service, described its value proposition, the benefits of using it and explain how to configure it. We also need to go through all the steps in the 2nd part of the series to set everything up. In the 3rd part of the series we saw DevOps Guru in action by generating the anomalies on the DynamoDB and explaining general capabilities of the DevOps Guru service. In this part of the series we'll generate anomalies on the API Gateway.There are mainly two kind of anomalies that we can experience with API Gateway : HTTP 4XX errors and HTTP 5XX errors. We'll see the latter in action when we provoke Lambda anomalies in the next part of the series. Let's take a look whether DevOps Guru can recognize HTTP 4XX errors as anomalies.There are several kind of such anomalies. We'll be looking at the following ones:HTTP 429 "too many requests" to API Gateway where it will throttle requests.HTTP 404 "not found error" in case we ask for not existing product id.Let's first look at HTTP 429 error. The easiest way to generate such errors with the lowest cost possible is to set low values to either Request Rate, Burst or Quota to the DevOpsGuruDemoProductAPIUsagePlan associated with our DevOpsGuruDemoProductAPI. Here is the example that we set Quota to 500 requests per dayNow let's do some stress test with hey toolWith this (sending 10 requests per second per container with 5 containers in parallel for 11 minutes) we'll exhaust 500 requests per day on API Gateway pretty quickly and then receive HTTP 429 as an response. DevOps Guru also recognized the anomaly as displayed in the image below.We see that DevOps Guru is the opinion that such an error has only medium severity (which I personally disagree)."Aggregated metrics" shows that "4XXError Average" was correctly recognized as a reason for the anomaly. Unfortunately it's the problem of the CloudWatch that it only displays the generic 4XX HTTP Error and not the concrete HTTP 429 error and DevOps Guru simply shows the CloudWatch graphs here. We'll need some help of the CloudWatch Logs to identify the exact error.And "Graphed Anomalies" shows the exact amount of throttled requests in the time range of the anomaly.There also some recommendations how to fix this kind of anomaly.To provoke HTTP 404 "not found error" we have simply to permanently query for not existing product id likeAnd after several minutes DevOps Guru will recognize this anomaly and create the insight. As CloudWatch doesn't differentiate between HTTP 4XX errors the insight will look exactly like in case of HTTP 429 errors explained above. Here is the room for improvement as HTTP 404 are application errors and HTTP 429 can be more infrastructural error, so more precise information delivered by CloudWatch/DevOps Guru will lead to much quicker remediation time.In this article we described how DevOps Guru was able to detect the anomaly on API Gateway by throttling through exceeding the number of requests per day quota (the real world scenario will be to exceed the request and burst quotas) and by query for not existing product id. In the next part of this series we'll explore the anomaly detection on the Lambda.Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Jesse Warden - Sep 19 Dmitriy A. - Sep 19 Rahul Ladumor - Sep 19 Reza Alipour - Oct 1 Would you like to become an AWS Community Builder? Learn more about the program and apply to join when applications are open next. Once suspended, aws-builders will not be able to comment or publish posts until their suspension is removed. Once unsuspended, aws-builders will be able to comment and publish posts again. Once unpublished, all posts by aws-builders will become hidden and only accessible to themselves. If aws-builders is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Vadym Kazulkin. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag aws-builders: aws-builders consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging aws-builders will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.