Skip to content

Printing process warning's via the appropriate loggers #8746

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

Merged
merged 1 commit into from
Oct 19, 2016

Conversation

kobelb
Copy link
Contributor

@kobelb kobelb commented Oct 19, 2016

Node v6.6.0 by default writes warnings to STDERR per https://nodejs.org/dist/latest-v6.x/docs/api/process.html#process_event_warning

This modification would by default suppress these warnings from being written to STDERR by using the --no-warnings flag, and then we'd selectively write these errors using the proper logging method.

Addresses: #8746

@@ -21,4 +21,4 @@ if [ ! -x "$NODE" ]; then
exit 1
fi

exec "${NODE}" $NODE_OPTIONS "${DIR}/src/cli" ${@}
Copy link
Contributor Author

@kobelb kobelb Oct 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't been able to find a way to selectively add this flag, besides potentially determining if the --dev flag is provided.

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 adding the flag all the time is fine, since we are forwarding all the messages via the server logger.

@@ -21,4 +21,4 @@ if [ ! -x "$NODE" ]; then
exit 1
fi

exec "${NODE}" $NODE_OPTIONS "${DIR}/src/cli_plugin" ${@}
exec "${NODE}" $NODE_OPTIONS --no-warnings "${DIR}/src/cli_plugin" ${@}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The kibana-plugin is currently not displaying the warnings at all, currently investigating the best way to determine if "we're in production"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The cli plugin command has it's own logger with it's own opinions about when messages should and shouldn't be logged (controlled with --silent and --quiet) https://github.com/elastic/kibana/blob/master/src/cli_plugin/lib/logger.js

We should probably wire this up in that cli

@@ -0,0 +1,9 @@
export default function (kbnServer, server, config) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming that we only have one instance of the kbnServer per 'process' (including when we're clustering) so we won't be subscribing to this event twice and possibly getting duplicate warnings.

Copy link
Contributor

@spalger spalger Oct 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming that we only have one instance of the kbnServer per 'process' (including when we're clustering) so we won't be subscribing to this event twice and possibly getting duplicate warnings.

Not necessarily, but I don't think there is a better option right now.

@kobelb
Copy link
Contributor Author

kobelb commented Oct 19, 2016

@spalger @tylersmalley should we consider switching the approach to the one that tyler has here: 0865c55

The main benefit that I see from Tyler's approach, is that warnings that are emitted before we hit the place where I'm registering the process.on('warning', ...) will be written to STDERR; with the trade-off that when they are written, they won't be in our standard 'format'.

@spalger spalger self-assigned this Oct 19, 2016
@@ -0,0 +1,9 @@
export default function (kbnServer, server, config) {
Copy link
Contributor

@spalger spalger Oct 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming that we only have one instance of the kbnServer per 'process' (including when we're clustering) so we won't be subscribing to this event twice and possibly getting duplicate warnings.

Not necessarily, but I don't think there is a better option right now.

}

process.on('warning', (warning) => {
server.log(['warning'], warning);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add a 'process' tag so that these warnings can be identified specifically

@@ -21,4 +21,4 @@ if [ ! -x "$NODE" ]; then
exit 1
fi

exec "${NODE}" $NODE_OPTIONS "${DIR}/src/cli_plugin" ${@}
exec "${NODE}" $NODE_OPTIONS --no-warnings "${DIR}/src/cli_plugin" ${@}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The cli plugin command has it's own logger with it's own opinions about when messages should and shouldn't be logged (controlled with --silent and --quiet) https://github.com/elastic/kibana/blob/master/src/cli_plugin/lib/logger.js

We should probably wire this up in that cli

@@ -21,4 +21,4 @@ if [ ! -x "$NODE" ]; then
exit 1
fi

exec "${NODE}" $NODE_OPTIONS "${DIR}/src/cli" ${@}
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 adding the flag all the time is fine, since we are forwarding all the messages via the server logger.

@kobelb kobelb changed the title Only displaying warnings for the kbn_server in dev using server.log Printing process warning's via the appropriate loggers Oct 19, 2016
@tylersmalley tylersmalley self-assigned this Oct 19, 2016
Copy link
Contributor

@tylersmalley tylersmalley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

As an added benefit we actually get the stack trace, abiet not very helpful in this case. screenshot 2016-10-19 11 26 18

@kobelb kobelb merged commit 3e3332f into elastic:master Oct 19, 2016
elastic-jasper added a commit that referenced this pull request Oct 19, 2016
---------

**Commit 1:**
Printing process warning's via the appropriate logger

* Original sha: 96ef75b
* Authored by = <[email protected]> on 2016-10-19T10:41:45Z
elastic-jasper added a commit that referenced this pull request Oct 19, 2016
---------

**Commit 1:**
Printing process warning's via the appropriate logger

* Original sha: 96ef75b
* Authored by = <[email protected]> on 2016-10-19T10:41:45Z
@kobelb kobelb deleted the nodejs-warnings branch October 19, 2016 18:58
kobelb added a commit that referenced this pull request Oct 19, 2016
kobelb added a commit that referenced this pull request Oct 19, 2016
@jbudz
Copy link
Member

jbudz commented Nov 28, 2016

Does this need to be backported to 4.7?

@kobelb
Copy link
Contributor Author

kobelb commented Nov 28, 2016

@jbudz if we're upgrading Node to 6.x, yup.

@epixa epixa added v5.1.1 and removed v5.1.0 labels Dec 8, 2016
epixa added a commit to epixa/kibana that referenced this pull request Dec 22, 2016
Node 6.6+ writes warnings to stderr rather than stdout, but we want
those warnings to piped through as warnings in our Kibana logger
instead.
@epixa epixa added the v4.6.4 label Dec 22, 2016
epixa added a commit that referenced this pull request Dec 22, 2016
Node 6.6+ writes warnings to stderr rather than stdout, but we want
those warnings to piped through as warnings in our Kibana logger
instead.
airow pushed a commit to airow/kibana that referenced this pull request Feb 16, 2017
---------

**Commit 1:**
Printing process warning's via the appropriate logger

* Original sha: f464a80786985c596a8f1155164a044c5f0fa39f [formerly 96ef75b]
* Authored by = <[email protected]> on 2016-10-19T10:41:45Z


Former-commit-id: 32cbd7c
airow pushed a commit to airow/kibana that referenced this pull request Feb 16, 2017
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.

5 participants