-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Expose agg usage in Feature Usage API #55732
Conversation
Counts usage of the aggs and exposes them on the _nodes/usage/. Closes elastic#53746
Pinging @elastic/es-analytics-geo (:Analytics/Aggregations) |
* Returns the name of the Values Source Type for stats purposes | ||
* @return the name of the Values Source Type | ||
*/ | ||
String value(); |
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 typeName()
instead? we're already using value
for a lot of things in aggregations support.
} | ||
} | ||
|
||
private static class MultiRegistryEntry extends RegistryEntry { |
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 don't think Multi should be it's own case. Instead, we can loop in the list version of register and just create multiple SingleRegistryEntry
records. That way, report usage can still track to a single ValuesSourceType, and the only "special case" is around Any, which we're planning to remove.
* @param aggregatorSupplier An Aggregation-specific specialization of AggregatorSupplier which will construct the mapped aggregator | ||
* from the aggregation standard set of parameters. | ||
*/ | ||
public void registerAny(String aggregationName, AggregatorSupplier aggregatorSupplier) { | ||
register(aggregationName, (ignored) -> true, aggregatorSupplier); | ||
register(aggregationName, new AnyRegistryEntry(aggregatorSupplier)); |
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.
So, @csoulios is working on a near term plan to get rid of the literal any, and replace registerAny with just registering all the CoreValuesSourceTypes
. We could adopt something like that here, and just register an explicit list of SingleRegistryEntry
cases instead. Or leave this as is and change it over when the rest of Christos's ANY work merges.
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.
Just pushed PR #55747 that removes registerAny()
method
After talking to @polyfractal I think I might need to redo this one. I feel like placement might have been wrong. We have aggregations that have 0, 1 or 2 ValuesSources, and this is not going away. So, I probably need to move this logic somewhere higher. |
@polyfractal @not-napoleon I think it is ready for review. |
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.
Left some comments, mainly around the periphery and with javadocs/comments/etc. I looked over the changes to the VSRegistry and they look fine to me, but I'll defer to @not-napoleon on the final say for that.
final Request index = new Request("POST", "/test/_doc/" + i); | ||
index.setJsonEntity("{\"str\": \"val\", \"foo\":\"bar\", \"num\": 5, \"start\": \"2020-03-15\"}"); | ||
client().performRequest(index); | ||
} |
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.
Should we refresh after indexing? Or does it not matter for the usage stats if the fields are potentially unmapped?
If it doesn' matter, maybe we could skip indexing to save some time?
"org.elasticsearch.rest.action.document.RestGetAction": 1, | ||
"org.elasticsearch.rest.action.search.RestSearchAction": 19, <3> | ||
"org.elasticsearch.rest.action.admin.cluster.RestNodesInfoAction": 36 | ||
"nodes_usage_action": 1, |
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.
Was this name change due to the PR, or were the docs always incorrect?
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.
No, we ignore this section. So when it was refactored in May 2017 we didn't update the docs.
@@ -483,6 +488,8 @@ private void registerAggregation(AggregationSpec spec, ValuesSourceRegistry.Buil | |||
Consumer<ValuesSourceRegistry.Builder> register = spec.getAggregatorRegistrar(); | |||
if (register != null) { | |||
register.accept(builder); | |||
} else { | |||
usageService.registerAggregationUsage(spec.getName().getPreferredName()); |
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.
Could we add a comment here, to the effect of the registry handles usage tracking, but since not all aggs use it we need to track the other ones explicitly? I feel like I'll stumble on this in the future and be confused :)
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.
Hmm, I was 100% I had this comment there. Strange.
@@ -238,4 +240,7 @@ protected static Aggregator asMultiBucketAggregator(final AggregatorFactory fact | |||
return new MultiBucketAggregatorWrapper(bigArrays, searchContext, parent, factory, first); | |||
} | |||
|
|||
public String getStatsSubtype() { |
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.
Could we add a javadoc for what this is/used for?
|
||
registerAggregation(new AggregationSpec(AvgAggregationBuilder.NAME, AvgAggregationBuilder::new, AvgAggregationBuilder.PARSER) | ||
.addResultReader(InternalAvg::new) | ||
.setAggregatorRegistrar(AvgAggregationBuilder::registerAggregators), builder); | ||
registerAggregation(new AggregationSpec(WeightedAvgAggregationBuilder.NAME, WeightedAvgAggregationBuilder::new, | ||
WeightedAvgAggregationBuilder.PARSER).addResultReader(InternalWeightedAvg::new), builder); | ||
WeightedAvgAggregationBuilder.PARSER).addResultReader(InternalWeightedAvg::new) | ||
.setAggregatorRegistrar(WeightedAvgAggregationBuilder::registerUsage), builder); |
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.
Heh, this is a bit cheeky...took me a minute to figure out what was going on here :)
|
||
public void incAggregationUsage(String aggregationName, String valuesSourceType) { | ||
Map<String, LongAdder> valuesSourceMap = aggs.get(aggregationName); | ||
// Not all aggs register their usage at the moment we also don't register them in test context |
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.
Are there other aggs that aren't caught by the else
in SearchModule (using registerAggregationUsage(String aggregationName)
)?
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.
Hmm, good point. Let's find out.
if (adder != null) { | ||
adder.increment(); | ||
} else { | ||
throw new IllegalArgumentException("Unknown subtype [" + aggregationName + "][" + valuesSourceType + "]"); |
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 wonder if we should just log an error but not actually throw an exception? I'm thinking if we end up breaking something on the usage side, it'd be a shame if it actually broke the aggs until we got a bugfix out
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.
That helped me to find a lot of strange behaving aggregations. But you are right, I might just replace this with assert for now.
@@ -105,6 +105,7 @@ public AnalyticsPlugin() { } | |||
TTestAggregationBuilder::new, | |||
usage.track(AnalyticsStatsAction.Item.T_TEST, checkLicense(TTestAggregationBuilder.PARSER))) |
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.
Hmm... we should probably discuss if we still want these being tracked separately? Unrelated to this PR though, just something I hadn't thought about :)
@elasticmachine update branch |
Suppresses bwc tests for backport of elastic#55732
Counts usage of the aggs and exposes them on the _nodes/usage/. Closes elastic#53746
Suppresses bwc tests for backport of #55732
Updates the serialization version and re-enables bwc tests for nodes usage api after backport of elastic#55732
Updates the serialization version and re-enables bwc tests for nodes usage api after backport of #55732
Relates: #4718, elastic/elasticsearch#55732 Co-authored-by: Russ Cam <[email protected]>
Relates: #4718, elastic/elasticsearch#55732 Co-authored-by: Russ Cam <[email protected]>
Counts usage of the aggs and exposes them on the /_nodes/usage.
Closes #53746