Merge change from #220 (node aggregated metrics) to fs/branch_9x

[patsonluk]

Description

#220 merged it to fs/branch_9_3, So we are pulling that change to fs/branch_9x as well

[magibney]

I really think we should split the "autoCommit" metrics into a separate PR at least. But more generally: how badly do we need the autocommit metrics? If we think this info is useful, then we should upstream it ... it's certainly generic enough. EDIT: nevermind I see this was already here, fs-specific, just adjusting how it's done.

Also, just to be sure: the CoreMetricsAPICaller doesn't actually request metrics that were already found via the solr.node aggregate metrics group, right? Basically I'm hoping to confirm that we're saving effort by directly getting pre-aggregated metrics, and not doing both ways "just in case". I think that's how it's working, just looking to confirm.

[magibney]

LGTM, assuming a positive confirmation of my earlier question:

Basically I'm hoping to confirm that we're saving effort by directly getting pre-aggregated metrics, and not doing both ways "just in case".

[patsonluk]

LGTM, assuming a positive confirmation of my earlier question:

Basically I'm hoping to confirm that we're saving effort by directly getting pre-aggregated metrics, and not doing both ways "just in case".

Yes AggregateMetricsApiCaller will go through all the values declared in CoreMetric enum, if it's not found in the node aggregated metrics, it will put that into the missingCoreMetrics list (there will be a fix in another PR for concurrent access issue), which such list is picked up by CoresMetricsApiCaller which builds the query string based on the missingCoreMetrics list. So the second call from CoresMetricsApiCaller should only query on whatever is not yet covered by AggregateMetricsApiCaller

[magibney]

force-pushed to adjust the commit message on this merge -- the new merged commit is 0fd93bb