You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 18, 2023. It is now read-only.
Latency alerts tend to be most focused on succeeding calls, and since errors can already be accurately I would like to allow to ignore failing requests from the histogram metrics.
I am a bit torn though on what to do:
Make this configurable, I don't really like this because suddenly the same histogram metric of different processes may behave totally different from the next.
Change the default, this might cause unexpected behavior for users that are already using the library today.
Since I'm unable to ignore failed requests from the histogram at all today, I'm going to mark this as a bug, as it's essentially of no use as it is for alerting purposes.
Totally +100 to this. I was thinking about this as well. In fact I think we should care about user error, system error etc. Histograms per grpc code would be bit too cardinal IMO, but is also an option.
Literally, at any point now, we could release v2 officially. We already have release candidates. But I would love to have metrics in first so grpc-ecosystem/go-grpc-middleware#346
Plus I think the last thing that has to be finalized is moving to newest protobuf Go bindings which I kind of stopped at some point doing, so help wanted: grpc-ecosystem/go-grpc-middleware#321
Latency alerts tend to be most focused on succeeding calls, and since errors can already be accurately I would like to allow to ignore failing requests from the histogram metrics.
I am a bit torn though on what to do:
Since I'm unable to ignore failed requests from the histogram at all today, I'm going to mark this as a bug, as it's essentially of no use as it is for alerting purposes.
Wdyt @bwplotka ?
The text was updated successfully, but these errors were encountered: