Too many IPs result in artificial loss docs?

[drewr]

I was using a config that included www.facebook.com and www.google.com, along with a us-east-1 elb dualstack hostname, and all of this expands to quite an IP list once you figure in IPv6. I left that running for a day (with 12 sec interval), and noticed a ton of loss docs. Right after I would notice a loss doc, I would try manually pinging the address and it would be very responsive. So my graphs weren't giving me a real picture of connectivity.

Reducing the configuration to a simple set of about 5-6 IPs has eliminated the loss docs, including from ones that were reporting consistently before. The top graph is a median agg over the RTT values, the bottom is a count agg over loss: true. With the simpler config, they go to absent.

New config:

input:
  period: 12
  privileged: true
  useipv4: true
  useipv6: true
  targets:
    comcast:
      - xe-5-2-0-sur01.blairblvd.tn.nash.comcast.net
    comcast dns:
      - cdns01.comcast.net
    google dns:
      - google-public-dns-a.google.com
    level3:
      - 4.2.2.2

[joshuar]

Possibly related to this: tatsushid/go-fastping#14

So right, now, it's likely the losses are false positives a lot of the time with a lot of hosts and small periods. I might need to disable loss counts until the above gets fixed upstream, or look into it myself.

[joshuar]

Hey @drewr I've been working on a re-write of pingbeat that removes the dep on go-fastping. My rough preliminary testing is proving positive results and I'm hoping this artificial loss issue is now resolved. If you get a chance, try out the 1.0-beat1 release and see if that removes the issue?