-
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
[Monitoring/Reporting Stats] Move hardcoded Reporting stats type collection out of monitoring plugin #18894
[Monitoring/Reporting Stats] Move hardcoded Reporting stats type collection out of monitoring plugin #18894
Conversation
@@ -21,7 +21,8 @@ export async function initKibanaMonitoring(kbnServer, server) { | |||
plugins: [monitoringBulk] | |||
}); | |||
|
|||
startCollector(kbnServer, server, client); | |||
const collector = startCollector(kbnServer, server, client); | |||
server.expose('typeCollector', collector); // NOTE: consumers need to wait on Monitoring plugin status go green, and that this object was successfully exposed |
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 note is relevant to line 163 in x-pack/plugins/reporting/index.js
💔 Build Failed |
💔 Build Failed |
💚 Build Succeeded |
I've removed review, added WIP label. Reporting is not registering its collector in this code yet. It looks like the monitoring plugin needs to wait until the registration method is exposed before the plugin can go green. Since exposing the collector object that has the registration method becomes a first-class concern of Monitoring, I want to make Monitoring's green status held up by that, to resolve the race condition. |
Added depends on #18939 |
typeCollector.register
method for external plugins to register their stats collector
💔 Build Failed |
c8b0454
to
21f95d5
Compare
💚 Build Succeeded |
6f4906a
to
bba238c
Compare
💚 Build Succeeded |
@@ -146,7 +147,8 @@ export const reporting = (kibana) => { | |||
validateConfig(config, message => server.log(['reporting', 'warning'], message)); | |||
logConfiguration(config, message => server.log(['reporting', 'debug'], message)); | |||
|
|||
const xpackMainPlugin = server.plugins.xpack_main; | |||
const { xpack_main: xpackMainPlugin, monitoring: monitoringPlugin } = server.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.
This needs testing on what happens when Monitoring is disabled but Reporting is enabled. cc @pickypg
86f872d
to
11e0f44
Compare
💔 Build Failed |
11e0f44
to
6e6e6ae
Compare
@@ -1,44 +0,0 @@ | |||
/* |
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 test wasn't really doing very much, and hasn't been replaced with a similar mocha test in the Reporting plugin.
@@ -1,18 +0,0 @@ | |||
/* |
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 has been moved to Reporting and replaces reporting/server/usage/get_usage.js
💚 Build Succeeded |
} from '../../../common/constants'; | ||
import { KIBANA_REPORTING_TYPE } from '../../../../reporting/common/constants'; |
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.
Is there a step two planned to get rid of this and the abstraction leak below? Or maybe you can get rid of it now?
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 module that combines collection types together into a bulk payload unfortunately does have to stay, but just for the short term. It's to support the behavior of Kibana Monitoring that sends kibana stats to the monitoring/_bulk
endpoint in ES. Unfortunately, this module needs to have a lot of awareness of the usage collectors because in the current schema, usage is a field of kibana_stats
.
We will take the responsibility of sending stats to ES out of Kibana and have Metricbeats used for monitoring all the systems. Once we do that, we can remove get_collector_types_combiner
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.
@stacey-gammon https://github.com/elastic/kibana/blob/6.x/x-pack/plugins/xpack_main/server/routes/api/v1/kibana_stats.js has the same story as this module
I merged in master to get #18986 into this branch. CI is running right now and I will also run some manual tests before merging. |
💚 Build Succeeded |
…ection out of monitoring plugin (elastic#18894) * [Monitoring/Telemetry collection] use `typeCollector.registerType` in Reporting * a few cleanup changes
Closes #12504
plugins/reporting/index.js
instead ofplugins/monitoring/server/kibana_monitoring/collectors/get_reporting_collector.js
KIBANA_REPORTING_TYPE
moved from the Monitoring plugin to the Reporting pluginDepends on: