Java Monitoring for Dev, Test, QA and Prod environments & collection options
Best part of my job over the last 20+ years is working with more than 200 companies and working very closely with a few dozens. The variety that I have been exposed to has helped me learn a lot from these diverse environments and the people involved. Most companies, especially the ones with Performance Teams, have interesting guidelines on what they collect, and how much detail they collect in each environment, and how long they keep the information.
In this blog we are going to discuss what you need and why you know better than anyone else how you should set this. I just like to provide some suggestions of what you may want to consider. One of my largest customers asked me for some recommendations. It was obvious that collect everything all the time was not a practical approach, when you have over 200 application servers that you are monitoring. So I had to sit down and compile a table and validate with a few, and ultimately make some executive decisions, with the disclaimer that these are MY recommendation.
Our Java collector has 4 levels of collection, as we call them our Instrumentation Levels:
We will not be discussing all the details about these 4 options right now. And I will be glad to review them in greater details for you individually, if you like. First I want to make a plea that no one should monitor all their applications using the same Instrumentation level. There is a reason that we offer 4 different ones. Unfortunately our default is FullDetail.
Our default should have been ComponentDetail, specially for large volume Production environments. That is how most of our internal demo environments are set up and for very good reasons. It provides the flexibility, and the most acceptable overhead, especially for the most important Business Critical applications. As we all know Java monitoring is intrusive. So if one is not going to actively using the information, and not using the information for hours at a time on daily basis for analysis, this is my favorite option.
For Development areas, FullDetail is a very good option. It provides the most detail you can get. If you have too many application servers and are not sure what you need to collect, BasicDetail is my first choice. And you have application servers that are very fragile; you may need to start with NoDetail.
Please provide your feedback as I love hear your perspectives on Instrumentation Options. I always learn from my customers and peers. Instrumentation options working with retention policies are very interesting topics to discuss and review. Please let me know if I can help.