Cannot show ping because icmp.rtt.us no value

Elastic Stack Beats
,
1

Hello everyone

I have a project to make some monitoring with ELK stack then for the monitoring i use grafana for user client. But i have a problems when im try to show up Ping visualization.
There is no value for icmp.rtt.us or rtt.us no available.

12313123213213333
123131232132133331365×665 81.2 KB

In Heartbeat /monitor.d i have already creating icmp.conf and configure on it.

this is the configuration from ./monitor.d/icmp.conf

# These files contain a list of monitor configurations identical
# to the heartbeat.monitors section in heartbeat.yml
# The .example extension on this file must be removed for it to
# be loaded.

- type: icmp # monitor type `icmp` (requires root) uses ICMP Echo Request to ping
 # configured hosts

# Monitor name used for job name and document type.
name: icmp

# Enable/Disable monitor
enabled: true

# Configure task schedule using cron-like syntax
schedule: '*/5 * * * * * *' # exactly every 5 seconds like 10:00:00, 10:00:05, ...

# List of hosts to ping
hosts: ["monitoring", "monitoring2"]

# Configure IP protocol types to ping on if hostnames are configured.
# Ping all resolvable IPs if `mode` is `all`, or only one IP if `mode` is `any`.
ipv4: true
ipv6: false
mode: any

# Total running time per ping test.
timeout: 16s

# Waiting duration until another ICMP Echo Request is emitted.
wait: 1s

# The tags of the monitors are included in their own field with each
# transaction published. Tags make it easy to group servers by different
# logical properties.
#tags: ["service-X", "web-tier"]

# Optional fields that you can specify to add additional information to the
# monitor output. Fields can be scalar values, arrays, dictionaries, or any nested
# combination of these.
#fields:
#  env: staging

# If this option is set to true, the custom fields are stored as top-level
# fields in the output document instead of being grouped under a fields
# sub-dictionary. Default is false.
#fields_under_root: false

this is very important to me to show up PING in my monitoring stack

Any ones know what happent? and can u give me some tricks for this problem?

2

You can get this value via the monitor.duration.us field. That measures the total execution for the monitor, which for an ICMP ping is equivalent.

3

thanks for reply

it work,but as you say. It is showing for the total execute to the monitor.
can u give me some trick To visualise PING for visualizing running Ping every second on graph? not for the total ping the machine can reach?

4

The time to execute the monitor is the rtt time. I suppose we could have another timer slightly closer to the point in the code where the packet is received but I don't have reason to believe it would yield a meaningfully different timing.

It's possible that it would, but very unlikely, and would need to be proven.

5

WRT to the visualization, you'll want to to aggregate by date_histogram, and probably choose the min/max or average monitor.duration.

6

I'm realizing that what I said earlier is incorrect, the monitor.duration should include DNS resolution time as well, I'll look into adding the icmp.rtt.us value back into heartbeat.

7

Hello Andrew,

I am having a similar issue with icmp.rtt.us. When I try to agregate to get the average value of icmp.rtt.us from hosts, the query returns null for every monitor.ip. Below is the query I am using.

    GET heartbeat-7.6.2-2020.04.22-000001/_search?pretty
    {
      "query": {"match": {
        "monitor.type": "icmp"
      }},
      "aggs": {
        "IPs": {
          "terms": {
            "field": "monitor.ip"
          },
          "aggs": {
            "avg_lat": {
              "avg": {
                "field": "icmp.rtt.us"
              }
            }
          }
        }
        
      }
    }

When I change the field value from icmp.rtt.us to monitor.duration it returns valid average values.

Is this really a issue or Am I doing something wrong?

Thank you

8

I found the bug and have opened up an issue to fix this here: https://github.com/elastic/beats/pull/17920

9

Thank you Andrew. I will follow this case.

1 Like
10

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.