Home Monitoring Application Monitoring

Application Monitoring

Application monitoring digs into application servers (like Tomcat, WebLogic, or JVM environments) to inspect execution threads and memory heaps.

Why Monitor Application?

Monitoring applications ensures that they are fast, reliable and available for users. It helps you:

  • Track the health and performance of critical transactions
  • Detect errors and exceptions in real time
  • Identify performance bottlenecks and slow components
  • Understand resource utilization and capacity needs
  • Improve user experience and business outcomes
How Application Monitoring Works
User
Request
Application Processes
Request
Monitored by
Agents/Probes
Data Collected
(Metrics, Logs)
Insights & Alerts
Generated
Agents collect data from various layers of the application and provide insights through dashboards and alerts.

1. JVM Heap Memory

Java applications allocate memory in Heap space. If the application does not release objects, the heap usage will grow continuously until it runs out of memory (OOM). We monitor Garbage Collection (GC) frequency and pause times.

Heap Used
1.62 GB (54.1%)
of 3.00 GB
Heap Committed
2.10 GB
of 3.50 GB
Heap Max
3.50 GB
JVM Memory Usage
54.1%
Used 1.62 GB
Free 1.38 GB
Max 3.00 GB
GC Frequency
Monitor Spikes
18
times / hour
GC Pause Times
< 50 ms
Max: 42 ms | Avg: 18 ms
Healthy
Heap Usage Trend (Last 1 Hour)
Heap Used
Heap Committed
3.0 GB2.0 GB1.0 GB0 GB
10:00 AM10:10 AM10:20 AM10:30 AM10:40 AM10:50 AM11:00 AM
Sawtooth pattern indicates healthy GC. If heap keeps growing without dropping, it may lead to OutOfMemoryError (OOM).

2. Thread Monitoring

Analyze thread states to understand application concurrency bottlenecks.

Runnable Threads

Active threads currently executing application code.

215 threads
45.2% of total
Blocked Threads

Threads waiting to acquire locks or waiting on DB connections.

32 threads
6.7% of total
Waiting Threads

Threads waiting for resources, I/O or sleep.

28 threads
5.9% of total
Thread Pool Utilization

If thread usage reaches 100%, incoming requests are queued.

78 %
Healthy
390 of 500 threads used
Thread Details by State
State Description Count % of Total Trend (Last 1 Hour)
Runnable
 Threads actively executing application code 215 45.2%
Blocked
 Threads waiting to acquire locks or waiting on DB connections 32 6.7%
Waiting
 Threads waiting for resources, I/O or sleep 28 5.9%
Timed Waiting
 Threads waiting with timeout for a certain condition 172 38.2%
Total
 447 100% —
Thread Pool Summary
Core Pool Size200
Max Pool Size500
Active Threads390
Queue Size110
Rejected Requests12
Utilization78%
Healthy
High blocked or waiting threads may indicate lock contention or slow downstream dependencies.

What Do These Metrics Mean?

JVM Heap Memory

Higher heap usage with increasing trend may lead to OutOfMemoryError (OOM). A sawtooth pattern indicates that garbage collection is reclaiming memory successfully.

GC Frequency

A sudden increase in GC frequency may indicate memory pressure. Consistent high GC activity can can impact application performance.

GC Pause Times

Long GC pauses stop application threads and can cause request latency. Keep pause times consistently below 50ms for optimal performance.

Thread Monitoring

High runnable threads indicate good utilization. High blocked threads may indicate lock contention or database connection issues.

Thread Pool Utilization

As utilization approaches 100%, requests are queued, increasing response time. Keep utilization below 80% for headroom.

Best Practices

Monitor heap usage trend and GC activity continuously.

Keep GC pause times below 50ms for optimal performance.

Analyze thread states regularly to find bottlenecks.

Set alerts for high heap usage, GC spikes and thread pool exhaustion.