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

Enable error logging #2003

Closed
yongxiangng opened this issue May 15, 2023 · 3 comments · Fixed by #2004
Closed

Enable error logging #2003

yongxiangng opened this issue May 15, 2023 · 3 comments · Fixed by #2004

Comments

@yongxiangng
Copy link
Contributor

yongxiangng commented May 15, 2023

Related issue #506

Feature Request

To enable logging of errors only. Currently, setting SIMDJSON_VERBOSE_LOGGING will log errors and other info. It would be nice to differentiate the logs into different levels and configure the log levels to be logged via an environment variable / compile option.

Is this a feature that would be desired? Should we implement this with an environment variable or compile option?

Other notes

The motivation behind this is because I'd like to know the key passed in when we receive NO_SUCH_FIELD error code is returned. Enabling verbose logging would be too expensive, because I only need the logs when an error occurs.

Possible Implementation

I am willing to help and make the changes.

My proposal is to use a environment variable SIMDJSON_LOG_LEVEL, which defaults to INFO. To log error messages only, we compile with SIMDJSON_VERBOSE_LOGGING and set the env variable SIMDJSON_LOG_LEVEL to ERROR.

  1. Add enum class log_level in the logger with 2 levels, INFO, ERROR
  2. Add method should_log(log_level) in the logger class. It will fetch the env variable on first invocation.
  3. Modify log_line to take in log_level as an additional param (should I default this to INFO?)
  4. inside log_line do something like
if (LOG_ENABLED && simdjson_unlikely(should_log(log_level)))
{
  // logging impl ...
}
@lemire
Copy link
Member

lemire commented May 15, 2023

The PR, at a glance, looks reasonable.

@lemire lemire reopened this Jul 7, 2023
@lemire
Copy link
Member

lemire commented Jul 7, 2023

I am going to have to remove the PR. It can have a large negative performance effect.

@lemire
Copy link
Member

lemire commented Aug 2, 2023

Fixed by #2030

@lemire lemire closed this as completed Aug 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants