One of my favorite features in Serverless360 is the monitoring calendar. It is something we added in 2022. The feature aims to help give you a view over time about when your business application has experienced problems that would have triggered warnings or errors based on the monitoring you have configured.
Once your solution is in testing and early in its production life, you need to be looking at how it performs in the real world and then optimize and tweak how it works so that you will be easy to support in the real world.
In this post, I wanted to look at a few scenarios and talk about how the monitoring calendar can help us drive continuous improvement, which will lower our operating costs.
Fixing bad data
In one of our integration solutions, we are feeding data from a plant operations system to a system where users will manage the accuracy and validation of the operations data.
The interface performed well during testing and had very few issues. In the real world, as the interface ramped up and the users started putting more data into the source system, we started finding that errors were happening that would trigger our monitoring in Serverless360.
On review, the problem was that the data added to the source systems, which was being pushed through to the destination system, did not have the corresponding data setup, so the destination system API threw errors.
In the Serverless360 business application, the calendar lets us see support issues over time, and we can see this is causing a common support issue that needs someone from the integration team to look at and work out what is wrong.
Because this is not an integration problem, it’s about issues with the data in the source and destination systems, and the integration team tells whichever team needs to take action to fix it.
To reduce the load on the integration team, we used Business Activity Monitoring in Serverless360 to allow the Logic Apps to let application users have visibility of issues processing data in the interfaces. The users can not take ownership of fixing their data to make sure their interfaces run more smoothly.
From the perspective of the integration team, we can now see an improvement in the performance of the interface through the monitoring calendar, and we have reduced our support overhead.
Fixing issues in the code
The following scenario I wanted to look at is an issue where we had a project which delivered an interface quite a while ago, and the project closed down. We would regularly get support requests from the business users about various issues, setting up Serverless360 to monitor this interface. We could see from the monitoring calendar that this solution was having many problems that weren’t visible.
What was happening was there were problems regularly under the hood which were going unnoticed, and then after a time, the users would raise a support ticket when they noticed a problem, and we would spend time sorting out the things that had gone wrong.
Using the view from the monitoring calendar gave us a solid case to get some budget to implement some changes to this interface. The common challenge in many enterprises is that when you don’t have a project driving change, then it’s sometimes challenging to get funding to make changes. The monitoring calendar gives us strong evidence to demonstrate the hidden support costs for a solution. An investment in fixing some issues in the interface can reduce our support costs significantly and improve the user’s experience.
After we made some code changes to the interface to better handle some data conditions that made some of the Logic Apps have problems, we can measure the improvement in the monitoring calendar, translating to a reduction in support overhead.
Working with vendors to improve system stability
An interesting scenario we had was with one of our business applications which manages an API where we get data sent from a 3rd party vendor, which indicates the GPS locations of some of our assets.
One of the things we set up using the application insights integration in Serverless360 was a query monitor which would check that we were receiving data from the vendor.
We were expecting to receive hundreds of events per hour, but when we went live, we found that the query monitor was triggering to indicate we had received no events or warn that we had only received a small number of events.
We were able to work with the vendor on some of the issues, and they were able to address the problems on their side; and we then were getting the events in the expected pattern.
It was a simple kusto query we set up that Serverless360 would run regularly against application insights to ensure that we receive the messages we expect.
Where we want to get to
When the business application operates well with no issues, the monitoring calendar should appear empty with no warnings or errors.
Here is where we want all of our business applications to get to, which indicates everything is running well.
Summary
Hopefully, these examples of how we used the monitoring calendar in Serverless360 will help inspire ideas to help you improve the operations of your Azure solutions and lower your support costs as a result.
