FPM is getting hammered with calls to "/status?json&full". How to disable this?

[benediktblank]

In our PHP-FPM Log we get many requests to "/status?json&full" that then receive auf 404.
[FPM ACCESS LOG] 14/Sep/2023:09:33:09 +0000 GET 404 0.000s 4194304 byte 0.00% CPU /status?json&full

When we disable the php-fpm_exporter it's gone, so it's coming from there.
When looking at the code I found that "/status?json&full" bit inside some tests.

We also seem to get the data we need so another (?) call to the FPM seems to go through but not that one

The question I have is, how can we disable that /status?json&full call?
Because that's flooding our fpm access log with that 404 message all the time.

[itcsoft54]

Hello,

If you go in this piece of code : https://github.com/hipages/php-fpm_exporter/blob/master/phpfpm/phpfpm.go#L166
You see that exporter use json&full to get metric. So if you have 404 in your log, exporter doesn't work and your php-fpm (or web server behind) is miss configured.

Maybe your exporter are miss configured to use two scrap url and one is targeting /status that isn't configured in php-fpm

[benediktblank]

Huh, two scrape urls would be something. Is there even a way to configure two scrape URLs in the exporter?

We have it like this:

 env:
            - name: PHP_FPM_SCRAPE_URI
              value: "tcp://127.0.0.1:9000/status" #"tcp://127.0.0.1:80/status"
            # Address on which to expose metrics and web interface.
            - name: PHP_FPM_WEB_LISTEN_ADDRESS
              value: ":9253"
            # Path under which to expose metrics.
            - name: PHP_FPM_WEB_TELEMETRY_PATH
              value: "/metrics"
            # Enabled to calculate process numbers via php-fpm_exporter since PHP-FPM sporadically reports wrong active/idle/total process numbers.
            - name: PHP_FPM_FIX_PROCESS_COUNT
              value: "true"
            # Only log messages with the given severity or above. Valid levels: [debug, info, warn, error, fatal] (default "error")
            - name: PHP_FPM_LOG_LEVEL
              value: "debug"

Maybe one status call goes against FPM and one goes against NGINX?
I think the one that is working goes against thr NGINX, and not the FPM.