When is it too early to think about monitoring?
In a word, “NEVER.”
I’ve heard people say that they are super busy with production deployments and fast-moving projects. They haven’t had much time to think about a performance monitoring strategy for their new applications.
But waiting until your applications are already in production is a mistake. However, it’s one that you can avoid.
Develop, test and deploy your applications with monitoring already in place and save yourself a lot of headaches. Let me count the ways:
1. Using the same monitoring tools for both pre- and post-production
Obviously, you will be doing performance testing during development and QA. But if you use different tools before and after, you might get inconsistent results. And you’ll have to retrain the people that did the original testing on the new performance monitoring tools. After they’ve moved on to other projects.
Having a monitoring strategy in place ensures that people are using the same tools throughout the lifecycle. .So that you can expect consistent measurements and more efficient troubleshooting and response if necessary.
2. Monitoring – independent from administration – eases access and alleviates concerns
Many developers need access to performance metrics during testing and often that means providing administrative access to middleware platforms to get those metrics.
When you’ve implemented an independent monitoring solution then developers can self-service their performance monitoring needs without worrying about providing administrative access.
3. Monitoring best practices implemented at design-time means less effort at run-time
Correlation of metrics between related technologies is what allows you to see things in context. For instance, show me all the servers that support a particular application. That's significantly easier than wading through 1000’s of servers trying to figure out which ones support my “banking” application. This is especially helpful when time is of the essence. But how does your monitoring system know which instances are related?
Well, you could map it manually, often using naming conventions for your services and engines. The better you stick to well-defined naming conventions, the easier it is. This is another reason why including monitoring requirements in your application building process will pay dividends down the road. Because “automatically” is so much easier than “manually”.
4. Capacity Planning is easier if you’ve been collecting performance data all along
If your business is successful, your apps will get busier and you’ll need to ask yourself if you have enough capacity for future growth? Of course, it’s hard to answer that question if you have no baseline data.
However, capturing performance data from the start enables you to see the resource usage trends over time. Correlate that to expected traffic growth for your application and you'll be on stable ground as you analyze your resource requirements for the next 6-12 months.
5. You don’t have to worry about running out of steam
For a lot of companies, once an application is written, people celebrate and move on. Things that you promise you’ll get to later – never seem to be a priority anymore. Unless, of course, you are hit with a severity one outage and then all heck breaks loose. Then people start panicking because there is no visibility into what is breaking down and where.
Building monitoring requirements into the application development cycle ensure that these things are not forgotten in the hustle and bustle of the next project. In fact, some of our customers will not sign off on a project unless monitoring is ready to go BEFORE moving into production. They make it a priority from the start so that they don’t have to struggle for resources AFTER everybody thinks they are done and move on to something else.
So, the next time somebody asks you about your monitoring strategy for your new apps, instead of saying “I’m too busy to think about it right now,” you should say, “I’m way ahead of you”.
David Hickman is in Product Marketing at SL Corporation.
The Latest
An effective breakpoint strategy helps deliver sharp, properly sized images, which are some of the most compelling pieces of content on a web page. Lack of such a strategy can lead to jagged images or ones that take too long to render due to excessive size, potentially reducing the overall effectiveness of web pages — and driving down the quality of the user experience. In this blog, we will explore just how significant image breakpoints are to businesses, and some important device-related factors to consider in image breakpoint decisions to deliver the optimally-sized web image every time ...
As the data generated by organizations grows, APM tools are now required to do a lot more than basic monitoring of metrics. Modern data is often raw and unstructured and requires more advanced methods of analysis. The tools must help dig deep into this data for both forensic analysis and predictive analysis. To extract more accurate and cheaper insights, modern APM tools use Big Data techniques to store, access, and analyze the multi-dimensional data ...
Modern enterprises are generating data at an unprecedented rate but aren't taking advantage of all the data available to them in order to drive real-time, actionable insights. According to a recent study commissioned by Actian, more than half of enterprises today are unable to efficiently manage nor effectively use data to drive decision-making ...
According to a study by Forrester Research, an enhanced UX design can increase the conversion rate by 400%. If UX has become the ultimate arbiter in determining the success or failure of a product or service, let us first understand what UX is all about ...
The requirements of an APM tool are now much more complex than they've ever been. Not only do they need to trace a user transaction across numerous microservices on the same system, but they also need to happen pretty fast ...
Performance monitoring is an old problem. As technology has advanced, we've had to evolve how we monitor applications. Initially, performance monitoring largely involved sending ICMP messages to start troubleshooting a down or slow application. Applications have gotten much more complex, so this is no longer enough. Now we need to know not just whether an application is broken, but why it broke. So APM has had to evolve over the years for us to get there. But how did this evolution take place, and what happens next? Let's find out ...
There are some IT organizations that are using DevOps methodology but are wary of getting bogged down in ITSM procedures. But without at least some ITSM controls in place, organizations lose their focus on systematic customer engagement, making it harder for them to scale ...
If you have deployed a Java application in production, you've probably encountered a situation where the application suddenly starts to take up a large amount of CPU. When this happens, application response becomes sluggish and users begin to complain about slow response. Often the solution to this problem is to restart the application and, lo and behold, the problem goes away — only to reappear a few days later. A key question then is: how to troubleshoot high CPU usage of a Java application? ...
Operations are no longer tethered tightly to a main office, as the headquarters-centric model has been retired in favor of a more decentralized enterprise structure. Rather than focus the business around a single location, enterprises are now comprised of a web of remote offices and individuals, where network connectivity has broken down the geographic barriers that in the past limited the availability of talent and resources. Key to the success of the decentralized enterprise model is a new generation of collaboration and communication tools ...
