That's the one I came across as well! I have a plan in my head for feeding this into zabbix, which goes something like this:
Run an LLD discovery script directly on all the sockets that matches /usr/local/php*/sockets/*.sock, and pass the username and php version to zabbix. This will ensure we find all php-fpm sockets, regardless of what php versions a user may have for their (sub) domains.
Then a script (e.g. cronjob) on the host that queries the discovered php-fpm sockets in a way that doesn't create a massive spike in number of php-fpm processes starting up. This should be done based on the pool settings (e.g. pm control, timeout, ..) and the resources on the server. I'm thinking of doing this in serial, with a few seconds delay between each, to allow php-fpm processes from earlier in the script to timeout and be killed off. How many to run at a time, how often to fetch the status will need to be adjusted based on the number of sockets you have for a single server, so I'm not sure exactly what I'll end up with here yet.
Run an LLD discovery script directly on all the sockets that matches /usr/local/php*/sockets/*.sock, and pass the username and php version to zabbix. This will ensure we find all php-fpm sockets, regardless of what php versions a user may have for their (sub) domains.
Then a script (e.g. cronjob) on the host that queries the discovered php-fpm sockets in a way that doesn't create a massive spike in number of php-fpm processes starting up. This should be done based on the pool settings (e.g. pm control, timeout, ..) and the resources on the server. I'm thinking of doing this in serial, with a few seconds delay between each, to allow php-fpm processes from earlier in the script to timeout and be killed off. How many to run at a time, how often to fetch the status will need to be adjusted based on the number of sockets you have for a single server, so I'm not sure exactly what I'll end up with here yet.
