How to Monitor Elasticsearch Performance: Query, Indexing, and JVM Metrics

During Elasticsearch operations, issues like node unavailability, out‑of‑memory errors, and long garbage‑collection pauses can disrupt services, so proactive monitoring is essential.

This piece is the first part of Emily Chang’s translated article “How to monitor Elasticsearch performance.”

It references several related articles on Elasticsearch basics, security, and architecture.

Key monitoring domains

1. Query and indexing performance 2. Memory allocation and garbage collection 3. Host‑level system and network metrics 4. Cluster health and node availability (to be covered later) 5. Resource saturation and related errors (to be covered later)

Query Performance Metrics

Search requests consist of two phases—Query and Fetch. The article describes the end‑to‑end flow with six steps: client sends request to a coordinating node, the request is forwarded to shard replicas, each shard executes the search, results are merged, the coordinating node issues a multi‑GET for the needed documents, and finally the data is returned to the client. Monitoring query latency and the Query/Fetch metrics helps detect performance regressions.

Additional query‑related metrics include concurrent query load, query thread‑pool queue usage, and fetch latency, which can indicate disk‑I/O bottlenecks or overly large result sets.

Indexing Performance Metrics

Indexing involves two internal processes: refresh and flush . Refresh writes buffered documents to a new segment (default every second) so they become searchable. Flush persists all in‑memory segments to disk and clears the translog; it can be triggered by translog size, durability settings, or a periodic interval. Diagrams illustrate both processes.

Indexing latency can be derived from index_total and index_time_in_millis . For bulk indexing, reducing the refresh interval or disabling refresh temporarily can improve throughput, but the setting should be restored after the load.

Memory Allocation and Garbage Collection

Elasticsearch relies on JVM heap and the operating system’s file‑system cache. Recommended heap size is ≤50 % of RAM and never more than 32 GB. Over‑sized heaps cause long GC pauses, while undersized heaps lead to OutOfMemory errors.

Key JVM metrics to watch include heap usage (used vs. committed), GC pause duration and frequency, and overall memory consumption. When heap usage exceeds ~75 % GC is triggered; sustained usage above 85 % suggests the need for larger heap or additional nodes.

Conclusion

The article covered three major monitoring areas—query/indexing performance, memory allocation & garbage collection, and host‑level system metrics—providing a foundation for maintaining a healthy Elasticsearch cluster.