GlassFish Monitoring: A Complete Guide

GlassFish is an open-source application server used to deploy and run Jakarta EE applications. Jakarta EE applications are enterprise applications built on the Jakarta EE platform. They are designed to have production-grade scalability, reliability, and security.

As GlassFish is the foundation for Jakarta EE apps, monitoring its performance is essential to ensure optimal application performance and availability. In this article, we share a comprehensive guide to monitoring key GlassFish metrics using native tools.

By effectively tracking these metrics, you can optimize your GlassFish environment to eliminate bottlenecks and improve resilience.

What is GlassFish?

GlassFish is a web server implementation that supports all Jakarta EE specifications, including Jakarta CDI, Jakarta Transactions, Jakarta Messaging, Jakarta REST, and Jakarta Security.

GlassFish was originally developed by Sun Microsystems in 2005. It was based on the J2EE platform — the predecessor to the Jakarta EE platform. In 2010, Sun Microsystems was acquired by Oracle, and GlassFish became an Oracle product. In 2018, it was transferred to the Eclipse Foundation, where it is now developed and maintained.

GlassFish is a great choice for running and serving a wide range of Java-based applications, including web applications, web services, e-commerce applications, and enterprise applications. Its built-in scalability makes it suitable for both small-scale projects and enterprise deployments.

Architecture

GlassFish has a modular architecture, which means that it’s made up of different Jakarta EE components, each providing a unique set of features. While installing GlassFish, developers can choose which components to include based on what they need. They can also implement custom functionality through add-on components.

This modular architecture brings multiple benefits, including flexibility, efficient memory usage, and low startup times. The core of GlassFish is built on a lightweight and performant Java Virtual Machine (JVM) that executes the Java bytecode of deployed applications.

GlassFish vs. Tomcat and Jetty

GlassFish, Tomcat, and Jetty are all open-source web servers that can be used to host Java applications. However, GlassFish is different in some key ways:

  • GlassFish is a fully featured application server, while Tomcat and Jetty are more lightweight web servers that support only a subset of the Jakarta EE specifications.
  • GlassFish is more complex to configure and manage than Tomcat and Jetty because it has more features and configuration options.
  • GlassFish is a good fit for deploying enterprise applications, while Tomcat and Jetty are better suited for hosting smaller, simpler applications.

Why is it important to monitor GlassFish?

Monitoring GlassFish is important for the following reasons:

Ensuring high performance

GlassFish is a crucial part of many IT infrastructures, as it houses the applications that users rely on. Regular monitoring of GlassFish ensures that these applications always perform at their best. By tracking metrics like response time, throughput, number of errors, and memory utilization, you can identify any dips in performance and take corrective action.

For example, if you notice that a spike in memory utilization is coinciding with an increase in average response time, you can surmise that a potential memory leak is slowing the server down.

Removing bottlenecks and maximizing throughput

Bottlenecks can severely impact application performance and user satisfaction. They can occur anywhere in the system, from the application code to the underlying hardware. For instance, poorly designed application code can lead to a bottleneck, but continuous monitoring of the GlassFish server enables you to detect and resolve bottlenecks early.

For example, an administrator may detect that an application is stuck while processing a request for a long time. By checking the logs and database metrics, they may find out that the application is waiting for a database query to execute. Armed with these insights, the administrator will be able to quickly identify and fix the problem.

Ensuring high availability

GlassFish is a resilient application server but it still requires regular monitoring to keep deployed applications up and running. By tracking metrics like uptime, HTTP response codes, and resource utilization, administrators can detect potential issues early on and implement failover mechanisms to maintain business continuity.

For example, a monitoring system may generate an alarm if an instance approaches 90% memory utilization. This will prompt an administrator to investigate the issue before the instance crashes, leading to service disruption.

Optimizing configurations

As applications evolve and usage patterns change, it becomes important to optimize configurations for continued performance. Monitoring GlassFish provides administrators with real-time insights regarding performance, which can be used to fine-tune configuration parameters.

For example, an administrator may notice that an instance slows down during peak hours. This may prompt them to consider adjusting settings related to the thread pool, connection pool, or caching.

Facilitating faster issue resolution

Monitoring GlassFish can also lead to faster troubleshooting. If a problem occurs, administrators can use real-time monitoring data to contextualize the issue and search for the root cause. This reduces the mean time to resolution (MTTR) and enhances the reliability of the overall system.

For example, if the GlassFish server experiences a sudden spike in CPU usage, administrators can identify the anomaly from the monitoring dashboards. They can then analyze different metrics, like concurrent requests, ongoing transactions, and active threads, to quickly pinpoint the issue and fix it.

Enhancing security and mitigating vulnerabilities

Web applications are susceptible to security threats and vulnerabilities. By tracking metrics such as login attempts, access denied errors and memory leaks, you can protect your applications and sensitive data from potential breaches.

For example, if you see multiple access denied errors, you can check the application logs to see if someone is trying to log in with elevated privileges.

Key metrics to monitor GlassFish performance

GlassFish exposes several metrics that can be used to track its performance and availability in real time. Let's explore the key metric categories.

Application metrics

Application metrics measure the health and performance of Java applications deployed inside a GlassFish instance. They can assist in identifying bottlenecks, troubleshooting application-level problems, and optimizing performance. Here are a few examples:

Metric Description
Total loaded servlets The total number of servlets that have been loaded in the instance.
Servlet processing time The total amount of time that all servlets have taken to process requests.
Total active servlets The total number of loaded servlets that are currently active.
Total activated sessions The total number of activated sessions since server startup. If the value of this metric is consistently high, it may indicate that the application is under heavy load.
Total expired sessions The total number of expired sessions since server startup.
Total sessions The total number of created sessions since server startup.
Total passivated sessions The total number of passivated sessions since server startup. A session is passivated when it is no longer active but is still held in memory.
Total persisted sessions The total number of persisted sessions since server startup.
Total rejected sessions The total number of rejected sessions since server startup. A high value of this metric warrants immediate investigation. (The definition of high differs based on operational requirements and SLAs.)
Active sessions The number of currently active sessions. Track this metric to gauge the load on a server at any given time.
Active JSP The number of currently active JSP pages.
Total JSP The total number of JSP pages loaded since server startup.
Reloaded JSP The total number of reloaded JSP pages.
JSP errors The total number of errors related to JSP pages.
Open connections The number of currently open connections.

HTTP metrics

HTTP metrics enable GlassFish administrators to ensure that HTTP requests are being processed efficiently. Here are some key HTTP metrics to remember:

Metric

Description

Request count 200 The total number of 200 responses generated since server startup.
Request count 2xx The total number of 2xx responses generated since server startup.
Request count 302 The total number of 302 responses generated since server startup.
Request count 304 The total number of 304 responses generated since server startup.
Request count 3xx The total number of 3xx responses generated since server startup.
Request count 400 The total number of 400 responses generated since server startup.
Request count 401 The total number of 401 responses generated since server startup.
Request count 403 The total number of 403 responses generated since server startup.
Request count 404 The total number of 404 responses generated since server startup.
Request count 4xx The total number of 4xx responses generated since server startup.
Request count 503 The total number of 503 responses generated since server startup.
Request count 5xx The total number of 5xx responses generated since server startup.
Transmitted bytes count The total number of transmitted bytes since server startup.
Received bytes count The total number of received bytes since server startup.
Max response time The fastest observed response time for any request since server startup.
Total request count The total number of requests processed since server startup.
Min response time The slowest observed response time for any request since server startup.
Error count The total number of error responses generated since server startup.
Processing time The average request processing time.

JVM metrics

JVM metrics can help administrators detect memory leaks, optimize garbage collection settings, and ensure efficient resource utilization. This leads to a stable and high-performing GlassFish environment for hosting Java EE applications. Let’s look at a few examples:

Metric

Description

Garbage collection time The total amount of time spent on garbage collection since server startup.
Total collections The total number of garbage collections performed since server startup.
Current memory usage The current JVM memory utilization. Ensure that this metric doesn’t exceed the max JVM memory threshold.
Committed heap size The amount of heap memory that is made available to the JVM.
Init heap size The amount of heap memory that the JVM requests from the operating system at server startup.
Committed non-heap size The amount of non-heap memory that is made available to the JVM.
Init non-heap size The amount of non-heap memory that the JVM requests from the operating system at server startup.
Max heap size The maximum amount of heap memory that can be used by the JVM.
Max non-heap size The maximum amount of non-heap memory that can be used by the JVM.
Used heap size The amount of currently used heap memory.
Used non-heap size The amount of currently used non-heap memory.
Pending finalization count An approximate count of the number of objects that are currently awaiting finalization. A high value of this metric may indicate memory retention issues that can lead to performance degradation or out-of-memory errors. (The definition of high differs based on operational requirements and SLAs.)

