-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Telemetry] Full schema
definition
#90273
[Telemetry] Full schema
definition
#90273
Conversation
65d7788
to
1e17622
Compare
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.
self-review/comments
x-pack/plugins/telemetry_collection_xpack/schema/xpack_root.json
Outdated
Show resolved
Hide resolved
} | ||
} | ||
}, | ||
"DYNAMIC_KEY": { |
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.
This comment applies to all the usages of DYNAMIC_KEY
int he *_root.json
files. Should we be more explicit in these, since we should know in advance all the possible values?
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.
cc/ @elastic/infra-telemetry
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 be more explicit in these, since we should know in advance all the possible values?
+1 for explicit values, if we know them in advance 🙏
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'd like some input from the ES team here to confirm if we'll know them in advance
Pinging @elastic/apm-ui (Team:apm) |
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.
Alerting related changes LGTM.
@elasticmachine merge upstream |
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.
LGTM
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.
Code LGTM.
I just want to voice my concerns here for the sake of clarity; As I stated earlier am not super happy baking these tests into our code base (#83704 (comment)). I am ok with merging this since the team feels OK doing that however.
I still believe we should not be having the full schema definition in kibana. We are basically adding tests for elasticsearch in our kibana codebase.
I'm worried that before every release all this will be skipped and marked as a flaky test.
The build priority is higher than fixing telemetry tests that fail from an ES update. This means the burden of updating those will always fall on our shoulders now.
The telemetry_check
will not fix the breaking changes in the root schemas (and cannot since there was a lot of manual checking involved to writing those root schemas).
@elasticmachine merge upstream |
Adding @rjernst as a reviewer because we are waiting for the input from the ES team because they'll have to maintain the possible changes coming from the ES APIs passed through. Related issue elastic/elasticsearch#58198 |
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.
Adding an LGTM to unblock a review needed from the kibana-telemetry team
@elasticmachine merge upstream Sorry for the noise, just keeping this up-to-date to test how often will this break in the future as other teams push features and changes :) |
@elasticmachine merge upstream Sorry for the noise (again), just keeping this up-to-date to test how often will this break in the future as other teams push features and changes :) |
@elasticmachine merge upstream Sorry for the noise (again), just keeping this up-to-date to test how often will this break in the future as other teams push features and changes :) |
In order to unblock some goodness this PR brings in (especially FTRs to make sure what we actually report matches what we claim in the schema), I've created the #92867 will add the definition of ES fields once we agree on the best way to keep them up-to-sync. |
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
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.
The changes since I last reviewed the PR look good to me.
My second review (this one) is a code-review only.
LGTM!
💔 Backport failed❌ 7.x: Commit could not be cherrypicked due to conflicts To backport manually, check out the target branch and run: |
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> # Conflicts: # test/api_integration/apis/telemetry/telemetry_local.ts
* [Telemetry] Full `schema` definition (#90273) Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> # Conflicts: # test/api_integration/apis/telemetry/telemetry_local.ts * Normalize test arguments with `master` * Normalize to `master` the `/api/settings` FTR tests
Summary
This PR adds the
schema
definitions to the full payloads sent from the OSS and X-Pack local collectors.It also creates some functional tests that validate that the schemas are up-to-date: for now, it primarily checks that we don't report fields that are not detailed in the schema. But it intentionally defines all the fields as optional. We can create additional tests in the future to ensure certain keys are mandatory.
Example of the error thrown during CI:
Last, but not least, it deletes the
legacy_oss
definition.TODO: Planned for a follow-up issue: define the monitoring payload (#90795).
Resolves #83704
Code Owners Review
Why am I required to review this? If your team has been asked to review, it is quite likely that we've found some issues when running the functional tests. I've tried to fix it the way I think it makes more sense to me, but please, let me know if a different approach should be taken in your collector.
Checklist
Delete any items that are not applicable to this PR.
For maintainers