Discussion thread for official Zabbix Template PHP-FPM

[AlexL]

This thread is designed to provide grounds for discussion of the official Zabbix Template for PHP-FPM.
The template and details of the template is available in GIT repository:
https://git.zabbix.com/projects/ZBX/...p/php-fpm_http
https://git.zabbix.com/projects/ZBX/.../php-fpm_agent


Zabbix is always looking for ways to improve our services and to make our users happier.
We pride ourselves on doing our best each and every day, but we know that there is always something more to learn.
We would like to hear back from you to know what have you liked and what would you improve in the template.

[janssensm]

Hi, this is my first post here.
I'm using zabbix since several months, so I'm still learning.
Thanks for posting this thread and the templates.
I imported the php-fpm-agent template from 5.0.6 and it's working, but not completely.
The host I monitor runs Debian Buster and php-fpm from debian repo.
I discovered that the php-fpm process was not found by the agent, appears that the process name I have to use is

php-fpm7.3

as it is found in top command. And after adjusting in the corresponding macro all started to work
So perhaps it's wise to guide people what command they should use to get the right process name. ps aux just lists

php-fpm

[LenR]

Since our upgrade, our zabbix fronted server gradually uses more swap. I'm trying to add the php-fpm template to the zabbix frontend to get statistics. I can't find a method to enable the php-fpm status and ping url's that works with apache. (zabbix 5.0, Centos 7.9, mysql)

Errors are:
[proxy_fcgi:error] [pid 20001] [client ::1:47976] AH01079: failed to make connection to backend: httpd-UDS
[proxy:error] [pid 20033] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php7.0-fpm.sock (*) failed

It looks like I need to enable a socket to php-fpm, but I can't find out how.

Thanks

[LenR]

The doc I followed had me add this apache conf file:

# Enable 'status' and 'ping' page
<LocationMatch "/(ping|status)">
SetHandler "proxy:unix:/run/php/php7.0-fpm.sock|fcgi://localhost"
</LocationMatch>

# Enable *real-time* 'status' page
<IfModule alias_module>
Alias /realtime-status "/usr/share/php/7.0/fpm/status.html"
</IfModule>

As far as I know Zabbix is the only php-fpm user we have.

[LenR]

Ok, I've got /status working with some hacking, including change the php-fpm listen to a socket. It was localhost:9000, will changing this effect the zabbix frontend?

Ping still doesn't work.

I'm working on a test system :-)

Thanks

[abompard]

Hey folks! I have a couple CentOS webservers with PHP-FPM to monitor. PHP-FPM config defaults to listening on a unix domain socket (/run/php-fpm/www.sock). I can't find a way to configure the Zabbix agent to use that for its ping and status queries. I have tried setting the PHP_FPM macros, but nothing worked.

I can change the listening method in PHP-FPM to localhost:9000 but it's a bit less secure on a shared server, so before I do that I wanted to make sure there's currently no way to use the unix domain socket for monitoring.

Thanks!

[bakoff]

Ok, I've got /status working with some hacking, including change the php-fpm listen to a socket. It was localhost:9000, will changing this effect the zabbix frontend?

Ping still doesn't work.

I'm working on a test system :-)

Thanks

Hi ! I have the same problem, with Apache... Do someone got a solution ?

[TrapoSAMA]

Hi!

i have a error with the template, get ping or status show Response code "404" did not match any of the required status codes "200" in the component but when check with curl is ok!

Some tips or idea?

Thx

[kristianr]

I also had problems (using "PHP-FPM by Zabbix agent" template) with the Ping item claiming my pool was down, and it seems the issue is with the preprocessing regex on the "PHP-FPM: Ping" item. By default (6.0 fresh install) it is {$PHP_FPM.PING.REPLY}($|\n), however this doesn't seem to match the output from the web.page.get in the master item, since that output has CRLF line endings. I suspect the CRLF line endings are standard from PHP-FPM's side (or Nginx?). Here's an example:

