[DOCS] Document thread_pool node stats
#50330
Conversation
Documents the `thread_pool` parameters returned by the `_nodes/stats` API.
jrodewig
added
>docs
|
Pinging @elastic/es-core-features (:Core/Features/Stats) |
|
Pinging @elastic/es-docs (>docs) |
| `thread_pool.analyze.threads`:: | ||
| (integer) | ||
| Number of threads in the `analyze` thread pool. | ||
|
|
||
| `thread_pool.analyze.queue`:: | ||
| (integer) | ||
| Number of tasks in queue for the `analyze` thread pool. | ||
|
|
||
| `thread_pool.analyze.active`:: | ||
| (integer) | ||
| Number of active threads in the `analyze` thread pool. | ||
|
|
||
| `thread_pool.analyze.rejected`:: | ||
| (integer) | ||
| Number of tasks rejected by the `analyze` thread pool executor. | ||
|
|
||
| `thread_pool.analyze.largest`:: | ||
| (integer) | ||
| Highest number of active threads in the `analyze` thread pool. | ||
|
|
||
| `thread_pool.analyze.completed`:: | ||
| (integer) | ||
| Number of tasks completed by the `analyze` thread pool executor. |
There was a problem hiding this comment.
Is there a good way from a writing perspective to parameterize these statistics? I bring this up because any plugin can create and name its own thread pools, which are added to the statistics output automatically if it's the correct type. The stats mean the same thing across every threadpool that can be returned so it should cut down on reading effort, as well as trying to maintain this list for every thread pool we add.
There was a problem hiding this comment.
I think we could do something like thread_pool.<thread_pool_name>.threads. We did something similar in the ingest section:
https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-stats.html#cluster-nodes-stats-api-response-body-ingest
I was debating this initially, but I decided to go with the current format because users might be searching for a specific thread pool name. However, I wasn't aware that this API would also pick up thread pools from plugins, which makes that direction kind of moot.
There was a problem hiding this comment.
Updated with 00ae054.
After looking at the preview, I decided against adding a default list and just letting the <thread_pool_name> placeholder stand as-is.
Also updated the ingest section to use snake_case.
There was a problem hiding this comment.
...users might be searching for a specific thread pool name
You could also potentially add the default thread pools names to the reference, but I think that sort of information is probably better documented elsewhere and linked to. Different thread pools often have a wide array of uses, which sometimes don't make sense without some decent explanation. It feels like it might be a bit much for a reference section.
Documents the
thread_poolparameters returned by the_nodes/statsAPI.