search

PromPHP / prometheus_client_php

Prometheus instrumentation library for PHP applications
https://prometheus.io/docs/concepts/metric_types/
Apache License 2.0
415 stars 91 forks source link

Document RedisNg #152

Open mvhirsch opened 4 months ago

mvhirsch commented 4 months ago

Hey @LKaemmerling ,

I'm using the artprima/prometheus-metrics-bundle Symfony bundle (which is built on this library) and need to add \RedisCluster support. Currently it fails connecting to multiple hosts (like a redis-cluster). I also noticed lack of predis support in #79. Well, I cannot add support for redis, but need to add support for \RedisCluster.

Starting to taking a deep look at this code, I noticed an undocumented RedisNg which you already suggested as (production-ready?) to ppl: #92, #98, #105. Looks like it's the next generation (focus on performance), but backwards-incompatible to Redis, is it?

Could you please share some thoughts on this, so I could propose a documentation/PR?

Thank you in advance!

LKaemmerling commented 4 months ago

RedisNG is basically an more optimized version of Redis. It contains a few breaking changes compared to the old Redis Storage.

LKaemmerling commented 4 months ago

https://github.com/PromPHP/prometheus_client_php/pull/99

mvhirsch commented 4 months ago

Thank you for answering.

RedisNG is basically an more optimized version of Redis. It contains a few breaking changes compared to the old Redis Storage.

I see, so it's safe to use it (production-ready)?

Question is: supporting both (Redis and RedisNg) will add more maintenance load over time. What's your current plan on this? Will there be a v3 dropping support for Redis and only go for RedisNg? If so it does make sense (at least to me) to build support for more Redis variations on that:

Is it possible to create a migration-script or upgrade guide for users switching to new RedisNg? That said it might be a chance to get rid of some legacy and win more support with less maintenance work.

LKaemmerling commented 4 months ago

Currently, it is not planned to remove the old Redis storage, however, it might make sense as you mentioned. Adding support for more redis variations makes sense IMHO. I'm not sure if this would make sense to build everything into one big Redis Adapter or if there should be a dedicated adapter for every variation.

RedisNG is production ready, a migration guide is not quite possible, it is as simple as "drop the whole content of all Redis Keys", they should not be used together.

(Same goes for APCng)