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

Statsd UDP epoll warn logs are verbose when statsd down #2624

Open
shakuzen opened this issue May 27, 2021 · 9 comments · May be fixed by #4042
Open

Statsd UDP epoll warn logs are verbose when statsd down #2624

shakuzen opened this issue May 27, 2021 · 9 comments · May be fixed by #4042
Labels
help wanted An issue that a contributor can help us with registry: statsd A StatsD Registry related issue type: task A general task
Milestone

Comments

@shakuzen
Copy link
Member

shakuzen commented May 27, 2021

Testing on Linux, I can see we get logs like the following with #2611 (and therefore epoll enabled) when the statsd daemon isn't running:

2021-05-28 03:11:45.544  WARN 6373 --- [    udp-epoll-1] i.m.s.reactor.netty.channel.FluxReceive  : [id:35f314ec, L:/127.0.0.1:60434 - R:localhost/127.0.0.1:8125] An exception has been observed post termination, use DEBUG level to see the full stack: java.net.PortUnreachableException: readAddress(..) failed: Connection refused
2021-05-28 03:11:45.554  WARN 6373 --- [    udp-epoll-1] i.m.s.reactor.netty.channel.FluxReceive  : [id:35f314ec, L:/127.0.0.1:60434 - R:localhost/127.0.0.1:8125] An exception has been observed post termination, use DEBUG level to see the full stack: java.net.PortUnreachableException: readAddress(..) failed: Connection refused

This is a bit verbose compared to without epoll enabled, in this scenario of the statsd daemon being down.
With epoll enabled and the statsd daemon running, metrics are received and no logs are output, as expected.

Originally posted by @shakuzen in #2611 (comment)

@shakuzen shakuzen added the registry: statsd A StatsD Registry related issue label May 27, 2021
@shakuzen shakuzen added this to the 1.8.0-M1 milestone May 27, 2021
@jonatan-ivanov jonatan-ivanov modified the milestones: 1.8.0-M1, 1.8 backlog Jul 9, 2021
@shakuzen shakuzen modified the milestones: 1.8 tentative, 1.8.0 Oct 14, 2021
@shakuzen shakuzen changed the title Statsd epoll warn logs are verbose when statsd down Statsd UDP epoll warn logs are verbose when statsd down Nov 11, 2021
@shakuzen shakuzen added the type: task A general task label Nov 11, 2021
@shakuzen shakuzen modified the milestones: 1.8.0, 1.8.x Nov 11, 2021
@sureshnomula74
Copy link

@shakuzen is this issue fixed?

@shakuzen
Copy link
Member Author

It has not been fixed (this issue is still open), but note that this issue is only about overly verbose logging, and not a functional issue. If the configured statsd daemon address is reachable, these logs will not be output and your metrics will be sent. If you are experiencing a functional issue, please open a separate issue with details so we can diagnose that.

@shakuzen shakuzen added the help wanted An issue that a contributor can help us with label Oct 18, 2022
@jonatan-ivanov jonatan-ivanov modified the milestones: 1.8.x, 1.9.x Jan 12, 2023
@adithyaonline
Copy link

Any updates about this issue ?
We don't use statsd, Is there a way to disable statsd completely to make this error go away ??

@shakuzen
Copy link
Member Author

We don't use statsd, Is there a way to disable statsd completely to make this error go away ??

If you don't use statsd, do not add a dependency on the micrometer-registry-statsd module and the issue mentioned here cannot happen.

@abhishekladdha13
Copy link

@jonatan-ivanov @shakuzen
is there any open PR to fix this issue ?

@shakuzen
Copy link
Member Author

is there any open PR to fix this issue ?

No. We would be happy to review such a pull request. The issue is labelled with the help wanted label.

@jon-signal
Copy link

I've made an attempt to fix this in #4042.

@jon-signal
Copy link

We would be happy to review such a pull request.

@shakuzen I recognize this may not be a top priority, but I'm hoping to take you up on the offer to review a pull request (specifically #4042). I do think that change will make a big difference with minimal risk.

@shakuzen
Copy link
Member Author

Thanks for the reminder. Sorry we didn't review earlier. I've left a review on the PR now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted An issue that a contributor can help us with registry: statsd A StatsD Registry related issue type: task A general task
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants