Introduction

In 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. Now it's time to set up the sample application on which we'll provoke the Devops Guru anomalies and see this service in action.

Deploying the sample application with activated DevOps Guru

To demonstrate the usage of DevOps Guru we use this sample application. It is Serverless application for creating, retrieving and deleting the products. For this purpose it uses API Gateway, Lambda, DynamoDB and SQS services as described in the architecture diagram below.

We use AWS SAM for IaC (which you need to install in your environment) and after deploying the sample application (by executing "sam deploy -g") and giving the stack the name DevOpsGuruWorkshop you'll see the application being deployed in your AWS account. Moreover DevOps Guru will be also activated to analyze the resources from this stack. This part of IaC from SAM template serves this purpose.

  DevOpsGuruResource:
    Type: AWS::DevOpsGuru::ResourceCollection
    Properties:
      ResourceCollectionFilter:
        CloudFormation:
          StackNames:
          - !Sub ${AWS::StackName}

To verify it, navigate to the DevOps Guru service and check if you see the following for the analyzed resources.

Adding some real data to our sample application

Now please go to the API Gateway service, then navigate to the DevOpsGuruDemoProductsAPI and then execute the following PUT HTTP Request

to create product with id "1" with its description and price to the DynamoDB ProductsTable to have some real application data. Here is the full JSON payload for it.

[
    {
      "id": 1,
      "name": "Print 10x13",
      "price": 0.15
    }
]

Pre-warming our sample application for the DevOps Guru usage

You need to pre-war our sample application for example by sending requests to the API Gateway (like retrieving the newly created product by id equals to 1 using the following URL YOUR_API_GATEWAY_ENDPOINT/prod/products/1) as DevOps Guru needs at least one hour or more to build the base line of the working application to start recognizingthe anomalies as described in the 1st part of the series.

You can send such requests either via the API Gateway GUI or programatically by figuring out your API Gateway URL first either in the API Gateway for DevOpsGuruDemoProductsAPI or alternativaly as output variable in the console after deploying the application by running the SAM template. Please note, that our API Gateway is protected with the API Key see MyApiKey resource definition in the SAM template, so you need to additionally send this HTTP header "X-API-Key: a6ZbcDefQW12BN56WEN7" in case you send the request programatically.

The indicator that DevOps Guru has already analyzed the application (or several resources only as specified by tagging) is that they appear in the list of the "Resources analyzed" under the "Resource summary" as displayed in the images below.

Here is the more detailed view additionally displaying the number of applications and different service types analyzed.

Choosing the stress test tool

For running our experiments to provoke anomalies we'll use the stress test tool. You can use the tool of your choice (like Gatling, JMeter, Fiddler or Artillery), I personally prefer to use the tool hey as it is easy to use and similar to curl. On Linux this tool can be installed by executing

curl -sf https://gobinaries.com/rakyll/hey | sh

Conclusion

Now we've set everything up to see DevOps Guru in action. In the next part of this series we'll explore the anomaly detection on the DynamoDB.