I wanted to remind people about the weekly Application Performance Management (APM) and IT Analytics webcasts that IBM is hosting. The following website contains a list of upcoming webcasts as well as recordings of the previous webcasts. Upcoming webcasts include:
- MongoDB and Ruby on Rails monitoring
- PHP, Python, and PostgreSQL monitoring
- The value of combining Log Analytics and Application Performance Management (APM)
Go to the following link to get details: https://ibm.biz/BdxUGq
I just came back from a visit with a customer. They were looking to move from their existing monitoring and Service Desk solution to a new solution with more capabilities. In addition, they wanted to introduce an Event Management layer because the number of events was getting too high as the customer has grown. I wanted to share some thoughts from the meeting. The interesting part of the discussion had to do with the actual migration process. The customer wanted to know where to start.
The customer wanted a complete solution with network monitoring, storage monitoring, application performance management, event management, and integration with a service desk. You know what you want your final state to look like, but you have to figure out how to get from point A to point B. So, where to start? Normally, when I have these conversations with customers, I start by asking the customer where their biggest pain points or gaps are. With most management solutions, there are several different entry points into the solution. You can start with the top of the enterprise management solution and work your way down. You can start with the monitoring layer and work your way up. But, ultimately, what usually work best is by solving the customer’s biggest challenge first.
In this case, the customer had two major challenges. They had too many events because they were sending events directly from the monitoring tool to the service desk with no event filtering, correlation or de-duplication. Second, they were encountering response time problems in their remote locations with Citrix XenApp applications. This provided a challenge in identifying whether the problem was introduced by the Citrix environment, the business applications being hosted in the Citrix environment, or by the network. By introducing response time monitoring and monitoring of the Citrix XenApp environment, the customer will be able to identify any issues with response time and Citrix environment. If we see that specific applications are causing problems, monitoring can be put in place for those applications. Response Time monitoring is the real key. By detecting slow response time and identifying where those response times are occurring, then it’s easy to identify whether the response time issues are a geographic/networking problem. Based on our conversations with the customer, identifying and isolating the response time problems seemed to be the bigger issue and that was the recommendation where to start.
Every customer is different. In some cases, a business service management service is the key challenge because of the size of the environment. In other cases event correlation or event management is the problem. Sometimes, the problem is a specific application or issues with the application performance management tools. What’s important is to start with the pain point and what will provide the biggest impact to the customer and build out a deployment plan.