Apache Tomcat Performance Monitoring: Basics and Troubleshooting Tips

When Java web applications experience slowdowns or crashes, the culprit is often the Tomcat server. For DevOps engineers overseeing critical applications, proactive monitoring is crucial for ensuring optimal performance and reliability.

In this guide, we'll explore the essential aspects of monitoring Apache Tomcat servers, focusing on the key metrics to track, setting up robust monitoring systems, and troubleshooting common performance issues that could impact your application’s stability.

Apache Tomcat's Architecture

Apache Tomcat is an open-source web server and servlet container that powers countless Java applications worldwide. As a DevOps engineer, you're likely familiar with Tomcat's role in executing Java servlets and rendering web pages for your applications.

But why does monitoring Tomcat matter so much?

Simply put, Tomcat serves as the backbone of your Java web applications. When it struggles, your applications struggle – leading to slow response times, errors, and potentially complete outages. Proper monitoring helps you:

• Spot performance bottlenecks before users notice
• Track resource usage patterns
• Identify memory leaks early
• Reduce downtime through proactive maintenance
• Make data-driven decisions about scaling

Without good monitoring, you're essentially flying blind – hoping nothing goes wrong rather than actively preventing issues.

Essential Apache Tomcat Performance Metrics for Effective Monitoring

Let's cut to the chase – which metrics matter when monitoring Tomcat? Here are the essential ones you should keep an eye on:

JVM Memory Metrics

Tomcat runs on the Java Virtual Machine (JVM), so monitoring memory usage is critical:

• Heap Memory Usage: The amount of memory your Java applications are consuming
• Non-Heap Memory: Memory used by the JVM itself outside the heap
• Garbage Collection: How often GC runs and how long it takes
• Memory Pools: Status of different memory areas (Eden Space, Survivor Space, Old Gen)

High memory usage or frequent garbage collection cycles can signal memory leaks or insufficient allocation.

Thread Metrics

Threads handle concurrent requests in Tomcat, making them vital to monitor:

• Active Thread Count: Number of threads currently processing requests
• Thread Pool Utilization: How close you are to maxing out available threads
• Thread States: How many threads are running, waiting, or blocked
• Thread Response Time: How long threads take to complete requests

Thread issues often manifest as slowdowns when the server becomes overloaded.

Connection Metrics

Since Tomcat serves web traffic, connection metrics reveal a lot about performance:

• Current Connections: Number of active connections to your Tomcat server
• Connection Time: How long connections stay open
• Connection States: Distribution of connections across different states
• Connection Errors: Failed connections and their error codes

Connection bottlenecks can limit how many users your application can serve simultaneously.

Request Metrics

These metrics tell you about the actual work Tomcat is doing:

• Request Count: Total number of HTTP requests processed
• Request Duration: Time taken to process requests
• Request Size: Size of incoming requests
• Response Time: How quickly Tomcat responds to requests
• Status Codes: Distribution of HTTP response codes (200s, 400s, 500s)

Unusual patterns in these metrics often point directly to application issues.

System Resource Metrics

Beyond Tomcat-specific metrics, overall system resources matter too:

• CPU Usage: How much processor time Tomcat is consuming
• Disk I/O: Read/write operations and their latency
• Network Traffic: Incoming and outgoing data volumes
• System Load: Overall system load average

Resource constraints at the system level can throttle Tomcat's performance regardless of its configuration.

Getting started with Tomcat Monitoring

Here's how to set up a basic monitoring foundation:

Enable JMX for Tomcat

Java Management Extensions (JMX) expose Tomcat metrics that monitoring tools can collect:

# Add these parameters to CATALINA_OPTS in setenv.sh or catalina.sh
CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=9999 
-Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.authenticate=false 
-Djava.rmi.server.hostname=<your-server-ip>"

Remember to lock down JMX with proper authentication in production environments!

Configure Tomcat's Built-in Manager

Tomcat includes a Manager application that provides basic monitoring capabilities:

1. Edit tomcat-users.xml to add an admin user:

<role rolename="manager-gui"/>
<role rolename="admin-gui"/>
<user username="admin" password="your-secure-password" roles="manager-gui,admin-gui"/>

2. Access the Manager at http://your-server:8080/manager/status

This gives you a quick dashboard of your Tomcat's current status without additional tools.

Set Up Log Monitoring

