# Stats around elasticsearch percolator queries **URL:** \ **Category:** Elasticsearch\ **Created:** [November 16, 2019, 4:48pm UTC](https://discuss.elastic.co/t/stats-around-elasticsearch-percolator-queries/208175 "2019-11-16T16:48:54Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Faiz\_Ahmed\_Mushtak\_H](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/faiz_ahmed_mushtak_h/32/47387_2.png) [@Faiz\_Ahmed\_Mushtak\_H](https://discuss.elastic.co/u/Faiz_Ahmed_Mushtak_H)\ **Post date:** [November 16, 2019, 4:48pm UTC](https://discuss.elastic.co/t/stats-around-elasticsearch-percolator-queries/208175/1 "2019-11-16T16:48:54Z")
After the unification of percolators as searches, all the metrics around percolators that were there in 1.x/2.x are gone. It kind of makes it difficult to figure out what's going on in percolation Searches and percolations are very different use cases in my opinion & sometimes it's hard to tell why CPU spikes happened on our percolation server. They mostly depend on the document coming in and based on the fields ES deciding potential candidates As a production deployment, we need metrics like how many percolators ES is trying for a document, can be a percolate\_total/percolate\_current metric at an index level or in the response some field telling us how many potential percolators ES tried for this document and how many actually matched. The latter can be found using the hits.total.value so that's not an issue. We usually are blind as to why our servers spiked ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [December 14, 2019, 4:49pm UTC](https://discuss.elastic.co/t/stats-around-elasticsearch-percolator-queries/208175/2 "2019-12-14T16:49:08Z")
Closed on December 14, 2019, 4:49pm UTC This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.