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

No info about hop address in MTR metric #49

Open
arsbest opened this issue Apr 9, 2024 · 5 comments
Open

No info about hop address in MTR metric #49

arsbest opened this issue Apr 9, 2024 · 5 comments

Comments

@arsbest
Copy link

arsbest commented Apr 9, 2024

I use network_exporer v1.7.6.
For example try to probe mtr google.com. And i cant see in metric addresses of intermediate hops.
If i correctly understand this info must be in path label

# TYPE mtr_hops gauge
mtr_hops{name="google",target="142.250.147.100"} 29
# HELP mtr_rtt_seconds Round Trip Time in seconds
# TYPE mtr_rtt_seconds gauge
mtr_rtt_seconds{name="google",path="172.17.0.1",target="142.250.147.100",ttl="1",type="best"} 8.7974e-05
mtr_rtt_seconds{name="google",path="172.17.0.1",target="142.250.147.100",ttl="1",type="csd"} -9.223372036854776e+09
mtr_rtt_seconds{name="google",path="172.17.0.1",target="142.250.147.100",ttl="1",type="last"} 8.7974e-05
mtr_rtt_seconds{name="google",path="172.17.0.1",target="142.250.147.100",ttl="1",type="loss"} 0.8333333333333334
mtr_rtt_seconds{name="google",path="172.17.0.1",target="142.250.147.100",ttl="1",type="mean"} 8.7e-05
mtr_rtt_seconds{name="google",path="172.17.0.1",target="142.250.147.100",ttl="1",type="range"} 0
mtr_rtt_seconds{name="google",path="172.17.0.1",target="142.250.147.100",ttl="1",type="sd"} 0
mtr_rtt_seconds{name="google",path="172.17.0.1",target="142.250.147.100",ttl="1",type="sum"} 8.7974e-05
mtr_rtt_seconds{name="google",path="172.17.0.1",target="142.250.147.100",ttl="1",type="usd"} 0
mtr_rtt_seconds{name="google",path="172.17.0.1",target="142.250.147.100",ttl="1",type="worst"} 8.7974e-05
mtr_rtt_seconds{name="google",path="unknown",target="142.250.147.100",ttl="10",type="best"} 0
mtr_rtt_seconds{name="google",path="unknown",target="142.250.147.100",ttl="10",type="csd"} 0
mtr_rtt_seconds{name="google",path="unknown",target="142.250.147.100",ttl="10",type="last"} 0
mtr_rtt_seconds{name="google",path="unknown",target="142.250.147.100",ttl="10",type="loss"} 1
mtr_rtt_seconds{name="google",path="unknown",target="142.250.147.100",ttl="10",type="mean"} 0
mtr_rtt_seconds{name="google",path="unknown",target="142.250.147.100",ttl="10",type="range"} 0
mtr_rtt_seconds{name="google",path="unknown",target="142.250.147.100",ttl="10",type="sd"} 0
...

If I run local mtr google.com i can see host ip for each hop.

@Inevitable
Copy link

I'm also seeing this behavior with mtr targets. Something is preventing path from being stored for a number of hops, resulting in most data points being associated with unknown.

I've confirmed that running mtr to the same target manually from within the network_exporter container results in the expected hop values/ips. Wish I had more insight as to where exactly it might be encountering issues. Happy to set flags/logging etc if it would help narrow down!
My data is pretty similar as well:

mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="unknown", target="204.2.29.8", ttl="11", type="best"}
0
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="unknown", target="204.2.29.8", ttl="12", type="best"}
0
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="unknown", target="204.2.29.8", ttl="13", type="best"}
0
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="unknown", target="204.2.29.8", ttl="14", type="best"}
0
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="unknown", target="204.2.29.8", ttl="15", type="best"}
0
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="unknown", target="204.2.29.8", ttl="3", type="best"}
0
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="unknown", target="204.2.29.8", ttl="4", type="best"}
0
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="unknown", target="204.2.29.8", ttl="5", type="best"}
0
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="unknown", target="204.2.29.8", ttl="6", type="best"}
0
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="unknown", target="204.2.29.8", ttl="7", type="best"}
0
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="unknown", target="204.2.29.8", ttl="8", type="best"}
0
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="unknown", target="204.2.29.8", ttl="9", type="best"}
0
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="10.10.10.1", target="204.2.29.8", ttl="2", type="csd"}
0.000036422
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="192.168.160.1", target="204.2.29.8", ttl="1", type="csd"}
0.000020767
mtr_rtt_seconds{host="network_exporter", instance="network_exporter:9427", job="vm_network_exporter", name="target_1", path="204.2.29.8", target="204.2.29.8", ttl="16", type="csd"}

D444Z0Aw4b

@gaopeiliang
Copy link

#65

@Inevitable
Copy link

Inevitable commented Feb 4, 2025

Would love to test this fix, but I'm a bit of a go novice; given that it's building as a go mod referencing syepes/network_explorer, what's the correct/least terrible way to grab and build the pr commit? Is it really just as simple as adding a replace to go.mod for the pr fork?

If so, I think I'm still experiencing the issue, as most path values are still "unknown". I'm willing to bet, though, that I've not properly included the pr code changes

@gaopeiliang
Copy link

gaopeiliang commented Feb 5, 2025

Would love to test this fix, but I'm a bit of a go novice; given that it's building as a go mod referencing syepes/network_explorer, what's the correct/least terrible way to grab and build the pr commit? Is it really just as simple as adding a replace to go.mod for the pr fork?

If so, I think I'm still experiencing the issue, as most path values are still "unknown". I'm willing to bet, though, that I've not properly included the pr code changes

  1. make build-local output bin from local source code
  2. copy Bin to Docker image like this dockerfile
FROM syepes/network_exporter
WORKDIR /app
COPY artifacts/network_exporter_linux_amd64_v1/network_exporter network_exporter
RUN setcap 'cap_net_raw,cap_net_admin+eip' /app/network_exporter
CMD ["/app/network_exporter"]

@Inevitable
Copy link

Thanks for that, quite straightforward. Can confirm the issue is resolved with your pr! #65

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

3 participants