TAG | legacy
Ten years ago, the standard way to troubleshoot an application issue was to look at the logs. Users would complain about a problem, you’d go to operations and ask for a thread dump, and then you’d spend some time poring over log files looking for errors, exceptions, or anything that might indicate a problem. There are some people who still use this approach today with some success, but for most modern applications logging is simply not enough. If you’re depending on log files to find and troubleshoot performance problems, then chances are your users are suffering – and you’re losing money for your business. In this blog we’ll look at how and why logging is no longer enough for managing application performance.
The Legacy Approach
The typical legacy web application was monolithic and fairly static, with a single application tier talking to a single database that was updated every six months. The legacy approach to monitoring production web applications was essentially a customer support loop. A customer would contact the support team to report an outage or bug, the customer support team reports the incident to the operations team, and then the operations team would investigate by looking at the logs with whatever useful information they had from the customer (username, timestamps, etc.). If the operations team was lucky and the application had ample logging, the operations team would spot the error and bring in developers to find the root cause and provide a resolution. This is the ideal scenario, but more often than not the logs were of very little use and the operations team would have to wait for another user to complain about a similar problem and kick off the process again. Ten years ago, this was what production monitoring looked like. Apart from some rudimentary server monitoring tools that could alert the operations team if a server was unavailable, it was the end users who were counted on to report problems.
Logging is inherently reactive
The most important reason that logging was never truly an application performance management strategy is that logging is an inherently reactive approach to performance. Typically this means an end user is the one alerting you to a problem, which means that they were affected by the issue – and (therefore) so was your business. A reactive approach to application performance loses you money and damages your reputation. So logging isn’t going to cut it in production.
You’re looking for a needle in a haystack
Another reason why logging was never a perfect strategy is that system logs have a particularly low signal to noise ratio. This means that most of the data you’re looking at (which can amount to terabytes for some organizations) isn’t helpful. Sifting through log files can be a very time-consuming process, especially as your application scales, and every minute you spend looking for a problem is time that your customers are being affected by a performance issue. Of course, newer tools like Splunk, Loggly, SumoLogic and others have made sorting through log files easier, but you’re still looking for a needle in a haystack.
Logging requires an application expert
Which brings us to another reason logging never worked: Even with tools like Loggly and Splunk, you need to know exactly what to search for before you start, whether it’s a specific string, a time range, or a particular file. This means the person searching needs to be someone who knows the application well, usually a developer or an architect. Even then, their hunches could be wrong, especially if it’s a performance issue that you’ve never encountered before.
Not everyone has access to logs
Logging is a great tool for developers to debug their code on their laptops, but things get more complicated in production, especially if the application is dealing with sensitive data like credit card numbers. There are usually restrictions on the production system that prevent people like developers from accessing the production logs. In some organizations, these can be requested from the operations team, but this step can take a while. In a crisis, every second counts, and these costly processes (while important) can cost organization money if your application is down.
It doesn’t work in production
Even in a perfect world where you have complete access to your application’s log files, you still won’t have complete visibility into what’s going on in your application. The developer who wrote the code is ultimately the one who decides what gets logged, and the verbosity of those logs is often limited by performance constraints in production. So even if you do everything right there’s still a chance you’ll never find what you’re looking for.
The Modern Approach
Today, enterprise web applications are much more complex than they were ten years ago. The new normal for these applications includes multiple application tiers communicating via a service-oriented architecture (SOA) that interacts with several databases and third-party web services while processing items out of caches and queues. The modern application has multiple clients from browser-based desktops to native applications on mobile. As a result, it can be difficult just to know where to start if you’re depending on log files for troubleshooting performance issues.
Logging is simply not enough
Logging is not enough – modern applications require application performance management to enable application owners to stay informed to minimize the business impact of performance degradation and downtime
Logging is simply not enough information to get to the root cause of problems in modern distributed applications. The problems of production monitoring have changed and so has the solution. Your end users are demanding and fickle, and you can’t afford to let them down. This means you need the fastest and most effective way to troubleshoot and solve performance problems, and you can’t rely on the chance that you might find the message in the log. Business owners, developers, and operations need in-depth visibility into the app, and the only way to get that is by using application performance monitoring.
Get started with AppDynamics Pro today for in-depth application performance management.
As always, please feel free to comment if you think I have missed something or if you have a request for content in an upcoming post.Link to this post:
Often times big enterprises have difficulty keeping pace with changes in technology. This means more often than not operations teams are responsible for legacy systems and are constrained by the monitoring tools that were built to support those legacy systems. Just because your technology hasn’t changed in decades, however, doesn’t mean you can take advantage of the latest in production monitoring tools.
Last month we introduced AppDynamics X to enable developers and third parties to build extensions for AppDynamics Pro. In this post we will highlight one of our most recent integrations for working with mainframes. Our partnership with DG Technologies enables enterprises to get deep monitoring of their legacy systems with MEAS and AppDynamics Pro.
Organizations that have any dependency on zOS applications will now have the ability to leverage the most innovative, quick to value and scalable approach to Application Performance Monitoring. AppDynamics gives companies the ability to solve very complex problems quickly instead of spending time and consulting dollars configuring and maintaining legacy APM products that have been the only option until now. The integration between AppDynamics and MEAS is game changing for the enterprise mainframe market.
The MEAS Mainframe Monitoring Extension integrates the MEAS system with AppDynamics Pro to give users visibility into key events and metrics for applications that execute on the Mainframe z/OS platform or traverse both open and mainframe platforms. The operations team can utilize a single tool and methodology to monitor both open and mainframe applications plus applying policies against all metrics. Leveraging AppDynamics and the MEAS Mainframe monitoring extensions provides:
- Visibility into mainframe applications or mainframe applications called from distributed systems
- Complete end-to-end application topology mapping and performance monitoring
- One product to manage open systems and mainframe application performance
AppDynamics/MEAS provides visibility into the following:
- DB2 Database metrics
- CICS metrics
- z/OS metrics
- RMF metrics
Find out how to get started on AppDynamics X or see the integration in action below.
Custom Event Notifications
Business Transaction drill-down to DB2 backend
“The partnership with AppDynamics is very exciting and game changing for our clients and our company! Organizations that have any dependency on the zOS platform will now have the ability to leverage the most innovative, quick to value and scalable approach to Application Performance Monitoring. AppDynamics gives these companies the ability to solve very complex problems quickly instead of spending time and consulting dollars configuring and maintaining legacy APM products that have been their only option until now.” Deb Gannaway, CEO, DG Technologies