- Notifications
You must be signed in to change notification settings - Fork 25.6k
Add thread_pool information to the cluster info endpoint #96407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
ensure the constructor is tested makes clearer when checking list order
| Documentation preview: |
| Pinging @elastic/es-data-management (Team:Data Management) |
| Hi @HiDAl, I've created a changelog YAML for you. |
| @elasticmachine run elasticsearch-ci/part-1 |
| @elasticmachine run elasticsearch-ci/packaging-tests-windows-sample |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @HiDAl this is looking great already! I started a discussion on some small topics :).
| ThreadPoolStats.Stats.merge(firstStats.get(1), secondStats.get(2)), // name-2 | ||
| ThreadPoolStats.Stats.merge(firstStats.get(2), secondStats.get(3)), // name-3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer here to not use the methods we are testing, I would be ok with writing a helper function for this but in the test. The idea behind this is, if a bug is introduced accidentally in ThreadPoolStats.Stats.merge we will catch it easier.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I thought the same while writing this. That's the reason why I wrote a separate test for this method at testStatsMerge() (a couple of lines below). IMO, that would give us enough confidence in case a bug is introduced to the other method it'll be caught. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, I do have a preference to have it not calling the merge, in case the other test is removed or changed somehow, but I understand if you want to leave it as is.
| Ingest information. | ||
| | ||
| `thread_pool`:: | ||
| Statistics about each thread pool, including current size, queue and rejected tasks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should say queue size instead of queue, what do you think?
| [[cluster-info-api-response-body-threadpool]] | ||
| `thread_pool`:: | ||
| (object) | ||
| Contains thread pool information of the cluster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe Contains information about the thread pools of the cluster reads a bit better? What do you think?
| ====== | ||
| `<thread_pool_name>`:: | ||
| (object) | ||
| Contains information about the thread pool of the cluster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about something like this:
Contains information about the thread pool of the cluster with name
<thread_pool_name>.
| .reduce(IngestStats.IDENTITY, IngestStats::merge), | ||
| // | ||
| THREAD_POOL.metricName(), | ||
| response -> response.getNodes().stream().map(NodeStats::getThreadPool).reduce(ThreadPoolStats.IDENTITY, ThreadPoolStats::merge) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit, if I am not mistaken this response is the same as the nodesStatsResponse in the other metrics. I would prefer to have it consistent over all the metrics to show that they have the same input.
| assertThat(copy.stream().map(ThreadPoolStats.Stats::name).toList(), contains("a", "d", "m", "m", "m", "t", "z")); | ||
| assertThat(copy.stream().map(ThreadPoolStats.Stats::threads).toList(), contains(-1, 2, -3, 4, 5, 6, 7)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What exactly are we testing with these two lines? It's not very clear to me. I thought the next two lines would be sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are the old tests: basically, checking that the method compareTo is correct. anyway, you're right, the next 2 lines should suffice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I didn't think of that :), thanks for the explanation.
| public ThreadPoolStats { | ||
| Collections.sort(stats); | ||
| stats = Collections.unmodifiableList(stats); | ||
| var statsCopy = new ArrayList<>(stats); | ||
| Collections.sort(statsCopy); | ||
| stats = Collections.unmodifiableList(statsCopy); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Should we add another constructor that accepts a Collection to avoid having to do new ThreadPoolStats(new ArrayList<>(mergedThreadPools.values())) in the merge method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sadly no, it clashes because we're using a List<Stat> (List is a Collection)...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about changing the constructor to ThreadPoolStats(Collection<Stat> stats)?
ArrayList constructor is also accepting Collection:
public ArrayList(Collection<? extends E> c) {...} There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good idea, will change it. Thanks Mary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I added two comments that continue our previous discussion.
Add a new target (
thread_pool) to the/_infoAPI. It consolidates all the thread pools information from the cluster nodes and returns a summary at the cluster level (compared with_nodes/stats/thread_poolit lacks the<node>dimension)Closes #95393