# zabbix_get -s localhost -k "web.page.get[\"localhost\",\"phpfpmping\",\"80\"]" | hexdump -C
00000000 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d |HTTP/1.1 200 OK.|
00000010 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f |.Connection: clo|
00000020 73 65 0d 0a 54 72 61 6e 73 66 65 72 2d 45 6e 63 |se..Transfer-Enc|
00000030 6f 64 69 6e 67 3a 20 63 68 75 6e 6b 65 64 0d 0a |oding: chunked..|
00000040 43 61 63 68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 6e |Cache-Control: n|
00000050 6f 2d 63 61 63 68 65 2c 20 6e 6f 2d 73 74 6f 72 |o-cache, no-stor|
00000060 65 2c 20 6d 75 73 74 2d 72 65 76 61 6c 69 64 61 |e, must-revalida|
00000070 74 65 2c 20 6d 61 78 2d 61 67 65 3d 30 0d 0a 43 |te, max-age=0..C|
00000080 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 |ontent-Type: tex|
00000090 74 2f 70 6c 61 69 6e 3b 63 68 61 72 73 65 74 3d |t/plain;charset=|
000000a0 55 54 46 2d 38 0d 0a 44 61 74 65 3a 20 4d 6f 6e |UTF-8..Date: Mon|
000000b0 2c 20 30 32 20 4d 61 79 20 32 30 32 32 20 31 31 |, 02 May 2022 11|
000000c0 3a 34 35 3a 34 33 20 47 4d 54 0d 0a 45 78 70 69 |:45:43 GMT..Expi|
000000d0 72 65 73 3a 20 54 68 75 2c 20 30 31 20 4a 61 6e |res: Thu, 01 Jan|
000000e0 20 31 39 37 30 20 30 30 3a 30 30 3a 30 30 20 47 | 1970 00:00:00 G|
000000f0 4d 54 0d 0a 53 65 72 76 65 72 3a 20 6e 67 69 6e |MT..Server: ngin|
00000100 78 2f 31 2e 31 38 2e 30 0d 0a 53 74 72 69 63 74 |x/1.18.0..Strict|
00000110 2d 54 72 61 6e 73 70 6f 72 74 2d 53 65 63 75 72 |-Transport-Secur|
00000120 69 74 79 3a 20 6d 61 78 2d 61 67 65 3d 31 35 37 |ity: max-age=157|
00000130 36 38 30 30 30 0d 0a 0d 0a 34 0d 0a 70 6f 6e 67 |68000....4..pong|
00000140 0d 0a 30 0a |..0.|
00000144

Modifying the regex in the preprocessing step can be done to fix this, but I kind of expected this to work out of the box. Also I noticed that if I curl this phpfpmping page directly, I don't get the same output in the body of the response:

With web.page.get:

# zabbix_get -s localhost -k "web.page.get[\"localhost\",\"phpfpmping\",\"80\"]"
HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Cache-Control: no-cache, no-store, must-revalidate, max-age=0
Content-Type: text/plain;charset=UTF-8
Date: Mon, 02 May 2022 11:51:22 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Server: nginx/1.18.0
Strict-Transport-Security: max-age=15768000

4
pong
0

With curl:

# curl -v http://localhost/phpfpmping
* Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET /phpfpmping HTTP/1.1
> Host: localhost
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.18.0
< Date: Mon, 02 May 2022 11:51:59 GMT
< Content-Type: text/plain;charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Cache-Control: no-cache, no-store, must-revalidate, max-age=0
< Strict-Transport-Security: max-age=15768000
<
* Connection #0 to host localhost left intact
pong

What are the lines with "4" and "0" above and below the "pong" in the output from zabbix_get? I get the same when fetching phpfpmstatus with zabbix_get/web.page.get as well, just different numbers ("17d" and "0"):