Logs contain valuable information about Tomcat's health:

1. Configure proper log rotation in logging.properties:

handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler

2. Use a log aggregation tool to centralize and analyze logs

Scanning logs for ERROR and WARNING entries can catch issues early.

Monitoring Strategies for Complex Tomcat Deployments

Once you've got the basics covered, these advanced techniques will give you deeper insights:

Custom JMX MBeans

Create custom MBeans to expose application-specific metrics:

@MBean
public class ConnectionPoolMonitor implements ConnectionPoolMonitorMBean {
    private int activeConnections;
    
    public int getActiveConnections() {
        return activeConnections;
    }
    
    public void setActiveConnections(int connections) {
        this.activeConnections = connections;
    }
}

Register these MBeans in your application to track metrics unique to your business needs.

Health Check Endpoints

Implement health check endpoints in your applications:

@WebServlet("/health")
public class HealthCheckServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
        resp.setContentType("application/json");
        
        JSONObject health = new JSONObject();
        health.put("status", "UP");
        health.put("database", checkDatabase() ? "UP" : "DOWN");
        health.put("cache", checkCache() ? "UP" : "DOWN");
        
        resp.getWriter().write(health.toString());
    }
}

These endpoints let monitoring tools verify that your application is functioning correctly, not just that Tomcat is running.

Monitoring with OpenTelemetry

Implement distributed tracing with OpenTelemetry to track requests across services:

1. Add the OpenTelemetry Java agent to your Tomcat startup:

CATALINA_OPTS="$CATALINA_OPTS -javaagent:/path/to/opentelemetry-javaagent.jar"

2. Configure the agent to send data to your observability platform

This approach provides end-to-end visibility into request flows, especially valuable in microservice architectures.

A Comprehensive Comparison of Tomcat Monitoring Solutions

Several tools can help you monitor Tomcat effectively. Here's how they compare:

If you're looking for a managed observability solution that delivers top performance without breaking your budget, Last9 is the answer. Our telemetry data platform efficiently handles high-cardinality data at scale, with proven experience in monitoring major live-streaming events.

By integrating with both OpenTelemetry and Prometheus, we enable you to centralize your metrics, logs, and traces, giving you correlated insights without the hassle of managing multiple tools.

Troubleshooting and Resolving Critical Tomcat Performance Bottlenecks

Even with solid monitoring, issues can arise. Here's how to tackle the most common Tomcat performance problems:

High Memory Usage

Signs in monitoring:

• Increasing heap usage that doesn't decrease after GC
• Frequent full GC cycles

Solutions:

• Analyze with tools like VisualVM or Eclipse MAT
• Look for accumulated collections or cached objects not being released
• Check for connection leaks in a database or the HTTP client code

Take heap dumps during high memory usage:

jmap -dump:format=b,file=heap.bin <pid>

Thread Pool Exhaustion

Signs in monitoring:

• Thread count near configured maximum
• Increasing request processing times
• Connection timeouts

Solutions:

• Profile to find slow operations blocking threads
• Implement asynchronous processing for long-running tasks
• Consider non-blocking I/O for high-concurrency scenarios

Increase thread pool size temporarily to handle load spikes:

<Connector port="8080" protocol="HTTP/1.1"           maxThreads="400" minSpareThreads="20"/>

Slow Response Times

Signs in monitoring:

• Increasing average response time
• High CPU usage
• Normal memory and thread patterns

Solutions:

• Check database query performance
• Look for external service calls that might be timing out
• The %D parameter shows request processing time in milliseconds

Enable access logging with timing information:

<Valve className="org.apache.catalina.valves.AccessLogValve"       pattern="%h %l %u %t &quot;%r&quot; %s %b %D"/>

Excessive Garbage Collection

Signs in monitoring:

• Frequent GC pauses
• Application "stop-the-world" events
• Sawtooth memory usage pattern

Solutions:

• Increase heap size if needed
• Consider adjusting generation sizes based on application characteristics
• Profile object creation to reduce garbage generation

Tune JVM garbage collection settings:

CATALINA_OPTS="$CATALINA_OPTS -XX:+UseG1GC -XX:MaxGCPauseMillis=200"

How to Set an Effective Alert Strategy for Tomcat Server Monitoring

Monitoring is only useful if you know when to take action. Here's how to set up effective alerts:

Critical Alerts

These need immediate attention:

• JVM Crashes: Set up alerts for unexpected Tomcat shutdowns
• Out of Memory Errors: Alert when heap usage approaches maximum
• HTTP 5xx Error Rate: Notify when error rates exceed 1-2%
• Response Time Spikes: Alert on sudden increases in latency

Warning Alerts

These indicate potential future problems:

• Increasing Memory Usage: Alert when usage trends upward over days
• Thread Pool Utilization: Notify at 80% capacity
• Slow Garbage Collection: Alert when GC takes more than 500ms
• Database Connection Pool: Notify at 80% utilization

Alert Tuning Best Practices

• Start with conservative thresholds and adjust based on false positives
• Implement alert aggregation to prevent notification storms
• Add context to alerts (links to dashboards, runbooks)
• Establish escalation paths for different alert severities

Automated Tomcat Monitoring and Remediation Workflows

Take your monitoring to the next level with automation:

Auto-Scaling Based on Metrics

Configure your infrastructure to scale based on monitoring metrics:

# Example Kubernetes HPA configuration
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: tomcat-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: tomcat-deployment
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

This automatically scales your Tomcat instances based on CPU usage.

Automated Recovery Scripts

Create scripts that can resolve common issues automatically:

#!/bin/bash
# Example script to restart Tomcat if memory usage exceeds threshold

HEAP_USAGE=$(jstat -gc $(pgrep java) | tail -n 1 | awk '{print $3+$4+$6+$8}')
MAX_HEAP=$(jstat -gccapacity $(pgrep java) | tail -n 1 | awk '{print $4+$6+$10}')

if [ $(echo "$HEAP_USAGE > $MAX_HEAP * 0.9" | bc) -eq 1 ]; then
  echo "High memory detected, restarting Tomcat" | logger
  /path/to/tomcat/bin/shutdown.sh
  sleep 10
  /path/to/tomcat/bin/startup.sh
fi

Such scripts can take corrective action before issues impact users.

Tomcat Monitoring Strategy for Modern Deployment Patterns

As technology evolves, so should your monitoring approach:

Containerization Considerations

If moving Tomcat to containers:

• Add container-specific metrics (restart count, resource limits)
• Use a service mesh for deeper visibility into container communication
• Consider specialized tools for Kubernetes monitoring if applicable

Monitoring as Code

Version your monitoring configuration alongside application code:

# Example Prometheus alert configuration
groups:
- name: tomcat_alerts
  rules:
  - alert: TomcatHighMemoryUsage
    expr: sum(jvm_memory_bytes_used{application="tomcat"}) / sum(jvm_memory_bytes_max{application="tomcat"}) > 0.85
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Tomcat memory usage high"
      description: "Tomcat is using more than 85% of available memory for more than 5 minutes"

This approach ensures consistent monitoring across environments and makes changes trackable.

Conclusion

Effective Tomcat monitoring requires focusing on core metrics like JVM performance, thread utilization, connection management, and request processing.

The real value comes from using this data to gain insights and drive improvements. Regular performance reviews and continuous optimization are key to maximizing your monitoring investment.

FAQs

How often should I check Tomcat metrics?

For most metrics, collecting data every 15-30 seconds provides good visibility without excessive overhead. Critical production systems might benefit from 5-second intervals for faster detection of issues.

What's the difference between Tomcat monitoring and Java application monitoring?

Tomcat monitoring focuses on the server itself (threads, connections, etc.), while Java application monitoring looks deeper into your code's performance (method calls, database queries, etc.). A complete monitoring strategy includes both.

Can Tomcat monitoring help identify security issues?

Yes, indirectly. Unusual patterns in connections, requests, or resource usage can indicate potential security incidents. Monitoring failed login attempts to the Manager application and watching for unexpected deployment activities are also valuable security practices.

Do I need different monitoring for development and production Tomcat instances?

While the core metrics remain the same, production environments typically need more comprehensive monitoring, stricter alerting thresholds, and higher reliability in the monitoring infrastructure itself. Development environments can often use simpler, more developer-focused tooling.

How do I monitor multiple Tomcat instances efficiently?

Centralized monitoring tools with agent-based collection are ideal for multiple instances. Consider using service discovery to automatically detect and monitor new Tomcat instances as they're deployed.