Java runtime Monitoring, part 1th: Runtime performance and availability monitoring of Java systems

Brief introduction

Many Java applications today rely on a complex set of distributed dependencies and moving parts. Many external factors can have an impact on the performance and availability of your application. These effects are largely not completely eliminated or resolved, and are difficult to simulate accurately in a prebuilt environment. Stuff happens. However, you can create and maintain a comprehensive system to monitor the entire ecosystem of your application, thereby significantly reducing the severity and duration of these events.

This series of articles gives some patterns and techniques for implementing such systems. Patterns, and some of the terms I'm going to use, are all generic. By combining sample code and illustrations, they will help you understand the concept of application performance monitoring. This understanding emphasizes the need for solutions and can help you choose a commercial or open source solution. You can extend and customize a solution, or use it as a blueprint for designing solutions as needed.

Part 1th:

Explore the properties of an application performance management (APM) system

Describe common negative patterns of system monitoring

Enumerate the ways to monitor JVM performance

Provides a way to effectively insert application source code

The 2nd part will focus on how to insert Java classes and resources without modifying the original source code. The 3rd part discusses methods for monitoring the external resources of the JVM, including the host and its operating system, as well as the remote services such as database and messaging systems. It will also summarize and generalize other APM issues, such as data management, data virtualization, reporting, and alerting.

APM systems: Patterns and negative patterns

To get you started correctly, it should be emphasized that while most of the Java-related content described here looks similar to the process of application and code profiling, this is not the case. Profiling is a valuable pre-production process that confirms that your Java code is scalable, efficient, fast, and good enough. However, according to the stuff happens axiom, good development phase Code performance analysis may be useless when you encounter an issue that cannot be explained in production.

I mean, to implement some aspects of performance analysis in production and to collect some of the same real-time data and all of its external dependencies from the running application. The data consists of a series of quantitative measurements across the target that provide fine-grained and detailed representations of the overall health of the system. In addition, by retaining the historical library of these metrics, you can capture accurate baselines to help you confirm that the environment is still healthy, or to identify the source and scale of specific defects.

Monitor Negative mode

There are very few applications that have no monitoring resources at all, but you still need to consider these negative patterns, which often appear in the running environment:

Blind spots: Some system dependencies are not monitored, or the monitoring data is inaccessible. The running database can overwrite all monitoring scopes, but if the supported network is not fully overwritten, the diagnostic team will not be able to see the failures in the network when analyzing database performance and applying server symptoms.

Black box: A core application or one of its dependencies may not have monitoring transparency within it. The JVM is an out-and-out black box. For example, the diagnostic team is investigating unexplained latency problems in the JVM and only has statistics that support the operating system (such as CPU utilization and the amount of memory required by the process), and they may not be able to diagnose garbage collection or thread synchronization issues.

Disjointed and disconnected monitoring systems: Applications can be hosted by large shared data centers, where dependencies consist of a range of shared resources, such as databases, storage area network (SAN) libraries, messaging, and middleware services. Organizations are sometimes highly isolated and teams are only responsible for managing their own monitoring and APM systems (see the Flaw sidebar for isolated monitoring). Without a consolidated view of the dependencies, the component owners can only glimpse.