# No thread pool info on dashboard of marvel 2.1?

**URL:** <https://discuss.elastic.co/t/no-thread-pool-info-on-dashboard-of-marvel-2-1/36350>\
**Category:** Elasticsearch\
**Tags:** elastic-stack-monitoring\
**Created:** [December 4, 2015, 6:20am UTC](https://discuss.elastic.co/t/no-thread-pool-info-on-dashboard-of-marvel-2-1/36350 "2015-12-04T06:20:56Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![makeyang](https://avatars.discourse-cdn.com/v4/letter/m/f05b48/32.png) [@makeyang](https://discuss.elastic.co/u/makeyang)\
**Post date:** [December 4, 2015, 6:20am UTC](https://discuss.elastic.co/t/no-thread-pool-info-on-dashboard-of-marvel-2-1/36350/1 "2015-12-04T06:20:56Z")

</div>

I'd like to confirm cause it is a very usefull info for my use case

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [December 4, 2015, 8:43am UTC](https://discuss.elastic.co/t/no-thread-pool-info-on-dashboard-of-marvel-2-1/36350/2 "2015-12-04T08:43:40Z")

</div>

That is correct, we're reworking all of the graphs to make sure we don't overload users, as Marvel 1 was a little crazy at times!

I'll let the team know about this though, as we are always after feedback on what is important.

---

<div class="post-metadata">

**Author:** ![makeyang](https://avatars.discourse-cdn.com/v4/letter/m/f05b48/32.png) [@makeyang](https://discuss.elastic.co/u/makeyang)\
**Post date:** [December 4, 2015, 9:40am UTC](https://discuss.elastic.co/t/no-thread-pool-info-on-dashboard-of-marvel-2-1/36350/3 "2015-12-04T09:40:10Z")

</div>

thanks.  
hope u guys can take it back ASAP

---

<div class="post-metadata">

**Author:** ![skearns](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/skearns/32/125945_2.png) [@skearns](https://discuss.elastic.co/u/skearns)\
**Post date:** [December 4, 2015, 1:50pm UTC](https://discuss.elastic.co/t/no-thread-pool-info-on-dashboard-of-marvel-2-1/36350/4 "2015-12-04T13:50:09Z")

</div>

Can you help clarify what you were using the threadpool information for in Marvel 1.x? For example, what specific issues would you diagnose, and with which charts?

Thanks for sharing!

---

<div class="post-metadata">

**Author:** ![makeyang](https://avatars.discourse-cdn.com/v4/letter/m/f05b48/32.png) [@makeyang](https://discuss.elastic.co/u/makeyang)\
**Post date:** [December 7, 2015, 1:33am UTC](https://discuss.elastic.co/t/no-thread-pool-info-on-dashboard-of-marvel-2-1/36350/5 "2015-12-07T01:33:02Z")

</div>

my server is write heavy server. I have to check the bulk thread size, bulk queue size, reject size etc.

---

<div class="post-metadata">

**Author:** ![djasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/djasek/32/11632_2.png) [@djasek](https://discuss.elastic.co/u/djasek)\
**Post date:** [August 25, 2016, 10:30pm UTC](https://discuss.elastic.co/t/no-thread-pool-info-on-dashboard-of-marvel-2-1/36350/6 "2016-08-25T22:30:29Z")

</div>

I would like to see queue and reject sizes in the new Marvel as well.  
In the past, I have found that monitoring queue size can provide a great early indicator that we are reaching the limits of performance of the cluster.

It would also be nice to have a graph of the CPU load from the various types of work. Something like the data provided by the hot\_threads call. I am thinking an area chart showing % CPU used by search, index, management, etc.

---

<div class="post-metadata">

**Author:** ![pickypg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pickypg/32/62409_2.png) [@pickypg](https://discuss.elastic.co/u/pickypg)\
**Post date:** [August 25, 2016, 11:46pm UTC](https://discuss.elastic.co/t/no-thread-pool-info-on-dashboard-of-marvel-2-1/36350/7 "2016-08-25T23:46:46Z")

</div>

> I would like to see queue and reject sizes in the new Marvel as well.

We hear you. While the next releases of Marvel (2.4 or X-Pack Monitoring 5.0) will not show the threadpool information directly, it _does_ pull out the most important threadpool queue and rejection counts. As a result, you can (and we will) make a standard Kibana dashboard that visualizes some of the data that we're not yet displaying. For Marvel 2.3 and 2.4, you can find this by querying the `/.marvel-es-1-*/node_stats` index/type.

In the not-too-distant future, we do expect to begin visualizing this type of information and it's already in the works.

> It would also be nice to have a graph of the CPU load from the various types of work. Something like the data provided by the hot\_threads call.

This sounds very interesting, but I do worry about the expense _and_ accuracy of doing it given the relative infrequency of the Marvel agent's polling (`10s` by default). Perhaps the CPU mixed with the [forthcoming `_nodes/usage` API](https://github.com/elastic/elasticsearch/pull/20124) may prove to be useful here though.

---

<div class="post-metadata">

**Author:** ![djasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/djasek/32/11632_2.png) [@djasek](https://discuss.elastic.co/u/djasek)\
**Post date:** [August 26, 2016, 5:03pm UTC](https://discuss.elastic.co/t/no-thread-pool-info-on-dashboard-of-marvel-2-1/36350/8 "2016-08-26T17:03:00Z")

</div>

Sounds good. Thanks.

I have already setup my own visualizations in Kibana for the reject count; looking forward to being able to do the same with queue sizes.

> [@pickypg](#):
>
> This sounds very interesting, but I do worry about the expense and accuracy of doing it given the relative infrequency of the Marvel agent's polling (10s by default).

Yeah, I have the pleasure of not needing to figure out how to make it work. 🙂  
The usage API looks interesting. I don't know if a simple count will be enough though, relocating a 1 GB shard does not use the same resources as relocating a 1 MB shard.  
Also, the important bit is the relative resource expense of, for example, the relocations going on compared to the queries being processed, which would be challenging to get right.

Just spit-balling here, but it looks like hot\_threads uses `ThreadMXBean.getThreadCpuTime` to calculate this info, which I don't think is too expensive. It might be reasonable to run this regularly and track CPU time usage, grouped into job type buckets. Tracking CPU time as threads enter/exit the thread pools, and running this every 10s doesn't seem ridiculous on the face of it.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 1:42pm UTC](https://discuss.elastic.co/t/no-thread-pool-info-on-dashboard-of-marvel-2-1/36350/9 "2017-07-06T13:42:17Z")

</div>

Closed on July 6, 2017, 1:42pm UTC


