Packetbeat: Not listening to mysql

I'm using packetbeat for monitoring MySQL, I've configured it using following configuration but it is not listening to the ports.

interfaces:
  device: 0

protocols:
  dns:
    ports: [53]

    include_additionals: true

  http:
    ports: [80, 8080, 8000, 5000, 8002]

  mysql:
    ports: [3306]

  memcache:

    ports: [11211]

  mysql:
    ports: [3306]

  mongodb:
    ports: [27017]

procs:
  enabled: true
  monitored:
    - process: mysqld
      cmdline_grep: mysqld

    - process: java
      cmdline_grep: java

output:

  elasticsearch:

    hosts: ["localhost:9200"]

    save_topology: true


shipper:

logging:

  files:
    rotateeverybytes: 10485760 # = 10MB

Is the issue only with MySQL? Under device you have configure device: 0. Not sure if that will work. For the available options run packetbeat -devices.

If you would like to monitor the MySQL traffic, you need to make sure that the mysql requests are sent over the network and not to the MySQL unix socket as Packetbeat can monitor only the network traffic. If MySQL is running on localhost, you can solve the problem by setting the IP to 127.0.0.1 instead of localhost.

@ruflin , currently we are just looking for mysql and http monitoring so we are not considering,
pgsql, redis and others. So request you to guide us on this.

@monica, Here is my host file from C:/Windows/System32/drivers/etc

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#	::1             localhost
#	10.75.242.162   localhost
	127.0.0.1   localhost

Still it is not listening to mysql.

how is host file related here? You have to make sure the mysql client connects via TCP socket and not named pipe (which is default when connecting to localhost).

Is your application using prepared statements? The are currently not supported by packetbeat. See: https://github.com/elastic/beats/issues/683

@monica, => Can you guide us, in making sure that the mysql requests are sent over the network and not to the MySQL unix socket?

@steffens, => please guide us, for making sure the mysql client connects via TCP socket and not named pipe.

By the time, I'll check it out with Statements instead of PreparedStatements.

Apparently windows is a beats of its own. Out of the box winPcap (used by pcap and many other sniffers) is not able to sniff from localhost.There is a workaround based on npcap see related github issue.

For connecting via TCP check out your clients docs. The command line based mysql client has options like --host, --protocol, --port. See mysql docs.

I'm having the same issue on Debian, running PB 1.2.1 I can see http traffic but not my local mysql traffic. I tried a tcpdump in parallel with packetbeat and I see the tcpdump traffic on port 3306. Packetbeat on the other hand, shows that it processed packets but it doesn't publish them (tcpdump shows local time, packetbeat shows GMT time):

Do you know what could be wrong?

This is the interface and protocol config I'm using:

interfaces:
device: any
protocols:
mysql:
# Configure the ports where to listen for MySQL traffic. You can disable
# the MySQL protocol by commenting out the list of ports.
ports: [3306]
procs:
enabled: true
monitored:
- process: mysqld
cmdline_grep: mysqld
[.....]

One more thing relevant to add is that if I do a mysql query to a remote host from this machine packetbeat parses and publishes the results correctly. The problem is when issuing a local query on 127.0.0.1.

Thanks!

could it be related to packetbeat not supporting mysql prepared statements yet: https://github.com/elastic/beats/issues/683 ?