Skip to content
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

Merged
merged 7 commits into from
May 15, 2018

Conversation

tsullivan
Copy link
Member

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.

  1. The collector object, which has a registerType method to incorporate collectors, is returned from start_collector.js and put in scope in the Monitoring init method.
    • registerType was just register before, but renamed because it was confusing that a collector object registers "collectors".
    • Should be more clear now that there is 1 collector and it gets "types" registered into it.
    • registerType is called with a type object that defines how the collector can fetch data for it
  2. Monitoring status starts as yellow and goes to green after the collector object is exposed as a server method.
  3. Some comments have been added to the areas in Monitoring where we're hardcoding for Reporting (seen as an external plugin) that will get cleaned up in 18894

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@tsullivan tsullivan removed the request for review from Gunnerva May 9, 2018 19:31
@tsullivan tsullivan force-pushed the monitoring/add-yellow-status branch from f50d596 to f1982e6 Compare May 9, 2018 19:43
@tsullivan tsullivan requested a review from pickypg May 9, 2018 20:00
@tsullivan tsullivan force-pushed the monitoring/add-yellow-status branch from f1982e6 to 53ddfa0 Compare May 9, 2018 20:05
@elasticmachine
Copy link
Contributor

💔 Build Failed

@tsullivan
Copy link
Member Author

jenkins test this

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@tsullivan tsullivan requested review from kobelb and stacey-gammon May 10, 2018 16:19
* @param monitoringPlugin {Object} Monitoring UI plugin
* @param server {Object} HapiJS server instance
*/
export const init = (monitoringPlugin, server) => {
monitoringPlugin.status.yellow('Initializing');
Copy link
Member Author

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.

@tsullivan
Copy link
Member Author

@pickypg @stacey-gammon @kobelb would you mind taking a look at this? It's a prep change needed to begin working on #12504

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@tsullivan
Copy link
Member Author

tsullivan commented May 10, 2018

pulled out the register => registerType function name changes. Issues with semantics will be addressed in a later PR (#18987, which depends on this one)

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@pickypg pickypg left a 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) {
Copy link
Member

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?

Copy link
Contributor

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.

Copy link
Member Author

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

Copy link
Member Author

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')) {
Copy link
Member

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.

Copy link
Member Author

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
Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Member Author

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

Copy link
Member Author

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) {
Copy link
Member

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.

Copy link
Contributor

@stacey-gammon stacey-gammon left a 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) {
Copy link
Contributor

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;
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Member Author

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
Copy link
Contributor

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.

@tsullivan tsullivan merged commit 9e0a6e2 into elastic:master May 15, 2018
@tsullivan tsullivan deleted the monitoring/add-yellow-status branch May 15, 2018 16:32
tsullivan added a commit to tsullivan/kibana that referenced this pull request May 15, 2018
* [Monitoring] Add a yellow status phase in the startup lifecycle

* comments

* more comments

* more comment

* undo register => registerType function name change
tsullivan added a commit that referenced this pull request May 15, 2018
* [Monitoring] Add a yellow status phase in the startup lifecycle

* comments

* more comments

* more comment

* undo register => registerType function name change
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants