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

Remove "/health" from logging? #428

Closed
rucksman opened this issue Aug 21, 2021 · 14 comments · Fixed by #566
Closed

Remove "/health" from logging? #428

rucksman opened this issue Aug 21, 2021 · 14 comments · Fixed by #566
Labels
question Further information is requested

Comments

@rucksman
Copy link

The log file I created with entrypoint: /bin/bash -c '/app/gotify-app | tee /app/data/gotify.log' in my docker-compose.yml is pretty quick filling up with entries like [GIN] 2021/08/21 - 19:02:50 | 200 | 440.732µs | 127.0.0.1 | GET "/health". Is there a way to prevent these kind of entries in the log file?

@rucksman rucksman added the question Further information is requested label Aug 21, 2021
@jmattheis
Copy link
Member

You can use grep

docker run --rm -p 12345:80 -v $PWD/gotify.log:/app/gotify.log --entrypoint '' gotify/server:2.0.22 /bin/bash -c '/app/gotify-app | grep --line-buffered -v /health | tee /app/gotify.log'

this suppresses all log entries that contain /health.

@rucksman
Copy link
Author

That was quick! Thanks a lot!

@ngosang
Copy link

ngosang commented Oct 2, 2021

@jmattheis I'm using this fix too but I think it's not right. Since the healthcheck is enabled in the Docker image you should exclude these traces to avoid spam. Out-the-box install should include this fix.

@jmattheis
Copy link
Member

You're probably right. I'll be open to accept a PR for this.

@jmattheis jmattheis reopened this Oct 3, 2021
@GAS85
Copy link

GAS85 commented Oct 13, 2021

I would say you have to grep out exact line like '127.0.0.1 | GET "/health"', because if you use logs to monitor your Server, you have to know if somebody else is calling your health endpoint besides localhost.

@ryester19
Copy link

Grepping a log file feels like a hacky way to solve this, especially when all Docker containers are affected by this in its default configuration

Is there any worth at all in logging requests coming from localhost? If not, I think I have a solution using what limited development knowledge I have

@sfkpmr
Copy link

sfkpmr commented May 21, 2022

What is the purpose of the health check, is it just a self-check? What happens if the check fails?

@jmattheis
Copy link
Member

Then docker will mark the container as unhealthy.

@ilude
Copy link

ilude commented Jul 27, 2022

I'm sorry golang is not my normal day to day thing but I think something like this should work in place of:

g.Use(gin.LoggerWithFormatter(logFormatter), gin.Recovery(), error.Handler(), location.Default())

skip_log_env, skip_log_env_present := os.LookupEnv("GOTIFY_DISABLE_LOG_PATHS")
if skip_log_env_present {
	skip_log_paths := strings.Split(skip_log_env, ",")
}
else {
	skip_log_paths := []
}

g.Use(gin.LoggerWithConfig(gin.LoggerConfig{SkipPaths: skip_log_paths, LogFormatter: logFormatter}, gin.Recovery(), error.Handler(), location.Default())

then you can pass in an env like so

GOTIFY_DISABLE_LOG_PATHS=/health

Reference: https://stackoverflow.com/a/71442218

@bonelifer
Copy link

@GAS85 so like this for compose?

  entrypoint: sh -c "/app/gotify-app | grep --line-buffered -v '127.0.0.1 | GET      \"/health\"' | tee /app/data/gotify.log"

@GAS85
Copy link

GAS85 commented Aug 10, 2022

Seems so, logs format is:

[GIN] 2022/08/10 - 09:13:09 | 200 |       47.17µs |       127.0.0.1 | GET      "/health"
[GIN] 2022/08/10 - 09:13:28 | 200 |      25.672µs |     10.20.30.40 | GET      "/health"

and your grep line should do the job.

@cyberius0
Copy link

cyberius0 commented Jan 10, 2023

Hello,
I also have the log full of 'GET "/health"' entries.

Is the above command still up to date?

I don't understand what it does, but "server:2.0.22" is not the current version anymore.

[bonelifer] posted a variant of it, so it this the right way to do it currently?

sudo docker run --rm -p 12345:80 -v $PWD/gotify.log:/app/gotify.log --entrypoint '' gotify/server:2.0.22 /bin/bash -c '/app/gotify-app | grep --line-buffered -v '127.0.0.1 | GET \"/health\"' | tee /app/gotify.log'

Running this command seems to produce errors

-bash: GET: command not found
Unable to find image 'gotify/server:2.0.22' locally
2.0.22: Pulling from gotify/server
79d3b412d726: Pulling fs layer
68f7f2742242: Pulling fs layer
e3fd2c9f2c77: Pulling fs layer
14abfa4935c1: Pulling fs layer
14abfa4935c1: Waiting
68f7f2742242: Verifying Checksum
68f7f2742242: Download complete
79d3b412d726: Verifying Checksum
79d3b412d726: Download complete
e3fd2c9f2c77: Verifying Checksum
e3fd2c9f2c77: Download complete
14abfa4935c1: Verifying Checksum
14abfa4935c1: Download complete
79d3b412d726: Pull complete
68f7f2742242: Pull complete
e3fd2c9f2c77: Pull complete
14abfa4935c1: Pull complete
Digest: sha256:75f730545dbb17912349beac563d838cd22a9aaa53eaaf7f18efcf368fa5b91a
Status: Downloaded newer image for gotify/server:2.0.22
write /dev/stdout: broken pipe

The health entries still appear and there's a new error message "WebSocket: ReadError read tcp 172.21.0.3:80->172.21.0.2:35506: i/o timeout"

@rucksman
Copy link
Author

rucksman commented Jan 12, 2023

"server:2.0.22" is not the current version anymore.

Then change it to the image you want to use (e.g. 2.2.4 or latest).

[bonelifer] posted a variant of it, so it this the right way to do it currently?

The solution @bonelifer posted is just a little more "precise" so to say, but both do work. I am using the line from @jmattheis since he posted it back in August 2021 in my docker-compose file and it still works.

I don't understand what it does

In very simplified terms, the command suppresses the output of all lines that match the string "/health" to the log.

@STaRDoGG
Copy link

STaRDoGG commented May 14, 2023

Healthcheck spam is one of those little easy to fix things that always drives me nuts, too.

I ended up fixing it for another container: LinkStackOrg/linkstack-docker#11

and you can see it here starting around this line: https://github.com/LinkStackOrg/linkstack-docker/blob/ef2fd131e623f2dd7fc75a31c9e0307918c3d0a0/docker-entrypoint.sh#LL51C15-L51C15

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Development

Successfully merging a pull request may close this issue.

10 participants