Transaction metrics

Monitoring transaction service metrics is vital for ensuring data integrity and consistency in web applications. Here are a few important transaction metrics to monitor:

Metric

Description

Active transactions The number of currently active transactions.
Committed transactions The total number of transactions committed since server startup.
Rolled back transactions The total number of transactions rolled back since server startup.
Transaction errors The total number of transaction errors encountered since server startup.
Transaction deadlocks The total number of transactions that ran into deadlocks since server startup.
Transaction success rate The overall success rate of transactions since server startup.
Transaction concurrency The level of concurrency in transaction processing. High concurrency can lead to contention and/or resource exhaustion.
Transaction latency The average transaction processing time since server startup.

Server metrics

Server metrics provide statistics on the GlassFish core, application clients, and resource utilization. They paint a good overall picture of the server's current status and well-being. The most important server metrics to focus on are:

Metric

Description

CPU usage The current CPU utilization of the GlassFish server.
Memory usage The current memory usage of the GlassFish server.
Disk usage The current disk usage of the node on which GlassFish is running.
Connection pool’s request wait time The average wait time of a connection request for this pool.
Connection pool’s longest connection request wait time The longest wait time of a connection request for this pool.
Connection pool’s acquired connections The total number of connections acquired from this connection pool since server startup.
Connection pool’s created connections The total number of connections created via this pool since server startup.
Connection pool’s destroyed connections The total number of connections for this pool that have been destroyed since server startup.
Connection pool’s free connections The total number of currently free connections in this pool.
Connection pool’s failed validations The total number of connections that failed validation for this connection pool.
Connection pool’s released connections The total number of connections that have been released to this pool since server startup.
Connection pool’s unmatched connections The total number of connection requests for this pool since startup that weren’t successfully matched.
Connection pool’s matched connections The total number of connection requests for this pool since startup that were successfully matched.
Connection pool’s used connections The number of connections for this pool that are currently in use.
Connection pool’s queue length The number of connection requests for this pool that are currently waiting to be served.
Connection pool’s potential leaks The total number of potential connection leaks for this pool since server startup. Any non-negative value of this metric should be investigated.

Tools for monitoring GlassFish performance

Now that we have explored some key performance metrics of GlassFish, let’s look at a few ways to measure and track them.

Using the asadmin command line utility

GlassFish ships with a command-line utility, asadmin, that can be used to gather key performance metrics in real time. By issuing commands via the utility, you can display several statistics, including requests per second, throughput, JVM memory utilization, thread pool usage, JMS service stats, and connector service statistics.

For example, to view a list of monitorable objects related to the GlassFish server, you can run the following command:

asadmin> list --monitor "server.*" 

The output should show the following objects:

server.applications 
server.http-service
server.jvm
server.resources
server.jms-service
server.network
server.orb
server.connector-service
server.web
server.thread-pool
server.security
server.transaction-service

You can then drill down on the relevant object to retrieve the desired metrics. For example, to fetch the max request processing time for an application named sample, you can use the following identifier in the asadmin monitor command.

server.applications.sample.server.request.maxtime 

Using the administration console

GlassFish also has a web-based administration console that can be used to manage and monitor a server. By default, the console is available at http://localhost:4848, and requires a login.

The console offers several built-in features, including:

  • Adding or connecting to brokers and clients
  • Configuring, managing, and monitoring connection services
  • Viewing and managing physical destinations
  • Monitoring messaging services
  • Monitoring broker operations

Using the Site24x7 monitoring engine

Site24x7's monitoring engine allows you to monitor GlassFish performance in real time. Among other things, you can analyze JVM performance, keep tabs on transactions, and gauge the overall HTTP success rate of your web applications. Here are some of the key monitorable metrics it offers:

  • CPU usage
  • JVM runtime memory usage
  • Thread counts
  • JIT compiler usage
  • Background and web transactions
  • Top error codes

Conclusion

Monitoring GlassFish is essential for ensuring optimal application performance, high availability, and robust security. By tracking key metrics using native tools and Site24x7, administrators can proactively manage and optimize their GlassFish environment, creating a resilient platform for Jakarta EE applications.

Was this article helpful?

Related Articles

Write For Us

Write for Site24x7 is a special writing program that supports writers who create content for Site24x7 "Learn" portal. Get paid for your writing.

Write For Us

Write for Site24x7 is a special writing program that supports writers who create content for Site24x7 “Learn” portal. Get paid for your writing.

Apply Now
Write For Us