IN operator

[gongcon]

Currently the operator supports these options:
=, !=, >, <, >=, <=, starts-with, contains, does-not-contain, exists, not-exists, has-root-span, matches

For a high cardinality field, e.g., service name, there's no way we can specify a rule not to sample traces of a list of services. This requires an in operator.

[kentquirk]

Hi. We did look at creating in for #822 but our YAML library can't handle a value that is either a scalar or an array, and we didn't want to implement an alternative Values instead of Value because of the complexity it adds. So in #939 we implemented matches which, while not ideal, can handle a regexp that includes the | operation.

Instead of something like this:

Field: service.name
Operator: in
Values: [healthcheck, login]

A workaround is:

Field: service.name
Operator: matches
Value: "^(healthcheck|login)$"

We are considering the possibility of a more flexible rule language, and if that happens we'll definitely look at including an in operator.

[gongcon]

Unfortunately regex doesn't work for us. The list is quite long, hundred items. It errored out (OOM in log) when we tried it earlier.

[kentquirk]

Interesting. Thank you for following up. To make sure I understand, you are trying to drop traces matching a value in a list of choices?

[gongcon]

We want to keep traces for certain whitelist, but dropping/keeping shouldn't matter here. Only ask is that we can check if a field is in a list. Thank you.

[kentquirk]

OK. I've added it to the list of issues for consideration soon. I can't guarantee when but having a real known use case helps. We'll keep this issue updated.