search

prometheus / alertmanager

Prometheus Alertmanager
https://prometheus.io
Apache License 2.0
6.66k stars 2.16k forks source link

Receiver filter matching incorrectly #933

Open grobie opened 7 years ago

grobie commented 7 years ago

The receiver dropdown/type ahead filter uses an algorithm to determine the weight of every receiver and bases the order of the results on that. It additionally caps the result set at 10 items. The mix in of filter properties made it harder for me to form a mental model of the behavior. I'd suggest to use a more straight forward approach, use a filter and always keep the alphabetical order. Like the file search in Github or most editors.

Example:

Type: prodeng Expected: /p.*r.*o.*d.*e.*n.*g/ Unexpected:

@stuartnelson3

mxinden commented 7 years ago

@grobie As far as I understand, the receiver dropdown is not filtering but just sorting. As backend-engineering-productivity is closer to prodeng then osc-reporting it is listed first.

Please have a look at my question here and @stuartnelson3 subsequent answer here.

grobie commented 7 years ago

Oooh, thanks for the clarification. That wasn't clear to me from the ux.

Any reason to not just do plain filtering? Like in editors when searching for files.

On Sat, Jul 29, 2017, 15:56 Max Inden notifications@github.com wrote:

@grobie https://github.com/grobie As far as I understand, the receiver dropdown is not filtering but just sorting. As backend-engineering-productivity is closer to prodeng then osc-reporting it is listed first.

Please have a look at my question here https://github.com/prometheus/alertmanager/pull/910#issuecomment-316009575 ans @stuartnelson3 https://github.com/stuartnelson3 subsequent answer here https://github.com/prometheus/alertmanager/pull/910#issuecomment-316011192 .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prometheus/alertmanager/issues/933#issuecomment-318832596, or mute the thread https://github.com/notifications/unsubscribe-auth/AAANaHS9NMKRAslIKKei199wqmH1j1sBks5sSzoGgaJpZM4OnVZf .

mxinden commented 7 years ago

Not sure. I would have to redirect this question on to @stuartnelson3.

stuartnelson3 commented 7 years ago

What we currently do is find string similarity and sort based on that. There's absolutely no reason why we can't add on to this (basic) functionality to e.g. filter out results whose similarity value is below a threshold.

The starts to become difficult because we'll be more or less arbitrarily picking a similarity value as the cut-off, and seeing how it works.

@grobie would you be interested in running a branch at SC with this enabled? It would be super helpful to tune the threshold based on a large production deploy like what is currently there.

grobie commented 7 years ago

I'm unsure about that approach to be honest. If I type prodeng I don't expect to see results for engineering productivity. My personal expectation of that feature would be to use a simple search behavior without any weighting as written in the (updated) issue description.

stuartnelson3 commented 7 years ago

Ok, I understand. The current search is matching because prod exists in both, but you expect as soon as you type prode that productivity would disappear from the list, because there's no match for the additional e.

beorn7 commented 7 years ago

As long as the best matches are on top of the list, and the total amount of displayed matches is limited, I actually prefer to show the fuzzy matches, too. That's also more and more common around the internet (I guess with fuzzy-searching large databases becoming more feasible), thus the moment of surprise @grobie encountered will become less common. The main use-case would be to be resilient against typos.