GlassFish ad hoc monitoring

Many servers have inbuilt monitoring capabilities. This depends highly on the server, but it can give some interesting insights without having to use another tool. This is precious when you don't control the machine or don't have the permissions to access/configure the server.

To illustrate this kind of monitoring, let's use our Java EE reference implementation: GlassFish.

Once started with the normal ./bin/asadmin start-domain command, you can activate monitoring with this additional command:

$ ./bin/asadmin enable-monitoring
Command enable-monitoring executed successfully.

Indeed, there is a symmetric command if you want to deactivate monitoring:

$./bin/asadmin disable-monitoring

You can list the monitors available with the get command:

$ ./bin/asadmin get server.monitoring-service.*
server.monitoring-service.module-monitoring-levels.cloud=OFF
server.monitoring-service.module-monitoring-levels.cloud-elasticity=OFF
server.monitoring-service.module-monitoring-levels.cloud-orchestrator=OFF
server.monitoring-service.module-monitoring-levels.cloud-tenant-manager=OFF
server.monitoring-service.module-monitoring-levels.cloud-virt-assembly-service=OFF
server.monitoring-service.module-monitoring-levels.connector-connection-pool=OFF
server.monitoring-service.module-monitoring-levels.connector-service=OFF
server.monitoring-service.module-monitoring-levels.deployment=OFF
server.monitoring-service.module-monitoring-levels.ejb-container=OFF
server.monitoring-service.module-monitoring-levels.http-service=OFF
server.monitoring-service.module-monitoring-levels.jdbc-connection-pool=OFF
server.monitoring-service.module-monitoring-levels.jersey=HIGH
server.monitoring-service.module-monitoring-levels.jms-service=OFF
server.monitoring-service.module-monitoring-levels.jpa=OFF
server.monitoring-service.module-monitoring-levels.jvm=OFF
server.monitoring-service.module-monitoring-levels.orb=OFF
server.monitoring-service.module-monitoring-levels.security=OFF
server.monitoring-service.module-monitoring-levels.thread-pool=OFF
server.monitoring-service.module-monitoring-levels.transaction-service=OFF
server.monitoring-service.module-monitoring-levels.web-container=OFF
server.monitoring-service.module-monitoring-levels.web-services-container=OFF
server.monitoring-service.dtrace-enabled=false
server.monitoring-service.mbean-enabled=true
server.monitoring-service.monitoring-enabled=true
Command get executed successfully.

This output shows that the Jersey monitoring level is HIGH but other ones are disabled (OFF).

An alternative is to use the administration UI (by default on http://localhost:4848, for a standalone installation). Going to your configuration part on the left tree, you will have a Monitoring item where you can access the exact same entries:

Selecting the level you want on the left of the table for the corresponding module will activate the associated monitoring. Once the monitoring is activated, you'll generally need to restart the server to let GlassFish take it into account.

Once it is done, you can access the associated information through the Monitoring Data item of the left tree:

Here, you can see the monitored instances. (If you use a standalone GlassFish, you will probably have a single entry.) The View Monitoring Data column will let you select the data you want to see. If you click on Application, for instance, you will obtain the corresponding screen with the information filled in, depending on the monitoring level you activated before. Here is a sample screenshot:

Depending on the application, this is more or less useful. However, for us (a JAX-RS service), the Request Statistics block is interesting even if it gives high-level information. We can use it to monitor the maximum response time and error count. By itself, it will not be enough to improve the performance, but it will enable us to compare it with the client-side information; we can then easily obtain and validate our performance testing.

It is important to keep in mind that servers often give aggregated performance figures for recent production monitoring, not performance tuning. This doesn't mean that it is useless but that you will only rely on ad hoc monitoring to validate your performance measurement pipeline (your client or your request injector, to put it simply).