Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upBuggy Discovery behavior #4914
Comments
This comment has been minimized.
This comment has been minimized.
|
Which version of Prometheus is it? |
simonpasquier
added
the
component/service discovery
label
Nov 26, 2018
This comment has been minimized.
This comment has been minimized.
|
prometheus 2.4.3, but it's actual in master https://github.com/prometheus/prometheus/blob/master/discovery/marathon/marathon.go#L352 |
This comment has been minimized.
This comment has been minimized.
|
Yep I see the bug now. |
simonpasquier
added
the
kind/bug
label
Nov 26, 2018
simonpasquier
referenced this issue
Nov 26, 2018
Merged
discovery/marathon: fix leaked connections #4915
xjewer
pushed a commit
to xjewer/prometheus
that referenced
this issue
Nov 26, 2018
simonpasquier
added this to the v2.6.0 milestone
Nov 26, 2018
xjewer
referenced this issue
Nov 26, 2018
Closed
close response.Body for the marathon discoverer #4916
simonpasquier
closed this
in
#4915
Nov 27, 2018
simonpasquier
removed this from the v2.6.0 milestone
Nov 30, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
johnskopis commentedNov 26, 2018
Sorry for the terrible bug report. I don't have more time to spend on this and it's not incredibly critical.
Seems the Discovery instance (at least for marathon) does not close response so underlying transport leaks sockets. This was observed on a server trying to scrape an endpoint returning 5xx errors. After some period of time you can observe many sockets in CLOSE_WAIT state
After removing the faulty Discoverer from config and reloading the leaked sockets are not cleaned up (why?)