[Telemetry] Full schema definition#90273
Conversation
65d7788 to
1e17622
Compare
x-pack/plugins/telemetry_collection_xpack/schema/xpack_root.json
Outdated
Show resolved
Hide resolved
| } | ||
| } | ||
| }, | ||
| "DYNAMIC_KEY": { |
There was a problem hiding this comment.
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.
cc/ @elastic/infra-telemetry
There was a problem hiding this comment.
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.
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) |
YulNaumenko
left a comment
There was a problem hiding this comment.
Alerting related changes LGTM.
|
@elasticmachine merge upstream |
There was a problem hiding this comment.
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 |
config-schema instead of our schema implementation?
#85810
|
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 |
TinaHeiligers
left a comment
There was a problem hiding this comment.
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: |
TinaHeiligers
left a comment
There was a problem hiding this comment.
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
schemadefinitions 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_ossdefinition.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