Apache Tomcat runs Java web applications, and monitoring it well means watching both the JVM underneath it and the application layer on top, not just whether the process is running.
Enabling JMX (recommended)
Tomcat exposes detailed runtime metrics through JMX (Java Management Extensions). To use it:
- Enable remote JMX in Tomcat's startup configuration, setting a port for JMX connections.
- Restrict access to that JMX port to the iPM server (and any other trusted monitoring source) — like other management endpoints, it shouldn't be openly reachable.
- Restart Tomcat to apply the change.
- Configure the Tomcat service check in iPM to connect over JMX.
What you can monitor
- Process / port — is Tomcat running and listening on its configured HTTP connector port
- JVM heap usage — how much of the allocated heap is in use, and how it trends over time; a heap that climbs steadily and never drops after garbage collection is an early warning sign of a memory leak
- Thread pool usage — busy versus available threads in the connector's thread pool, similar in spirit to Apache's worker utilization
- Garbage collection activity — frequency and duration of GC pauses, which directly affect application responsiveness under load
- HTTP response check — a request to a real application endpoint, confirming the deployed application is actually responding correctly, not just that the JVM is alive
Why heap trends matter most
Of everything above, a slowly climbing heap that doesn't recover after garbage collection is usually the earliest warning of a problem — by the time Tomcat becomes visibly slow or unresponsive, the JVM has often been under memory pressure for hours. A threshold alert on heap usage, watched over days rather than minutes, tends to catch application memory leaks well before end users notice anything.