-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Usage collection] Collect non-default kibana configs #97368
[Usage collection] Collect non-default kibana configs #97368
Conversation
Pinging @elastic/kibana-core (Team:Core) |
Pinging @elastic/kibana-telemetry (Team:KibanaTelemetry) |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@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.
Overall, it looks great! Good job @Bamieh! I just added some NITs and 2 potential issues we might want to look at before merging this PR:
- startsWith check
- array of objects
src/core/server/core_usage_data/core_usage_data_service.test.ts
Outdated
Show resolved
Hide resolved
...ns/kibana_usage_collection/server/collectors/config_usage/register_config_usage_collector.ts
Show resolved
Hide resolved
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.
Overall looking great.
A few remarks and questions
"exclude": [] | ||
"exclude": [ | ||
"src/plugins/kibana_usage_collection/server/collectors/config_usage/register_config_usage_collector.ts" | ||
] |
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.
Why was that necessary?
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've opened a follow up issue here: #97599.
TLDR;
Explicitly typing every config in the schema is not practical. We'll be experimenting with flattened_type
ES type and runtime fields to query this collector. Both are not yet supported by the collection schema
types.
If we had to explicitly specify every kibana config in the schema we'd need to improve our telemetry tooling to automatically do this for devs. Although flattened_type
seems promising enough for this use case.
public getExposedPluginConfigsToUsage() { | ||
return this.pluginConfigUsageDescriptors; | ||
} |
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.
Why can't this be added to the internal setup
contract instead of creating a new method?
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 function is called in the start
function before plugins.start
is called. I can expose it from setup but then i'd have to pass it from setup to start via this
inside server
.
if (typeof isSafe === 'boolean') { | ||
return { explicitlyMarked: true, isSafe }; | ||
} |
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'm wondering (if I understood the model correctly): with TS support, can this condition actually be false?
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.
Correct TS should not allow this case to happen since we only allow boolean
leafs. We cannot rely on TS type safety alone since devs can always // @ts-ignore
. This would also guard from unexpected changes to the type by mistake in the future (along with tests).
// @ts-expect-error | ||
service.getMarkedAsSafe = mockGetMarkedAsSafe; |
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.
Optional: I think CoreUsageDataService.getMarkedAsSafe
can be made static, right? If so, we could extract it to allow proper module mocking.
src/core/server/core_usage_data/core_usage_data_service.test.ts
Outdated
Show resolved
Hide resolved
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.
LGTM! Thank you for this, @Bamieh!
merge( | ||
get(fullSchema, 'properties.stack_stats.properties.kibana.properties.plugins'), | ||
telemetrySchema.plugins | ||
); |
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.
🧡
💚 Build SucceededMetrics [docs]History
To update your PR or re-run it, just comment with: |
Co-authored-by: Kibana Machine <[email protected]>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Ahmad Bamieh <[email protected]>
Config Usage Collector
The config usage collector reports non-default kibana configs.
All non-default configs except booleans and numbers will be reported as
[redacted]
unless otherwise specified viaconfig.exposeToUsage
in the plugin config descriptor.In the above example setting
uiCounters: true
in theexposeToUsage
property marks all configs under the pathuiCounters
as safe. The collector will send the actual non-default config value when setting an exact config or its parent path totrue
.Settings the config path or its parent path to
false
will explicitly mark this config as unsafe. The collector will send[redacted]
for non-default configs when setting an exact config or its parent path tofalse
.Example output of the collector