Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal to deprecate the project for PHP 8.1+ #284

Open
blkperl opened this issue Feb 13, 2023 · 3 comments
Open

Proposal to deprecate the project for PHP 8.1+ #284

blkperl opened this issue Feb 13, 2023 · 3 comments

Comments

@blkperl
Copy link

blkperl commented Feb 13, 2023

First off thank you for providing this exporter.

I recently learned that PHP 8.1 added support for the openmetric status format and I think we should guide users of this project to use that feature for PHP 8.1 and above. There is only one outstanding compatibility issue on the php bug tracker at this time and it is probably not a blocker for the a large subset of users.

php/php-src#9494

I can open a PR for the README if this is a direction the project would like to take.

@itcsoft54
Copy link
Contributor

itcsoft54 commented Feb 14, 2023

Separated exporter are still usefull, if you want to limit ressources allocated to collect metrics or cache informations collected to avoid heavy load on php-fpm.

@blkperl
Copy link
Author

blkperl commented Feb 17, 2023

Hey @itcsoft54, I'm not sure I understand how metric collection would cause heavy load on php? There is a config for php-fpm that provides a dedicated php worker for the status page called pm.status_listen that might solve this issue for you. I use pm.status_listen so that metrics continue to flow when php hits the max worker.

So perhaps instead of deprecating the project we could mention on the readme that PHP offers this feature.

@itcsoft54
Copy link
Contributor

itcsoft54 commented Feb 18, 2023

After read this one : php/php-src#9494, I believe waiting is better than migrating.
In add, I believe that some label are missing : https://github.com/php/php-src/blob/b453c95fe809572f9723265a46dd9de9ca4d8a6f/sapi/fpm/fpm/fpm_status.c#L387

Some proposed improvements like (php/php-src#9494 (comment)) make problems with pid cardinality (or pid_hash like we fix in #110)

For heavy load, we can use separated exporter to control ressources allocated for metric (with per process limitation, cgroups, network interconnection...). Even If you use dedicated socket in php-fpm, you can't control resources for metrics like with a separated process. With separated exporter you can limit flow before connecting to php-fpm socket (unix or tcp).

Other advantage to keep collector / exporter separated from process of php-fpm is to split supervisor network to service network. You can by locate "collector to exporter network" to one network, and "exporter to php-fpm" in another one (production network). with no routing between both. Exporter are point of forward in one way (exporter to php-fpm).

In Add, when using containers, i prefer to use sidecar container separated from production containers for metrics even if process has his own "metrics" endpoint.

So at this time, I mean it's better to wait and see.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants