I am posting here first before opening an issue on Github. While conducting some testing on the new TCP socket module I have found that in some situations an incorrect value is reported for system.socket.family. I have observed this with metricbeat versions 5.2.1 and 5.2.2 (the only two that I tested). Notice in the sample data below that the local and remote addresses are clearly IPv4, however the family is designated as ipv6.
NOTE: metricbeat is running on CentOS7 with kernel 3.10.0-514.6.2
{
"@timestamp"e => e2017-02-20T18:00:56.312Z,
"system"e => e{
"socket"e => e{
"process"e => e{
"exe"e => ee"/usr/java/jdk1.8.0_102/jre/bin/java"e,
"cmdline"e => ee"/usr/bin/java -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+DisableExplicitGC -Djava.awt.headless=true -Dfile.encoding=UTF-8 -XX:+HeapDumpOnOutOfMemoryError -Xmx1g -Xms512m -Xss2048k -Djffi.boot.library.path=/usr/share/logstash/vendor/jruby/lib/jni -Xbootclasspath/a:/usr/share/logstash/vendor/jruby/lib/jruby.jar -classpath : -Djruby.home=/usr/share/logstash/vendor/jruby -Djruby.lib=/usr/share/logstash/vendor/jruby/lib -Djruby.script=jruby -Djruby.shell=/bin/sh org.jruby.Main /usr/share/logstash/lib/bootstrap/environment.rb logstash/runner.rb --path.settings /etc/logstash --path.config /etc/koios-es/logstash/conf.d/flow -r"e,
"pid"e => ee3163e,
"command"e => ee"java"e
},
"family"e => ee"ipv6"e,
"remote"e => e{
"port"e => ee9200e,
"ip"e => ee"192.168.12.41"e
},
"user"e => e{
"name"e => ee"root"e,
"id"e => ee0e
},
"local"e => e{
"port"e => ee43288e,
"ip"e => ee"192.168.12.32"e
},
"direction"e => ee"outgoing"e
}
},
"@metadata"e => e{
"beat"e => ee"metricbeat"e,
"type"e => ee"metricsets"e
},
"beat"e => e{
"hostname"e => ee"logstash2"e,
"name"e => ee"logstash2"e,
"version"e => ee"5.2.1"e
},
"@version"e => ee"1"e,
"host"e => ee"logstash2"e,
"metricset"e => e{
"rtt"e => ee15630e,
"module"e => ee"system"e,
"name"e => ee"socket"e
},
"type"e => ee"metricsets"e,
"tags"e => e[
e [0] ee"beats_input_raw_event"e
]
}
Has anyone else noticed this?
I am able to workaround/correct this using the CIDR filter in logstash, however it would be good to see if this can be corrected.
Rob