This relates to both the socket metricset in Metricbeat and the sockets metricset in Auditbeat, both of which use netlink to get a list of sockets from the Linux kernel, and then search /proc to find the process that holds the socket's inode.
However, some sockets are not owned by a user process, and so their inode cannot be found in /proc. Some of them can belong to RPC services (e.g. NFS is using an nlockmgr service), and it's possible to match such sockets to their RPC service by comparing the socket port to the ports that various RPC services use.
rpcinfo -p shows all the registered IPv4 RPC services and their ports on a host, rpcinfo localhost shows IPv6 services as well (but not the ports - I know, it's weird).
When writing Auditbeat's sockets metricset, I had originally added enrichment by RPC service using pmap_getmaps(3) to get a list of all registered RPC services on a system, but ran into a problem where every call to pmap_getmaps creates a new socket (which then is captured by the metricset, which triggers another call, and so on - endless socket creation). It should be possible to make this work by using more low-level methods to construct an RPC client and re-using it to query the RPC server.
It has grown to be too much work just now, but in case we want to do this in the future, the code is in a branch.
This relates to both the
socketmetricset in Metricbeat and thesocketsmetricset in Auditbeat, both of which use netlink to get a list of sockets from the Linux kernel, and then search/procto find the process that holds the socket's inode.However, some sockets are not owned by a user process, and so their inode cannot be found in
/proc. Some of them can belong to RPC services (e.g. NFS is using annlockmgrservice), and it's possible to match such sockets to their RPC service by comparing the socket port to the ports that various RPC services use.rpcinfo -pshows all the registered IPv4 RPC services and their ports on a host,rpcinfo localhostshows IPv6 services as well (but not the ports - I know, it's weird).When writing Auditbeat's
socketsmetricset, I had originally added enrichment by RPC service usingpmap_getmaps(3)to get a list of all registered RPC services on a system, but ran into a problem where every call topmap_getmapscreates a new socket (which then is captured by the metricset, which triggers another call, and so on - endless socket creation). It should be possible to make this work by using more low-level methods to construct an RPC client and re-using it to query the RPC server.It has grown to be too much work just now, but in case we want to do this in the future, the code is in a branch.