Like razors and razor blades or cars and gasoline, development is inextricably linked to operations—particularly when it comes to overall application costs, SLAs, and similar IT performance metrics.
In this article, we explain how to use Spring Insight IDK and Spring Insight Operations to manage and monitor applications by their transactions and transaction types, making them content-aware. In other words, we can use these tools to monitor the system based on the data that is passing through it much like routers might analyze packets based on the type of data passing through.
As developers, our applications’ business transactions are the core unit of what serves the business or customer and what we need to monitor and manage. Our code might support a simple transaction such as withdrawing money from an ATM, booking a hotel room, or ordering online theater tickets. As well, our code provides longer business operations such as aggregating daily sales data into a weekly report or performing more complex data analytics. The one thing we all expect is that these transactions will perform well and operate cost-effectively. With a smart approach using the Spring IDK combined with a application performance monitoring solution like Application Performance Manager (APM), the monitoring solution can intelligently alert us about problems based on the context of the data or transactional information.
Scenarios of Use and Dev to Ops Collaboration
Within APM, AppInsight enables us to monitor application transactions. It automatically maps business transactions across the various application tiers, helps us identify problems in all levels (application, middleware, data, and infrastructure), and allows us to drill down to the root cause of a problem. AppInsight transactions can also be easily monitored by IT operations and make triage faster and easier when further investigation is necessary. In some monitoring cases, there is a need to manually define transactions that have the most meaningful operations in an application. The information required in order to define these operations is not always accessible at runtime / production but it is available during the application development process. A true dev to ops collaboration is critical in order to achieve the best definition of these transactions. Developers typically know application transactions best and are usually “occupied” implementing the complex business logic of an application. Until recently, we were not involved with other phases past coding and were less aware of how critical business transactions are identified and monitored in production. Recently, more and more developers have started asking themselves whether their work is production maintainable. There is a clear understanding that monitoring these critical business transaction cannot fall on the shoulders of the IT operational staff who lack the expertise to track and remediate application level issues (in contradiction to infrastructure issues) and cannot handle the growing number of applications and complexity. This pushes developers beyond the boundaries of coding towards operations where they can bring better integration points between application lifecycle stages.
AppInsight can play a major role in this area. Together with Spring Insight, we can control how transactions are monitored. I chose to demonstrate these tools using the SpringTrader application, a vFabric sample day trading system that uses most of the vFabric components. Here is how our approach leverages the vFabric suite:
- Coding: using STS with Spring Insight for developers to develop/maintain code.
- Deploy: using vFabric Application Director to deploy or update deployments.
- Monitor: using vFabric Application Performance Manager’s AppInsight to monitor business transactions.
Monitoring can be done for any specific type of content or transaction. Here are two example use cases:
1. Monitor transactions/transaction elements by content (e.g. stock symbol).
Different stocks might route to different channels based on content; some are transacted with very high volume while others are rarely ordered. Differentiating between transaction endpoints according to the stock symbol can ease monitoring and make things more efficient.
2. Monitor order transactions that result in high volume (e.g. gold transactions).
These gold transactions are critical. For example, high volume means higher impact (loss) when the transaction is delayed; thus, this kind of transaction should be satisfied promptly and without any problems. Applications may honor different SLAs for such gold transactions and should have a way to monitor them differently.
Coding Phase
In the coding phase, developers can use the Spring Insight Developer Kit, which is set of annotations a developer can use inside his code. The approach allows us to introduce content aware monitoring for transactions, which is one capability of the IDK. The IDK also provides capabilities to:
1. Ensure that the transaction (or part of it) will be monitored
2. Determine the correct labels
3. Obscure monitored data
4. Protect parts of the code from being monitored (sensitive data
Please visit the Spring Insight IDK documentation for more.
Content Aware Monitoring
The following is the “save” method signature (from SpringTrader code) to save an order on the OrderController class:
The highlighted part is a parameter level annotation. As part of the IDK, the annotation hints to Spring Insight that anytime the TradingServiceFacade#save is picked as an endpoint, its name and label will be determined according to the getName and getGold methods on the argument attribute(Order). Of course, sub attributes can be accessed as well (e.g., {foo.bar}).
From the Order class:
The name of the transaction element is picked as the regular class#method fashion with the quote symbol appended at the end.
The label (as seen in AppInsight) is “class#method Sym” for a regular order (less than $10k, but an order total value higher than $10k will be marked as a gold order to be monitored separately). I picked simple logic here but, of course, any transaction and type of content can be implemented as the differentiate logic.
Deployment Phase
Compiled artifacts are automatically published and consumed as content members in vFabric Application Director blueprint.
Update action is being initiated to replace old artifacts with new (pushing code into staging).
The code and monitoring updates can then be pushed from development to staging automatically by using vFabric Application Director and something like Jenkins.
Monitoring Phase
After a successful deployment/update with Application Director, AppInsight monitors the SpringTrader application automatically.
The transactions are being learned.
The image below shows that TradingServiceFacadeImpl@saveOrderDirect transaction element is being monitored per stock symbol and not as a single transaction endpoint and that the monitoring data is being collected per stock order. Two transaction elements are marked as gold orders, meaning that these transaction elements monitor performance of the critical orders valued at more than $10k.
The image below shows how transaction elements are monitored by AppInsight.
With these examples in mind, you can see how our monitoring can become content aware and how the approach can be used to manage operational costs, performance, and SLAs.
>> To learn more about Spring Insight, Application Director, or Application Performance Management:
- Visit the Virtualization and Cloud Management Blog
- Visit the vFabric Blog
- Try the application, buy online, or learn more
 |
About the Author: Dani Matzlavi leads the vFabric AppInsight development. He has over 10 years of experience in software engineering both in technical and management positions, specializing in software design, architecture and software solutions. He holds a BA. in Computer Science from the Academic college of Tel-Aviv and MBA from the Open university. Dani joined VMware in 2010 (from EMC Ionix) and has previously worked on VMware vCenter Infrastructure Navigator (VIN) and on Application Dependency Manager (ADM) at EMC. |
