Lab 5: Platform Operations, analyzing metrics and log aggregation

Go back to the Web Terminal and stop your Flex Gateway container process by typing:

Now, let’s run it again, but add a special -d flag, so that the container runs in the background in daemon mode and that way, we can free up the terminal to run our load generation requests.

Verify that Flex Gateway container is running by typing

You should see 2 containers, the payments microservice that we initiated in Lab 2, as well as Flex Gateway container.

Let’s test that we can still invoke our Flex Gateway. Since we are in the same VM where it is running, we can simply do a localhost invocation to the port where the APIInstance was configured in Lab 2 (i.e. 8081)

This should also return the same JSON payload that we saw before from Payment service.

Now, let’s generate some load using an incorrect username and password combination, so that the result is always a 401 Unauthorized response.

Now in the new terminal, run another command to generate more load. This time, we are going to use the right credentials, but since we are limiting the number of requests with a “Rate Limiting” policy that allows only 2 requests every 30 seconds, then just a few requests will work, while the majority will fail with a “429 Too Many Requests” violation.

Wait a few minutes for both of these commands to run and generate enough data in the Control Plane.

Go back to Anypoint Platform Web Console and navigate to API Manager.

Open your Payment API that you configured in Lab 2.

You should be able to see a lot of movement in the different graphs.

With the mouse select over any of the charts “a range” across the activity period, so that you get a zoom in on the Monitoring across all charts

You can see across the 4 top metrics, the total number of requests and policy violations both increasing.

If you focus on the top right chart, you can see data across the 2 policies that we are forcing to fail by design, ie. Rate Limiting and Basic Authentication

Next, click “ View more analytics in Anypoint Monitoring Dashboard ” to see more information.

Notice that for every API that you create in API Manager, a new Dashboard will be built in Anypoint Monitoring using some of the most common API metrics, sent in real time by Flex Gateway. However, you have the option to create your own custom dashboard using a wider range of API metrics being pushed by Flex Gateway.

Let’s analyze the auto-generated built-in dashboard. On the overview page, you can see total request volume and breakdowns of failed requests.

If you are experienced running MuleSoft Applications, you will notice that this is the same place, skills and tooling that we use to monitor Mule APIs. This is great, as your Mule and Non-Mule enterprise APIs can all be monitored and Managed from the same Control Plane in 1-single Platform.

Also, notice that you can also use your mouse to select periods of time on top of any chart and all charts will filter on that period, so that you can always analyze different metrics across the same time window, all in one place.

Another option is to click on the date at the top right, to change the time range for which the dashboards display information. If you toggle the auto-refresh box, you will see live metrics for your API - which should still be receiving new requests from your terminal.

Now, click the requests tab.

Here, we can see the requests by response code and we will see numerous 401 and 429 code responses, with just a minority being 200 code responses. Let’s analyze some of the charts:

Requests by Response Code: Here, we can see graphically the amount of load that has been generated, split by response code. As you remember, every second we are sending an unauthorized request, but also, every second, we are alternating across sending just a couple of successful requests and forcing the majority ending in a 429 Too Many requests violation. So at the end, we see that many requests are doubled as “too many requests”, being represented very clearly in this chart “with colors”. This is great, because that means that even though the password is incorrect, by design a rate limit policy will protect APIs from Denial of Service attacks.

Now, click on Failures

Here, we can see some interesting charts created automatically. For example:

Failures by Response Code: This chart only shows the split by failures, so the successful responses with 200 response code have been removed and it will only show the errored ones.

Failures by Response Size: This chart will show the breakdown of responses by size. This will vary mainly because only some responses will contain the actual 200 code and will return a full JSON payload, while the majority will contain a shorter message about the type of error.

The last tab, “Client applications” is empty, as we did not use Client ID based Authorization access. In a normal API deployment configuration, this is another great way to secure access to your APIs and further provide Rate Limiting - SLA based access, leveraging API contracts that can be automatically or manually approved, providing different tier-based API Service Level Agreements.

Go back to API Manager and select your Payments API that you configured previously. Make sure to select the one with your prefix.

On the left side of the screen select Policies

Select Add Policy followed by Message logging under the Troubleshooting section at the bottom of the screen. Then, click Next .

From this page, we will only update the Message component. Go ahead and add a DataWeave instruction to log the response HTTP Headers .

Ensure “After API is called” is checked.

Finally, click Apply .

You should have 3 policies at this point

Now we are ready to test the Logging Policy. On the left side of the screen select Message Log .

Here you will see an output of all logged messages based on the attributes you selected earlier.

You will see the logs displayed. Feel free to edit your configuration and adjust the message data to be logged. Also, try the search capability to filter out messages based on your Logging selection.

On the top right of the screen, you can use the “Time range” filter, to pick a specific window to examine.

You can also click the “Show Latest Messages” to easily see the latest messages.

Also you can adjust the “Log Levels” - so that you can filter for certain information based on the debugging level. All of this configuration is enforced at runtime by the AnypointPlatform, without affecting your APIs or microservices.

In this lab you should just have the “INFO” flag returning log data.