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

Add log option to all outputs #2254

Merged
merged 1 commit into from
Dec 23, 2022
Merged

Add log option to all outputs #2254

merged 1 commit into from
Dec 23, 2022

Conversation

zuckschwerdt
Copy link
Collaborator

@zuckschwerdt zuckschwerdt commented Nov 29, 2022

Logging used to be simple messages on stderr. Limitations:

  • Always visible on the console (KV output), not available at other outputs (JSON, Syslog, HTTP)
  • Not really inline with events (events: stdout, log: stderr)
  • No severity visible (by color or common markers)

Logging now changed to be messages along the same path as events:

  • Selectable for any output
  • Inline with events
  • Severity by color (or level markers)

Usage changes:

  • If you don't select any outputs then logging will go to KV output (equivalent to -F kv, i.e. -F kv,v=8)
  • If you select the KV output then logging will be shown, suppress with -F kv,v=0)
  • If you don't select the KV output then no logging will be shown, add it with -F log)
  • If you want logging back to stderr and suppressed in KV use -F log -F kv,v=0

Implementation

Now that refactoring from fprintf()s in decoders to decoder_log*() calls is done this will finally allow all logging to selectively (verbosity levels) go to outputs (KV, JSON, CSV, MQTT, HTTP, …).

One would raise the verbosity globally (-v) or per decoder (-R 99,v) and configure outputs to display those messages (e.g. -F json,v).

Tasks

  • Outputs need to parse the level option
  • Global prints ("noise level") need to be converted to log
  • KV ouput should prettify the logs
  • Looks like there is an overflow somewhere? (6e1f120)

@zuckschwerdt
Copy link
Collaborator Author

I'm pondering what label coloring would appeal to most? (dim or intense bg? regular or bold fg?)

intense-norm
intense-bold

dim-norm
dim-bold

The "intense-bold" variant is what we would use by default right now, the "dim" variants would be slightly more compatible with Windows 8.1 (only Windows 10+ offers bright bg).

The labels would show the logging "source" as seen here:

log-src

@zuckschwerdt
Copy link
Collaborator Author

Personally, I prefer the crisper looking non-bold text (also it's less of a distraction).
And the dim backgrounds might be a problem as many custom color schemes "wash out" those colors.
For me it then would be the first example above.

@zuckschwerdt
Copy link
Collaborator Author

Ok, let's use variant 1 for now (intense background, crisp non-bold text).

I'll merge this now. There is still need to fine-tune some log levels and messages, feel free to leave some feedback!

@zuckschwerdt zuckschwerdt merged commit 7d51297 into master Dec 23, 2022
@zuckschwerdt zuckschwerdt deleted the feat-logtooutputs branch December 23, 2022 12:18
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 this pull request may close these issues.

None yet

1 participant