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

[Feature Request] Adding the .quiet() property to all node types and making it more configurable #1561

Closed
oplehto opened this issue Sep 14, 2017 · 4 comments

Comments

@oplehto
Copy link

oplehto commented Sep 14, 2017

The eval node has a .quiet() property which is very useful for supressing errors and warnings that we don't necessarily care about. It would be great if more, or even all, node types would offer this functionality.

Ideally I'd like even with more control over which log level messages get supressed and possibly a lambda expression to supress specific errors. For example, we might want DerivativeNode to supress just the "0 time difference" errors but nothing else.

@oplehto oplehto changed the title [ [Feature Request] Adding the .quiet() property to all node types and making it more configurable Sep 14, 2017
@rbetts
Copy link

rbetts commented Dec 7, 2017

@nathanielc Can we scope this for effort / feasibility?

@nathanielc
Copy link
Contributor

Adding a .quiet() to every node is reasonable, probably a few days of work.

Allowing the suppression of specific errors using a lambda expression is a non-starter. Lambda expressions are tailored to processing the point data, and while it might be possible to re-purpose them, I think it would be a confusing user experience. Another way to solve this would be to have the .quite() accept a list of errors to suppress. Since 1.4 all errors have a static string message, so it would be easy to identify them. This is probably only a marginal addition to the work of adding .quiet() to all nodes.

@oplehto
Copy link
Author

oplehto commented Dec 8, 2017

Yeah. Having a .quiet() propety and some parameter to adjust the verbosity (like a list of errors) would be sufficient. Fair point about the lambda expressions.

@russorat
Copy link
Contributor

russorat commented Mar 5, 2018

A trivial example: We process a measurement where a certain field is not always defined. We want to supress the error that results in a node failing to process that field if it is undefined. We could start adding default nodes but that can become really convoluted. Just having kapacitor drop the problematic line to the floor quietly would be the preferred option.
I've hit situations several times where I've found myself trying doing extra work with a script just to supress the error messages while the script itself is already working properly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants