valkeyotel: key pattern as additional label for client-side metrics

[simonbos]

I am looking to use valkeyotel. The client-side metrics valkey_do_cache_miss and valkey_do_cache_hits seem super useful, but I would find it interesting to have the key pattern, e.g. book:{bookID} or author:{authorID} as an additional label.

Is this something I should solve in another way? Is this something you would be willing to support?

[rueian]

Hi @simonbos, I believe you can use the db.stmt attribute, which can be customized by the WithDBStatement functional option when you constructing the otel wrapper.

[simonbos]

Thanks, that seems exactly what I was looking for 🙏

[simonbos]

Hi @rueian, I tried it out and it looks like the db.stmt attribute is only added to spans, not to the metrics. (Correct me if I am wrong.)

[rueian]

Oh, sorry about that. You are right. Please try WithOperationMetricAttr instead: c1a6417

[rueian]

Sorry again. I just realized that WithOperationMetricAttr doesn't apply to valkey_do_cache_miss and valkey_do_cache_hits as well. It also doesn't allow you to customize the operation name with key patterns. We need a new option here.

I think parsing key patterns from a function like type StatementFunc func(cmdTokens []string) string could be quite hard. How about we have a more generic solution that allows users to pass user-defined labels through ctx?

[simonbos]

Hi, thanks for following this up! I completely agree that parsing key patterns from cmdTokens []string is hard (and error prone and somewhat inefficient). That's why in my current implementation I did not go for parsing the full key pattern, but only the resource type (which I could more easily retrieve by enforcing consistent cache keys).

Being able to pass a label through the context would be much nicer 👍

[Sukuna0007Abhi]

Hi @rueian @simonbos can I work on this

[rueian]

Hi @Sukuna0007Abhi, sure!

If you want to work on this, could you first give us a glance at what a sample code will look like for using it?