Document360 is one of the leading knowledge base platforms in the market, with over 1000 enterprise customers.
The initial version of Document360 was released in the year 2017. Due to the simple and elegant user experience and competitive feature set, it gained the traction of many customers in the market, leaving it to become one of the category’s top tools.
The entire Document360 application is hosted in Microsoft Azure. Document360’s customer base increased, so the application required a proper tool for monitoring the Azure infrastructure. Though Azure provides default monitoring capabilities, it is too vague and is available only at the resource level, not at an application or business level. Since we had an in-house product in the organization addressing the exact problem, we used Turbo360 – Business Applications to monitor the Azure resources.
Now that the Azure environment is being monitored using Business Applications, we faced a few internal issues within the background jobs running in .NET Function apps. The Function apps had different triggers like Timer, Service Bus, and HTTP, especially for Durable Functions. We also had a couple of Azure Worker roles with similar triggers.
We needed a tracing solution that connects the integrations and provides troubleshooting and .NET application monitoring from a business perspective. We initially tried App insights, which helped to a certain extent, but we required an end-to-end tracking tool rather than just a logging solution.
We tried a few other solutions in the market and found them to be a dead end. We even considered building a custom solution for achieving this, as it is critical for us to monitor the jobs. In search of a solution, we learned that Turbo360 recently brought in an offering called BAM, which solves our exact problem. So, we decided to give Turbo360 BAM a try for a small chunk of integration.
Turbo360 BAM has a hierarchy to define one’s business solution,
- Business Process – A top-level container for multiple transactions.
- Transaction – Group of tasks representing a transaction.
- Stage – A small piece of task or activity.
It is entirely up to the users to define their Business processes, Transaction, and Stages.
In our case, we wanted to start with monitoring the jobs related to credit card payments. We integrated a third-party library for payment using a credit card and required the following tasks to run at daily intervals.
- Successful payments,
- Payment failures,
- Expired cards,
- Invoice notification, etc
First, we created a business process and started with a single transaction with all the mentioned tasks as stages. Defining a Transaction is straightforward and gives an overall picture of what is happening from a business perspective.
Adding a stage involves defining properties that will be extracted in the real-time transaction data. It was super helpful for us to extract the customer-specific identifier from the transaction data.
Now that the configurations were defined, the pending task was to instrument BAM in the code base. There are a few ways Turbo360 BAM can be instrumented in a solution, like REST APIs, .NET Library, and Azure Logic App connectors. Since our tech stack is .NET, we used the .NET library, which was simple to configure.
There is a NuGet package available, Kovai.Turbo360.BAM, which has the required methods to instrument the data. This article covers how to use the .Net library to instrument BAM . There are three types of actions available to track the data,
- Strat Transaction
- Checkpoint
- Checkpoint with Correlation
We added a Start Transaction call at the beginning of the orchestration as this is instrumented in a durable function. According to the Transaction defined in BAM, we had equivalent tasks and added the respective Checkpointing calls at each task. Following are a few snippets of the instrumentation,
Now that everything is set and we are ready to see the outcome of the instrumentation, we tried some trial runs and found a few manual errors in the instrumentation, and it didn’t take much time for us to resolve everything.
So, we have a working instrumentation published in our QA environment. These are jobs running at regular intervals, so we could see the actual run details logged as Transaction Instance in the Tracking section of the Turbo360 application soon after each Azure Function invocation, and it looked fantastic.
By clicking a Transaction instance, we could see the status of all the stages executed for the respective Azure Function invocation.
Identifying the failures is way cooler than just accessing the instances. If there is any error in the Transaction Instance, the row will be highlighted with an error indication, and we can check for the stage/ task which caused the error and the details of the error.
An excellent querying option is available so a user can drill down and search for a particular instance based on the tracked data. The transaction instance will be displayed on clicking the failed row, with failed stages marked in red.
Upon clicking the failed stage, the details of the exception which caused the failure will be displayed.
Above is what we need in the first place, and we could achieve this using Turbo360 BAM. The following steps were to set up Transactions in all possible services of the application running in Web apps, Function apps, and Worker roles.
Right now, we have 19+ Transactions defined for our jobs, and there are three regions where Document360 is hosted. We created a Business Process for each region and cloned the transactions in it. So, we have 50+ Transactions that are being monitored in Turbo360 BAM.
In addition to the tracking, we configured real-time exception monitoring on the transactions so that our team will get an instant alert whenever there is a failure in the jobs; this addresses our main requirement – “end-to-end .NET Application monitoring” following is an alert report received for one of our transactions.
Similarly, we can monitor the transactions based on the duration taken for completion. Queries saved on the Transactions can also be monitored based on the result set. This helps in observing the performance of the jobs.
There are many integrations like Microsoft Teams, SMTP, ServiceNow, and Azure DevOps in the tool to drop alerts such as messages, emails, tickets, etc.
All the monitoring aspects have been covered, and the last thing pending was to set up dashboards; this again is constructed based on the queries and helps observe the trends of the jobs, basically the failures and performance in our case. We have multiple widgets created representing the transactions, and the dashboard is quite helpful for us to ensure the services are healthy.
To conclude, while searching for tools to achieve .NET application monitoring, we tried Turbo360 BAM with a small integration, which was the best solution for us in terms of addressing our requirements. Our usage in Turbo360 BAM is simple, but the tool can support much more complex integrations involving cross-platform implementations. Once the BAM is instrumented, irrespective of how complex the solution is, a user can quickly troubleshoot the failures in a system.
Try out Turbo360 for free.