# zabbix_get -s localhost -k "web.page.get[\"localhost\",\"phpfpmstatus\",\"80\"]"
HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Cache-Control: no-cache, no-store, must-revalidate, max-age=0
Content-Type: text/plain;charset=UTF-8
Date: Mon, 02 May 2022 11:53:04 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Server: nginx/1.18.0
Strict-Transport-Security: max-age=15768000

17d
pool: www
process manager: static
start time: 19/Apr/2022:08:14:01 +0200
start since: 1143543
accepted conn: 493077
listen queue: 0
max listen queue: 0
listen queue len: 0
idle processes: 9
active processes: 1
total processes: 10
max active processes: 10
max children reached: 0
slow requests: 0

0

They also don't appear when using curl:

# curl -v http://localhost/phpfpmstatus
* Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET /phpfpmstatus HTTP/1.1
> Host: localhost
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.18.0
< Date: Mon, 02 May 2022 11:55:03 GMT
< Content-Type: text/plain;charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Cache-Control: no-cache, no-store, must-revalidate, max-age=0
< Strict-Transport-Security: max-age=15768000
<
pool: www
process manager: static
start time: 19/Apr/2022:08:14:01 +0200
start since: 1143662
accepted conn: 493162
listen queue: 0
max listen queue: 0
listen queue len: 0
idle processes: 9
active processes: 1
total processes: 10
max active processes: 10
max children reached: 0
slow requests: 0
* Connection #0 to host localhost left intact

If I fetch a test file from another domain, I don't see those lines:

# zabbix_get -s localhost -k "web.page.get[\"https://redacted\",\"temp/foo.txt\",\"443\"]"
HTTP/1.1 200 OK
Connection: close
Content-Length: 12
Accept-Ranges: bytes
Content-Type: text/plain
Date: Mon, 02 May 2022 11:55:57 GMT
Etag: "c-5de05d9ef9590"
Last-Modified: Mon, 02 May 2022 11:39:56 GMT
Server: Apache/2
Upgrade: h2,h2c
Vary: User-Agent

line1
line2

Something seems strange here, but I'm not really sure what to point at for being the root cause. It seems the two extra lines with numbers are added inside zabbix, and they use CRLF. Here's the hexdump for the phpfpmstatus contents:

