-
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] Add a yellow status phase in plugin init #18939
[Monitoring] Add a yellow status phase in plugin init #18939
Conversation
💚 Build Succeeded |
f50d596
to
f1982e6
Compare
f1982e6
to
53ddfa0
Compare
💔 Build Failed |
jenkins test this |
💚 Build Succeeded |
* @param monitoringPlugin {Object} Monitoring UI plugin | ||
* @param server {Object} HapiJS server instance | ||
*/ | ||
export const init = (monitoringPlugin, server) => { | ||
monitoringPlugin.status.yellow('Initializing'); |
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.
Starting with a yellow status and changing to green after typeCollector
is exposed on the server allows plugins to wait for Monitoring to be ready before trying to consume the typeCollector
and add their own collection methods.
@pickypg @stacey-gammon @kobelb would you mind taking a look at this? It's a prep change needed to begin working on #12504 |
💚 Build Succeeded |
pulled out the |
💚 Build Succeeded |
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.
My comments are more thoughts than issues.
*/ | ||
export async function initKibanaMonitoring(kbnServer, server) { | ||
export function initKibanaMonitoring(kbnServer, server) { |
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 think we should change this function's name now that it returns something. Perhaps createKibanaCollector
?
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 think could also do @return {TypeCollector}
? If I'm following the code correctly, that is what is returned.
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.
Sure, but I'd like to handle this in the next PR, which depends on this one: #18987
It's a small one with strictly renaming changes
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.
} | ||
|
||
// Send Kibana usage / server ops to the monitoring bulk api | ||
if (config.get('xpack.monitoring.kibana.collection.enabled')) { |
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.
As a side note, outside code that registers its own collectors will need to effectively do this too:
if (config.get('xpack.monitoring.enabled') && config.get('xpack.monitoring.kibana.collection.enabled')) {
// or
if (server.plugins.monitoring && server.plugins.monitoring.typeCollector) {
for any usage of this server object.
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 started this work in the 2nd PR to come after this one: #18894 It might be awhile before that gets filed, but I'll be sure to test what happens when Monitoring is disabled but Reporting is enabled.
* - init {Function} (optional) | ||
* - fetch {Function} | ||
* - cleanup {Function} (optional) | ||
* @param {String} type.type |
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 wonder if we should make this an object parameter that makes these fields clearer? That or make type
a class that users are expected to implement to take advantage of?
register({ type, fetch, init, cleanup }) {
I would personally vote for the class because it makes it easier to require specific methods with the less opportunity for misunderstanding their purpose.
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 like the class implementation approach too, it's what I've been following for my pluggable things, like embeddables and pluggable panel actions. Eventually when we move to typescript we'll be able to use their interfaces. But this is fine too, if you want to leave as is.
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 had the same thought :D , but planned to work that out in a later PR: 60ba195
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.
It's in a PR now: #19098
*/ | ||
register(collectorOptions) { | ||
this._collectors.push(collectorOptions); | ||
register(type) { |
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.
One downside to this approach is that a plugin that registers late could technically miss [at least] the first collection cycle.
I don't have a better approach in mind, but it's something to keep in mind as we add more.
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 with minor comments.
*/ | ||
export async function initKibanaMonitoring(kbnServer, server) { | ||
export function initKibanaMonitoring(kbnServer, server) { |
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 think could also do @return {TypeCollector}
? If I'm following the code correctly, that is what is returned.
@@ -53,4 +53,6 @@ export function startCollector(kbnServer, server, client, _sendBulkPayload = sen | |||
server.plugins.elasticsearch.status.on('red', () => { | |||
collector.cleanup(); | |||
}); | |||
|
|||
return collector; |
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.
add @return {TypeCollector}
to jsdoc?
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.
TypeCollector
will get renamed to CollectorSet
in my next PR, so I'll handle it there.
TypeCollector
seemed like a bad name because it is a thing that keeps a set of collectors, not a collector itself.
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.
* - init {Function} (optional) | ||
* - fetch {Function} | ||
* - cleanup {Function} (optional) | ||
* @param {String} type.type |
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 like the class implementation approach too, it's what I've been following for my pluggable things, like embeddables and pluggable panel actions. Eventually when we move to typescript we'll be able to use their interfaces. But this is fine too, if you want to leave as is.
* [Monitoring] Add a yellow status phase in the startup lifecycle * comments * more comments * more comment * undo register => registerType function name change
Pulled out from #18894
This PR adds a yellow status phase to the Monitoring app plugin startup, and pulls a few other changes out of #18894 to show the intent of this preparatory change.
registerType
method to incorporate collectors, is returned fromstart_collector.js
and put in scope in the Monitoringinit
method.registerType
was justregister
before, but renamed because it was confusing that a collector object registers "collectors".registerType
is called with a type object that defines how the collector can fetch data for it