Skip to content
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

Create @elastic/analytics package #128407

Merged
merged 39 commits into from
Apr 5, 2022

Conversation

afharo
Copy link
Member

@afharo afharo commented Mar 23, 2022

Summary

This PR creates the new @elastic/analytics package and all the tasks involved in this process:

  • Create the @elastic/analytics package
  • Unit Tests in the package
  • Export the Jest mocks for the shipper and the analyticsClient APIs
  • Create the core.analytics service both:
    • server
    • public
  • Export the Jest mocks from the core service
    • server
    • public
  • Create FTR tests
    • server
    • public
  • Create FTR helpers
    • server
    • public
  • Add CODEOWNERS

Resolves #121995.

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@afharo afharo added release_note:skip Skip the PR/issue when compiling release notes backport:skip This commit does not require backporting v8.2.0 labels Mar 23, 2022
@afharo afharo force-pushed the ebt/create-elastic-analytics-package branch from de2dbe8 to 867b983 Compare March 23, 2022 18:10
@afharo afharo force-pushed the ebt/create-elastic-analytics-package branch from 7e3f267 to dcd11c5 Compare March 24, 2022 20:05
@afharo
Copy link
Member Author

afharo commented Mar 30, 2022

@elasticmachine merge upstream

Copy link
Contributor

@pgayvallet pgayvallet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found some other minor NITS, but overall LGTM!

We may want a second review from another team member though, to make sure we didn't miss anything.

* @param eventType the event type to check for the shipper
*/
public isShipperOptedIn(shipperName: ShipperName, eventType?: EventType): boolean {
const isGlobalOptedIn = this.isOptedIn();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: I would exit fast here, instead of keeping this value and executing the following logic when unnecessary

if(!this.isOptedIn()) {
   return false;
}

Same for isEventTypeOptedIn

Can also do the same with isShipperGloballyOptedIn

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense! Updated!

/**
* Who emitted the event? It can be "client" or the name of the shipper.
*/
source: 'client' | ShipperName;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: given client is a special value here, I wonder if we should be forbidding to register a shipper with the client name.

Comment on lines +66 to +68
* Code to provide additional information about the success or failure. Examples are 200/400/504/ValidationError/UnknownError
*/
code: string;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we somehow come with a defined list of values for this code? I'm guessing not given it can be specified by the shipper when encountering an error, but still asking.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd leave it open for now to allow shippers to provide context about their failures. But yeah... we could potentially limit this in the future.

Comment on lines +37 to +39
// TODO: We need to be able to edit sendTo once we resolve the telemetry config.
// For now, we are relying on whether it's a distributable or running from source.
sendTo: core.env.packageInfo.dist ? 'production' : 'staging',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can definitely be done in a follow-up, but thinking out loud, I wonder how we will be able to access the telemetry config from core. Should we expose an API for another actor to call it with the config? Should core access the telemetry config directly (it's hacky and a bad isolation of concern, but technically core can access any plugin's config...)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah! I'm still wrapping my head about the best way to spread the config given the architecture of Kibana.

I've created #129014 to discuss and find out our preferred approach.

@afharo
Copy link
Member Author

afharo commented Mar 31, 2022

Just for traceability:

  • The scaffolding for the dedicated FTR test suite is great, but I wonder if that's the most efficient tooling we can provide to teams to test their events. I would expect a way/tool for them to run any FTR functional suite (e.g displaying a dashboard, creating an ML rule), and then being able to retrieve the events that were sent during the scenario to check them. Do you think that make sense?

I wish we could offer a simple helper. However, the way this client works requires a plugin to register the FTR-helper shipper. If folks want to use them in their suites, they can change their config to import the plugin and the FTR helper. That was my intention with the last line of the README in that directory. WDYT?

@pgayvallet
Copy link
Contributor

I wish we could offer a simple helper. However, the way this client works requires a plugin to register the FTR-helper shipper. If folks want to use them in their suites, they can change their config to import the plugin and the FTR helper. That was my intention with the last line of the README in that directory. WDYT?

Yea, I'm not sure we can really do better than. Was just mentioning it because it would have been great, but if we can't, what you did in this PR is good.

@afharo afharo added v8.3.0 and removed v8.2.0 labels Mar 31, 2022
@afharo
Copy link
Member Author

afharo commented Mar 31, 2022

Changing the label from v8.2.0 to v8.3.0 because there's no need to actually backport these changes to 8.2 as it currently has no users.

Copy link
Member

@Bamieh Bamieh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 1 question about an @deprecated comment

export interface RegisterShipperOpts {
/**
* List of event types that will be received only by this shipper.
* @deprecated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's explained in the following line:

Set as internal and deprecated until we come up with the best design for this. Not in the scope of the initial MVP.

At the moment we don't have a @beta-please-do-not-use tag.

@afharo afharo enabled auto-merge (squash) April 5, 2022 13:54
@afharo
Copy link
Member Author

afharo commented Apr 5, 2022

Agreed on Slack: as we are reaching the end of our sprint, I'll go ahead and merge this PR. Any comments from @lukeelmers will be addressed in future PRs.

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
core 335 346 +11

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@elastic/analytics - 11 +11

Any counts in public APIs

Total count of every any typed public API. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats any for more detailed information.

id before after diff
@elastic/analytics - 1 +1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
core 132.3KB 132.3KB +27.0B

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id before after diff
kibana 310 323 +13

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
core 309.4KB 318.7KB +9.2KB
Unknown metric groups

API count

id before after diff
@elastic/analytics - 82 +82
core 2381 2497 +116
total +198

ESLint disabled line counts

id before after diff
@elastic/analytics - 16 +16
core 49 56 +7
total +23

Total ESLint disabled count

id before after diff
@elastic/analytics - 16 +16
core 59 66 +7
total +23

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@afharo afharo merged commit fcf8622 into elastic:main Apr 5, 2022
@afharo afharo deleted the ebt/create-elastic-analytics-package branch April 5, 2022 15:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:skip Skip the PR/issue when compiling release notes v8.3.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Event-based Telemetry] Create the external package @elastic/analytics in the Kibana monorepo
7 participants