# zabbix_get -s localhost -k "web.page.get[\"localhost\",\"phpfpmstatus\",\"80\"]" | hexdump -C
00000000 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d |HTTP/1.1 200 OK.|
00000010 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f |.Connection: clo|
00000020 73 65 0d 0a 54 72 61 6e 73 66 65 72 2d 45 6e 63 |se..Transfer-Enc|
00000030 6f 64 69 6e 67 3a 20 63 68 75 6e 6b 65 64 0d 0a |oding: chunked..|
00000040 43 61 63 68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 6e |Cache-Control: n|
00000050 6f 2d 63 61 63 68 65 2c 20 6e 6f 2d 73 74 6f 72 |o-cache, no-stor|
00000060 65 2c 20 6d 75 73 74 2d 72 65 76 61 6c 69 64 61 |e, must-revalida|
00000070 74 65 2c 20 6d 61 78 2d 61 67 65 3d 30 0d 0a 43 |te, max-age=0..C|
00000080 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 |ontent-Type: tex|
00000090 74 2f 70 6c 61 69 6e 3b 63 68 61 72 73 65 74 3d |t/plain;charset=|
000000a0 55 54 46 2d 38 0d 0a 44 61 74 65 3a 20 4d 6f 6e |UTF-8..Date: Mon|
000000b0 2c 20 30 32 20 4d 61 79 20 32 30 32 32 20 31 31 |, 02 May 2022 11|
000000c0 3a 35 38 3a 31 31 20 47 4d 54 0d 0a 45 78 70 69 |:58:11 GMT..Expi|
000000d0 72 65 73 3a 20 54 68 75 2c 20 30 31 20 4a 61 6e |res: Thu, 01 Jan|
000000e0 20 31 39 37 30 20 30 30 3a 30 30 3a 30 30 20 47 | 1970 00:00:00 G|
000000f0 4d 54 0d 0a 53 65 72 76 65 72 3a 20 6e 67 69 6e |MT..Server: ngin|
00000100 78 2f 31 2e 31 38 2e 30 0d 0a 53 74 72 69 63 74 |x/1.18.0..Strict|
00000110 2d 54 72 61 6e 73 70 6f 72 74 2d 53 65 63 75 72 |-Transport-Secur|
00000120 69 74 79 3a 20 6d 61 78 2d 61 67 65 3d 31 35 37 |ity: max-age=157|
00000130 36 38 30 30 30 0d 0a 0d 0a 31 37 64 0d 0a 70 6f |68000....17d..po|
00000140 6f 6c 3a 20 20 20 20 20 20 20 20 20 20 20 20 20 |ol: |
00000150 20 20 20 20 77 77 77 0a 70 72 6f 63 65 73 73 20 | www.process |
00000160 6d 61 6e 61 67 65 72 3a 20 20 20 20 20 20 73 74 |manager: st|
00000170 61 74 69 63 0a 73 74 61 72 74 20 74 69 6d 65 3a |atic.start time:|
00000180 20 20 20 20 20 20 20 20 20 20 20 31 39 2f 41 70 | 19/Ap|
00000190 72 2f 32 30 32 32 3a 30 38 3a 31 34 3a 30 31 20 |r/2022:08:14:01 |
000001a0 2b 30 32 30 30 0a 73 74 61 72 74 20 73 69 6e 63 |+0200.start sinc|
000001b0 65 3a 20 20 20 20 20 20 20 20 20 20 31 31 34 33 |e: 1143|
000001c0 38 35 30 0a 61 63 63 65 70 74 65 64 20 63 6f 6e |850.accepted con|
000001d0 6e 3a 20 20 20 20 20 20 20 20 34 39 33 32 39 36 |n: 493296|
000001e0 0a 6c 69 73 74 65 6e 20 71 75 65 75 65 3a 20 20 |.listen queue: |
000001f0 20 20 20 20 20 20 20 30 0a 6d 61 78 20 6c 69 73 | 0.max lis|
00000200 74 65 6e 20 71 75 65 75 65 3a 20 20 20 20 20 30 |ten queue: 0|
00000210 0a 6c 69 73 74 65 6e 20 71 75 65 75 65 20 6c 65 |.listen queue le|
00000220 6e 3a 20 20 20 20 20 30 0a 69 64 6c 65 20 70 72 |n: 0.idle pr|
00000230 6f 63 65 73 73 65 73 3a 20 20 20 20 20 20 20 39 |ocesses: 9|
00000240 0a 61 63 74 69 76 65 20 70 72 6f 63 65 73 73 65 |.active processe|
00000250 73 3a 20 20 20 20 20 31 0a 74 6f 74 61 6c 20 70 |s: 1.total p|
00000260 72 6f 63 65 73 73 65 73 3a 20 20 20 20 20 20 31 |rocesses: 1|
00000270 30 0a 6d 61 78 20 61 63 74 69 76 65 20 70 72 6f |0.max active pro|
00000280 63 65 73 73 65 73 3a 20 31 30 0a 6d 61 78 20 63 |cesses: 10.max c|
00000290 68 69 6c 64 72 65 6e 20 72 65 61 63 68 65 64 3a |hildren reached:|
000002a0 20 30 0a 73 6c 6f 77 20 72 65 71 75 65 73 74 73 | 0.slow requests|
000002b0 3a 20 20 20 20 20 20 20 20 30 0a 0d 0a 30 0a |: 0...0.|
000002bf

As you can see, the "17d" is followed by 0d0a (CRLF), and the end out the status from PHP-FPM is ending with first a 0a, then a 0d0a followed by the "0", and another 0a.

If anyone can make sense of any of this, please enlighten me. :-)