Open aarengee opened 2 years ago
@aarengee Thank you for descriptive feature request. Keeping it here for discussion.
Hi @sazzad16 by when can we expect to close or get comments on this ? Like a month . Not pushing just asking the median time given past experience
@aarengee It could take several days/weeks get some discussions. Collaborators do it voluntarily besides their daily job.
From me, personally, we added Gson
and org.json
since Jedis 4.0.0 and we kind of have backlash for both of those. So at this moment I have more negative perception about adding new dependency than I usually do.
Yes I am very much grateful to all collaborators working on all OSS. You guys are the unsung heroes doing this not out of necessity and not for monetary gains. Fortune 500 companies save millions cause of OSS :)
Can you tag some active collaborators ? If the sentiment is same that adding prom support is out of scope which I completely understand then I will proceed to create a a simple three file project ( pom + java + test ) on my own account . Will also link it here just in case people want to use contribute or better decide to add it to jedis later on .
Thanks @sazzad16
Pinging @dengliming @yangbodong22011 @mina-asham @gkorland @chayim if you have some time.
@aarengee Thanks for your ticket.
The functions you describe (get maxTotal, maxIdle, minIdle, etc.) can be obtained and monitored directly through the JMX port (p.s. Jedis's DEFAULT_JMX_ENABLE
is true by default), it is more suitable as a function of Apache common-pool2
, not Jedis, that's exactly what it is now.
As a client, Jedis really needs to provide Trace functions, like Lettuce's Command Latency Metrics or go-redis with opentelemetry, there is no clear roadmap yet.
I will proceed to create a simple three file project ( pom + java + test ) on my own account . Will also link it here just in case people want to use contribute or better decide to add it to jedis later on .
Very welcome and thanks.
@yangbodong22011 hello, is there any news about latency meterics
This is very much needed, we are using Jedis in high scale systems and in case of issue having this metrics helps a lot in root causing.
Feature request to add a prometheus collector in jedis
Add a implementation of Collector in
src/main/java/redis/clients/jedis/metrics
package or utils maybeBasically a 1:1 clone of what HikariCP ships with here
Using this all
can be instrumented using a simple line of code
RedisCollector.getCollector().track(myjedisClusterOrPool)
Why as part of jedis and not as left upto user in there code.
In my opinion shipping it with jedis will add value to the library as it provides visibility to the user about the metrics as an inbuilt rather than having to instrument it separately.
As and when we add more metrics we can keep adding gauges/histogram/counter to the same collector . And the user wont even know these metrics are automatically available in the same registry . As soon as you upgrade your jedis library dependency metric is available. If I create it as a separate project then a pull request needs to be raised on that project , that project will have to upgrade jedis version , add those new metrics . All that
Prometheus is one of the most common timeseries in the industry with a simple to implement interface .
Why not do this in jedis ?
Sample code
Sample metrics
I would really like to contribute. Thanks for your consideration .