[Telemetry] move x-pack/monitoring collector classes to src/server/usage#20248
[Telemetry] move x-pack/monitoring collector classes to src/server/usage#20248tsullivan merged 10 commits intoelastic:masterfrom
Conversation
276fafa to
d095edc
Compare
3265c73 to
510f63d
Compare
pickypg
left a comment
There was a problem hiding this comment.
The current test failure is unrelated (PhantomJS / Reporting error), but I do have one question that might need someone else's feedback on the platform team. Otherwise LGTM.
|
|
||
| export function getSettingsCollector(server) { | ||
| const config = server.config(); | ||
| const { Collector } = server.usage; |
There was a problem hiding this comment.
This is creative. I wonder if this approach will work with the future plugin system / TypeScript?
There was a problem hiding this comment.
Earlier ago, I talked with @epixa about these changes and he let me know that if we're registering server methods as per the conventions from the Hapi ecosystem, we should be OK for at least the foreseeable future.
I mentioned Court on this so he can correct me if I misunderstood.
x-pack/plugins/reporting/index.js
Outdated
| } | ||
| }); | ||
| // Register a function with server to manage the collection of usage stats | ||
| const { collectorSet } = server.usage; |
There was a problem hiding this comment.
This is a nitpick, but why not just do
// Register a function with server to manage the collection of usage stats
server.usage.collectorSet.register(getReportingUsageCollector(server));Bringing the variable into scope seems unnecessary.
|
I'm taking the review label off this for now. After a chat with @ycombinator, I want to change some assumptions I was going with on this. This will get the changes documented in #20393 |
|
Once this is green, it will be ready again for review. I made some experimental changes that have been rolled back, which I did through rebase. The changes to do next are part of a Meta issue: #20393 |
💔 Build Failed |
| export class UsageCollector extends Collector { | ||
| constructor(server, properties) { | ||
| super(server, properties); | ||
| } |
There was a problem hiding this comment.
Do you even need the constructor here?
src/server/usage/index.js
Outdated
| collectorSet, // consumer code calls collectorSet.register(collector) to define their own collector objects | ||
| Collector, // helper class for consumer code implementing ops/stats collection | ||
| UsageCollector, // helper class for consumer codea implementing usage collection | ||
| }); |
There was a problem hiding this comment.
You could potentially avoid exposing the helper classes themselves by providing factory methods on CollectorSet like makeCollector(server, properties) and makeUsageCollector(server, properties). Internally these methods would new up and return Collector and UsageCollector instances, respectively.
Another argument for this pattern is that there is no use case for creating Collector or UsageCollector instances without having to use them with a collectorSet anyway. By requiring their creation via a collectorSet instance, you are at least hinting at this coupling a bit more strongly.
💚 Build Succeeded |
ycombinator
left a comment
There was a problem hiding this comment.
LGTM pending green CI
💚 Build Succeeded |
…age (elastic#20248) * [Monitoring/Telemetry] Move Usage service from Monitoring to Kibana core * fix tests * fix reporting integration * roll back more diffs * roll logger into bulk uploader to remove file duplication * fix xpack usage api * subclass constructor is not needed * collectorSet has factory methods for collector object creation * fix reporting usage jest test
|
6.x/6.4.0: #20955 |
…age (#20248) (#20955) * [Monitoring/Telemetry] Move Usage service from Monitoring to Kibana core * fix tests * fix reporting integration * roll back more diffs * roll logger into bulk uploader to remove file duplication * fix xpack usage api * subclass constructor is not needed * collectorSet has factory methods for collector object creation * fix reporting usage jest test
Part of Meta issue #20393
Closes #19534
Following along on #19691
Most of these code changes have already been reviewed. This PR moves the CollectorSet classes to
src/server/usageand registers the service differently. The service is longer dependent on the Monitoring plugin, so consumers should have it easier since they don't have to watch any plugin status before registering their collectors.Comments about needing to use the saved object client are partially dependent on #19662