-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using routes.unmatched: heuristic
interferes with Prometheus/Grafana regex interpretation
#1410
Comments
Hey @marevers, thanks for reporting!
How is this unhandy? isn't just scape the character? |
I was now able to escape them with double \ e.g. |
I see, definitively it's unpractical. I wouldn't mind make this configurable, but I think it's a bit overkill to add just a config option for that. Maybe we can come up with a better character/word than |
What about |
This is a good point, our use of asterisk came from looking at what the OpenTelemetry Java SDK did for unknown routes, but perhaps we can replace it in 2.0 which is a major new release. Adding '{}' might be an option too, but to make the code perform it was easier to use a single character. The loop in the heuristic processor is ugly because it's highly specialized, we were concerned with performance. |
Dummy question: wouldn't escaping the asterisks work?
or maybe
|
@mariomac it does, your option 2 works like I mentioned in my earlier comment. So it can indeed be worked around, but it would be better to use a character that is not interpreted by regex at all. |
If the following is enabled in the configuration:
Beyla will automatically identify certain parts of the route (like numeric ids) and replace them with an asterisk in order to prevent high-cardinality metrics and to be able to analyze common routes even if the path contains a unique id. However, the specific use of an asterisk (
*
) can introduce some problems when using regex in the label selectors.For example, if you want to match a certain list of paths, the asterisk is interpreted as regex which causes no matches.
Here I would expect metrics from these two specific HTTP routes, but there are no results, because:
This can be worked around, but is unhandy at times.
I would suggest making the replacement character (currently the asterisk) configurable. The asterisk can stay the default, but maybe it could be made configurable so the user can choose something else instead of an asterisk (either a single character or a string of characters).
The text was updated successfully, but these errors were encountered: