Add analytics plugin usage stats to _xpack/usage#54911
Add analytics plugin usage stats to _xpack/usage#54911imotov merged 8 commits intoelastic:masterfrom
Conversation
Adds analytics plugin usage stats to _xpack/usage. Closes elastic#54847
|
Pinging @elastic/es-analytics-geo (:Analytics/Aggregations) |
| ResourceWatcherService resourceWatcherService, ScriptService scriptService, NamedXContentRegistry xContentRegistry, | ||
| Environment environment, NodeEnvironment nodeEnvironment, NamedWriteableRegistry namedWriteableRegistry, | ||
| IndexNameExpressionResolver indexNameExpressionResolver) { | ||
| return singletonList(new AnalyticsUsage()); |
| import org.elasticsearch.cluster.node.DiscoveryNode; | ||
| import org.elasticsearch.common.xcontent.ContextParser; | ||
| import org.elasticsearch.xpack.core.analytics.action.AnalyticsStatsAction; | ||
| import org.elasticsearch.xpack.core.watcher.common.stats.Counters; |
There was a problem hiding this comment.
I feel like we might be better off using an EnumMap<AnalyticsStatsAction.Item, AtomicLong> than this string based thing. Serialization would have to be a bit more explicit, but I don't mind that too much.
There was a problem hiding this comment.
On the other hand, Counters is nice from a BWC perspective. Maybe just move it out of the watcher package in a follow up change? Maybe drop the enum entirely and just us a string?
There was a problem hiding this comment.
I have replaced Counters with Enum-based Counters, which for now resides in the analytics package, but we can move it to a more generic package if we decide to start using them for other areas.
|
@polyfractal @nik9000 I implemented some changes. I would love to hear what you think about it. |
| vals[i] = val; | ||
| } | ||
| } | ||
| counters = new AtomicLongArray(vals); |
There was a problem hiding this comment.
So, like, we have to add enum entries to the end and they'll come through as 0 if they aren't set. Right?
There was a problem hiding this comment.
I think it is worth adding comments about that, both to the enum class and to this one.
There was a problem hiding this comment.
This is basically to handle the situation when an older node have less stat categories or a newer node has more stats categories. I added a comment to the enum but I agree I should duplicate it here.
| counters.inc(TestV1.A, 1); | ||
| counters.inc(TestV1.B, 2); | ||
| counters.inc(TestV1.C, 3); | ||
| EnumCounters<TestV2> newCounters = serialize(counters, in -> new EnumCounters<>(in, TestV2.class)); |
|
@polyfractal @nik9000 I have added comments that @nik9000 has requested. |
polyfractal
left a comment
There was a problem hiding this comment.
Left a few minor comments and a serialization question, but otherwise LGTM! Thanks for fixing <3
| @Override | ||
| protected void masterOperation(Task task, XPackUsageRequest request, ClusterState state, | ||
| ActionListener<XPackUsageFeatureResponse> listener) { | ||
| boolean available = licenseState.isDataScienceAllowed(); |
There was a problem hiding this comment.
Oof, just noticed "DataScience"... we should probably change that at some point 😓 Not for this PR though :)
| vals[i] = val; | ||
| } | ||
| } | ||
| counters = new AtomicLongArray(vals); |
| ttestUsage = 0; | ||
| counters = new EnumCounters<>(Item.class); | ||
| if (in.getVersion().onOrAfter(Version.V_7_7_0)) { | ||
| counters.inc(Item.BOXPLOT, in.readLong()); |
There was a problem hiding this comment.
I think this should be a readVLong() instead of readLong()?
| } | ||
|
|
||
| /** | ||
| * Items to track. Serialized by ordinals. Append only, don't remove or change order of items in this list. |
There was a problem hiding this comment.
Should we have a test somewhere that enforces this? E.g. enums that extend writeable directly can implement AbstractWriteableEnumTestCase. Not the same situation here, but having something conceptually similar to testValidOrdinals() would be nice. Just verifies that BOXPLOT == 0, etc etc
There was a problem hiding this comment.
Indeed we need a bwc test for usage. Right now it is completely broken so it didn't make sense to have it. But as soon as I back port this I will open a PR for bwc test for usage.
Adds analytics plugin usage stats to _xpack/usage. Closes elastic#54847

Adds analytics plugin usage stats to _xpack/usage. It looks like the usage
didn't report the actual usage in the previous versions. So, while it looks
like it is reported in 7.7, the numbers are always 0. Because code between 7.7
and 7.x/master is significantly different, I can open a separate PR for 7.7 if
we want to fix it there.
Closes #54847