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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change loglevel of docker container & stdout? #310

Open
emilebosch opened this issue Aug 9, 2022 · 7 comments
Open

Change loglevel of docker container & stdout? #310

emilebosch opened this issue Aug 9, 2022 · 7 comments

Comments

@emilebosch
Copy link

Hi all 馃憢

I'm using pganalyze in our prod cluster and I was wondering whether there is a way to limit the logs only to output error or warn. Additionally it also seems like its not outputting on the right stdout for I (info)

We're using datadog as our monitoring system and it captures all the I's as Error. Usually and indication that logs are not send to the right fd.

@emilebosch
Copy link
Author

emilebosch commented Aug 9, 2022

Here a sample of how it looks. Please note that even I's are captured as errors.

image

@lfittl
Copy link
Member

lfittl commented Aug 10, 2022

@emilebosch Interesting point - it looks like you are correct and we emit information to stderr for the log output.

I don't see a big downside to adjusting this, but I wonder what the expected behavior would be for warnings - I'd assume you'd only want actual errors sent to stderr?

Also out of curiosity, what do you run for container orchestration / how do the logs flow from the container to Datadog?

@emilebosch
Copy link
Author

@lfittl Thanks for the response. We're using the Datadog helm chart that comes with datadog that takes care of log shipping. Since we pay per log line just as any other tool (i.e. splunk) its nice if there is an option to only log essential messages.

I guess warn goes to stdout? Not 100% sure on this but here is some reference/guidance ipfs/go-log#60

Thank you much for considering this.

@lfittl
Copy link
Member

lfittl commented Aug 10, 2022

@emilebosch Thanks for that, appreciate the reference!

It does appear there are some alternate opinions referenced in that issue and others linked from it, but especially for a background process I can see how it could make sense to split it.

The slightly easier solution for now would actually be to just add a --quiet / -q flag, that silences all log output except for errors. Would that also solve your use case? (since it sounds like you're mostly concerned on the cost aspect of the repeated messages)

@emilebosch
Copy link
Author

emilebosch commented Aug 10, 2022

@lfittl Maybe -q would work for now. Would still be nice to have things in separate streams since various software/observability tools automatically understand then the difference between errors/info.

Another thing you might like to look into would be logfmt kind of logging. This allows you to also send out some metrics at times that can be useful for graphing things out at times (number of captured snapshots etc) or something that a devops/sre engineer can act upon to detect that something's off with the collector.

@lfittl
Copy link
Member

lfittl commented Aug 13, 2022

@emilebosch Great! - added the -q / --quiet flag in #312 and released as v0.45.1.

@emilebosch
Copy link
Author

Fantastic thank you Lukas!

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

No branches or pull requests

2 participants