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.

Sign up for GitHub

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

Jump to bottom

Disable stderr logging when file is provided #83

Closed
aloknerurkar opened this issue May 12, 2020 · 4 comments
Closed

Disable stderr logging when file is provided #83

aloknerurkar opened this issue May 12, 2020 · 4 comments
Labels
need/triage Needs initial labeling and prioritization

Comments

@aloknerurkar
Copy link
Contributor

The setup by default adds "stderr" to the output paths. I don't see any way we can change this. I don't see zap.Logger also providing a way to change it later.

We have a CLI application, so we would prefer not to show the logs on the console when we configure a log file. Currently, we do a Dup of the stderr to a file to get around this. But Windows doesn't support this that well.

Is there a way to disable the stderr logs?
@aloknerurkar aloknerurkar added the need/triage Needs initial labeling and prioritization label May 12, 2020
@welcome
Copy link

welcome bot commented May 12, 2020

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

  • "Priority" labels will show how urgent this is for the team.
  • "Status" labels will show if this is ready to be worked on, blocked, or in progress.
  • "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

@Stebalien
Copy link
Member

Stebalien commented May 12, 2020 via email

@aloknerurkar
Copy link
Contributor Author

Okay sure will send a patch.

"Really, we should make it possible to pragmatically re-configure the log target but that's a bigger change."
=> If you already have something in mind let me know. I can work on that as well. Least I could do after exploiting this library so much.

iand added a commit to iand/go-log that referenced this issue May 19, 2020
@iand
Add log config and populate from environment
e03f270 
This change adds a Config struct to enable easier reconfiguration
of the logger. The default config is still read from the
environment in init() but a client of the package can now call
SetupLogging again with a custom config to adjust logging after
initialization.

Allows logging to stderr to be disabled via configuration.

Fixes ipfs#83
@iand iand mentioned this issue May 19, 2020
Closed
iand added a commit to iand/go-log that referenced this issue May 20, 2020
@iand
Add log config and populate from environment
7365850 
This change adds a Config struct to enable easier reconfiguration
of the logger. The default config is still read from the
environment in init() but a client of the package can now call
SetupLogging again with a custom config to adjust logging after
initialization.

Allows logging to stderr to be disabled via configuration.

Fixes ipfs#83
iand added a commit to iand/go-log that referenced this issue May 20, 2020
@iand
Add log config and populate from environment
a3a4045 
This change adds a Config struct to enable easier reconfiguration
of the logger. The default config is still read from the
environment in init() but a client of the package can now call
SetupLogging again with a custom config to adjust logging after
initialization.

Allows logging to stderr to be disabled via configuration.

Fixes ipfs#83
iand added a commit to iand/go-log that referenced this issue May 20, 2020
@iand
Add log config and populate from environment
1d9af96 
This change adds a Config struct to enable easier reconfiguration
of the logger. The default config is still read from the
environment in init() but a client of the package can now call
SetupLogging again with a custom config to adjust logging after
initialization.

Allows logging to stderr to be disabled via configuration.

Fixes ipfs#83
@aloknerurkar aloknerurkar mentioned this issue May 22, 2020
Merged
iand added a commit to iand/go-log that referenced this issue May 24, 2020
@iand
Use multiple cores in logger
359bf83 
Another take on ipfs#66

This change introduces a multicore implementation that allows
additonal zap cores to be added at runtime. Each core can be
configured with distinct encoders and writers which makes
it possible to tail the logs in a program using a different
log format (e.g. program may log in json but interactive
tailing can be in plaintext). This comes at the cost of an
additional mutex that must be taken on each write since the
destination of the write is mutable.

It reworks (and simplifies) the pipe reader implementation
added in ipfs#87 and adds a
new function NewPipeReaderFormat which creates a pipe reader
using a different output format.

This change also allows us to reconfigure logging after it has been
initialised by swapping out the initial zap core with a
newly configured one. This solves the problem that I attempted
in ipfs#88

Adds a Config struct to enable easier reconfiguration
of the logger. The default config is still read from the
environment in init() but a client of the package can now call
SetupLogging again with a custom config to adjust logging after
initialization.

Note that the fix for ipfs#83
is slightly different. If a file is specified using GOLOG_FILE
then logging to stderr will be disabled but logging can be
configured to write to both file and stderr by calling SetupLogging
with the appropriate configuration.
@iand iand mentioned this issue May 24, 2020
Merged
iand added a commit to iand/go-log that referenced this issue May 25, 2020
@iand
Use multiple cores in logger
357fbe4 
Another take on ipfs#66

This change introduces a multicore implementation that allows
additonal zap cores to be added at runtime. Each core can be
configured with distinct encoders and writers which makes
it possible to tail the logs in a program using a different
log format (e.g. program may log in json but interactive
tailing can be in plaintext). This comes at the cost of an
additional mutex that must be taken on each write since the
destination of the write is mutable.

It reworks (and simplifies) the pipe reader implementation
added in ipfs#87 and adds a
new function NewPipeReaderFormat which creates a pipe reader
using a different output format.

This change also allows us to reconfigure logging after it has been
initialised by swapping out the initial zap core with a
newly configured one. This solves the problem that I attempted
in ipfs#88

Adds a Config struct to enable easier reconfiguration
of the logger. The default config is still read from the
environment in init() but a client of the package can now call
SetupLogging again with a custom config to adjust logging after
initialization.

Note that the fix for ipfs#83
is slightly different. If a file is specified using GOLOG_FILE
then logging to stderr will be disabled but logging can be
configured to write to both file and stderr by calling SetupLogging
with the appropriate configuration.
@lanzafame
Copy link
Contributor

@Stebalien This change has broken the ability to have logs go to both a file and to journald. journald requires stderr output, whilst tooling such as mtail for log metric collection require a file to parse.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
need/triage Needs initial labeling and prioritization
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add log config and populate from environment iand/go-log
3 participants
@Stebalien @aloknerurkar @lanzafame