-
Couldn't load subscription status.
- Fork 2.3k
Add support to cluster stats API for enabling/disabling mapping_stats… #15377
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -68,6 +68,8 @@ public RestChannelConsumer prepareRequest(final RestRequest request, final NodeC | |
| clusterStatsRequest.timeout(request.param("timeout")); | ||
| clusterStatsRequest.setIncludeDiscoveryNodes(false); | ||
| clusterStatsRequest.useAggregatedNodeLevelResponses(true); | ||
| clusterStatsRequest.setIncludeMappingStats(request.paramAsBoolean("include_mapping_stats", true)); | ||
| clusterStatsRequest.setIncludeAnalysisStats(request.paramAsBoolean("include_analysis_stats", true)); | ||
|
Comment on lines
+71
to
+72
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Have we discussed these param names anywhere? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No there was no separate discussion for these param names. It can be part of this PR itself? open for suggestions. |
||
| return channel -> client.admin().cluster().clusterStats(clusterStatsRequest, new NodesResponseRestListener<>(channel)); | ||
| } | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,60 @@ | ||
| /* | ||
| * SPDX-License-Identifier: Apache-2.0 | ||
| * | ||
| * The OpenSearch Contributors require contributions made to | ||
| * this file be licensed under the Apache-2.0 license or a | ||
| * compatible open source license. | ||
| */ | ||
|
|
||
| package org.opensearch.action.admin.cluster.stats; | ||
|
|
||
| import org.opensearch.test.OpenSearchTestCase; | ||
| import org.opensearch.test.client.NoOpClient; | ||
| import org.junit.After; | ||
| import org.junit.Before; | ||
|
|
||
| public class ClusterStatsRequestBuilderTests extends OpenSearchTestCase { | ||
|
|
||
| private NoOpClient testClient; | ||
|
|
||
| @Override | ||
| @Before | ||
| public void setUp() throws Exception { | ||
| super.setUp(); | ||
| this.testClient = new NoOpClient(getTestName()); | ||
| } | ||
|
|
||
| @Override | ||
| @After | ||
| public void tearDown() throws Exception { | ||
| this.testClient.close(); | ||
| super.tearDown(); | ||
| } | ||
|
|
||
| public void testUseAggregatedNodeLevelResponses() { | ||
| ClusterStatsRequestBuilder clusterStatsRequestBuilder = new ClusterStatsRequestBuilder( | ||
| this.testClient, | ||
| ClusterStatsAction.INSTANCE | ||
| ); | ||
| clusterStatsRequestBuilder.useAggregatedNodeLevelResponses(false); | ||
| assertFalse(clusterStatsRequestBuilder.request().useAggregatedNodeLevelResponses()); | ||
| } | ||
|
|
||
| public void testIncludeMappingStats() { | ||
| ClusterStatsRequestBuilder clusterStatsRequestBuilder = new ClusterStatsRequestBuilder( | ||
| this.testClient, | ||
| ClusterStatsAction.INSTANCE | ||
| ); | ||
| clusterStatsRequestBuilder.includeMappingStats(false); | ||
| assertFalse(clusterStatsRequestBuilder.request().isIncludeMappingStats()); | ||
| } | ||
|
|
||
| public void testIncludeAnalysisStats() { | ||
| ClusterStatsRequestBuilder clusterStatsRequestBuilder = new ClusterStatsRequestBuilder( | ||
| this.testClient, | ||
| ClusterStatsAction.INSTANCE | ||
| ); | ||
| clusterStatsRequestBuilder.includeAnalysisStats(false); | ||
| assertFalse(clusterStatsRequestBuilder.request().isIncludeAnalysisStats()); | ||
| } | ||
| } |
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.
APIs like Index Stats, Node Stats already provide a way to handle filtering the required stats through URI Path. Is it possible to implement a similar logic here?
e.g. index stats
/{index}/_stats/{metric}e.g. node stats
/_nodes/{nodeId}/stats/{metric}/{index_metric}We can add a similar route like
/_cluster/stats/{metrics}/{sub_metrics}wheremetricscan benodesorindicesor both. And sub metrics can be specific details within stats likemappings,analysisThis should help maintain a common pattern across different stats APIS
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.
Thanks for the inputs @mgodwan but the use-case here is little different. In the the URI path approach client can fetch stats for a specific metric whereas for this issue we want to add support for filtering out some information from the overall response that client does not need.
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.
The motivation behind this PR seems to be #14447 which mentions
Reduced OverheadandFine-Grained Controlas the benefitsHence, opting-in to fetch required metrics still seem to be a way which we should explore to handle as it aligns with these benefits while keeping the API signature streamlined across different stats APIs.
e.g. if new fields are added to the cluster stats response in a new OS version, users may start to see the overhead similar to what is mentioned in the parent issue due to some new computation happening. Opt-in mechanism like URI path ensures users only get what they want from cluster stats if they are sensitive to performance of these APIs or are concerned about computation overhead of these on the cluster. And as existing APIs work, if no filter is provided, it defaults to ALL which means all stats should be returned, and continues to maintain a backward compatible way for this existing API as well.
Uh oh!
There was an error while loading. Please reload this page.
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 get the concerns, but I don't understand how we can use the URI paths to selective exclude some stats from the default response. For APIs like
_cluster/healthwe support request paramsinclude_defaultsto additionally fetch default settings in addition to the default response. Conversely, in this use-case request params is being used to exclude some information from the default response.By default the value of the params is set to true which ensures the default behavior of API remains unchanged and is backward compatible. If the confusion is arising from the choice of param names, would
exclude_mapping_statsandexclude_analysis_statsbe a better logical choice?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.
@mgodwan I would prefer the uri based approach. But, like @SwethaGuptha mentioned we need to maintain backward compatibility so can't turn it off by default. Now, we can explore the URI approach where metric can excluded/ included in via sub-metric