-
Notifications
You must be signed in to change notification settings - Fork 463
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
Perl regex syntax no longer accepted in any filter (plugin 4.2) #1264
Comments
@eithor as a workaround, try to scape the forward slash with a double one, something like: "//" instead a single one "/" @alexanderzobnin I can confirm the bug, linux partitions in item name like "Used Space on /var/log" suffer from this too, I needed to double type "//var//log" in grafana field to make it work. Looking at the error it seems to be something in golang backend. |
I confirm this issue. So, the current workaround is downgrade to 4.1.5. Waiting for the resolution. |
If I can put my 2 cents here, seems like the regex processing has moved from react frontend to golang backend, since there's a lot of lookahead/lookbehind errors with Perl like errors. If anyone can test (I'm in a pinch right now) try this documentation for creating the regex (it's the golang flavor): https://github.com/google/re2/wiki/Syntax |
@eithor please, can you change your issue title? I'd say: "Perl related error when parsing Regex" The truth is: "Javascript regex syntax no longer accepted in any filter" because the original flavor that we use is Javascript Regex. And the error is that there's a Javascript expression when the software says that it wanted a Perl like expression. |
Same for me in Grafana 8.1.2 and plugin version 4.2.x |
Well, as I understand it, it is more that Javascript regex support Perl-style regex syntax and golang does not (according to your link to re2). Still, end result is that plugin 4.2.x no longer supports Perl-style regex syntax - and changing all the dashboards to not use Perl-style regex is a huge undertaking (if possible). |
Yes, that's true. Since all data processing now moved to the bakend, regexps evaluated in Go. Go has a bit different engine (RE2) than JS, so some of existing patterns no longer supported. The syntax accepted by Golang described at https://golang.org/s/re2syntax. Unfortunately, I do not see any straightforward solution for this problem right now. I'll leave this issue opened and wait for more feedback. Maybe someone can suggest a workaround/fix. |
What about the need to double type literal forward slashes? It'll be a new default? Better doc it at least IMHO. |
@isaqueprofeta I have to investigate it a little bit more. But I agree, docs should be improved. |
@alexanderzobnin Since it works with Grafana 8.1.x and plugin 4.1.5, does this mean that you have changed your plugin to use backend instead of frontend regex parsing? What I'm asking perhaps is this: is this a forced choice by a Grafana API change, or a (needed) change that is introduced only in the grafana-zabbix plugin? |
@eithor It's a change introduced by plugin. In order to make alerting working with queries that contain functions, data processing should be on the backend. But it does not make sense to keep functions both on the frontend (non-alerting queries) and backend because it's tricky to support 2 different implementations. So now queries are fully handled on the backend. It's also better from the performance perspective. |
@alexanderzobnin I understand it complicates things, though not being able to say "give me all matches except those with the word XXX in them" will make the filtering very limited. I'm not sure how we could workaround this. Even your own plugin documentation example uses negative matching (perl regex syntax). |
It should be possible to use PCRE library either directly or via existing Golang wrappers. |
i-ky: Good call, a quick google gave me this example that uses golang pcre lib/wrapper: https://golangbyexample.com/golang-regex-backreferences/ |
Nice! I'll take a look. if |
+1 |
emmmmm, why I think the regex of grafana-zabbix has something wrong because the same panel in Grafana7.5.3 and plugin 4.1.5 is working. |
Unfortunately, |
I do not get, why regex is working in Group and host field (green) but not on item tag or item (red). maybe these are two different issues |
@jeff42, yes, looks like this is another issue. |
@alexanderzobnin What about this one: https://github.com/dlclark/regexp2 as an alternative that should work on Windows. |
@alexanderzobnin Or... this blog shows how to use libpcre also on Windows: https://xrstf.de/2018/04/go-regexp-vs-pcre/ |
@eithor |
@alexanderzobnin May I ask for an update on this issue? |
Any update in this? It is really critical. Regular expressions are widely beeing used in Grafana. So if you broke regexp, you broke many things! |
Is there still no solution for this? |
@alexanderzobnin Please, please have a look at PR #1472 to close this issue. I cannot upgrade Zabbix past 6.0 without this fix (since I would need the 4.2.9 fix for 6.2+). |
@eithor |
Since this issue is quite critical and it's a blocker for many users, I decided to release it as soon as possible. So here's a 4.2.10 release https://github.com/alexanderzobnin/grafana-zabbix/releases/tag/v4.2.10
then restart grafana server |
Is it just me or negative lookahead is still not working? |
@Phobos-7, do you have a specific example? |
Describe the bug
After update to 4.2.1 plugin (and grafana 8.1.1) any panel with an item/application/host/group filter that uses Perl regex syntax will show no-data. Using simpler regex syntax shows data as normal. Tried to switch from old "Graph" viz to the new "Time series" without any change in behaviour.
Expected behavior
Time-series graph shown also for Perl regex syntax filters as the same syntax worked previously (grafana 7.x/8.0 and plugin 4.1.5). Edit: it also works with grafana 8.1.2+plugin 4.1.5 (but that has other issues)
Network data
{"queries":[{"application":{"filter":"CPU"},"countTriggers":true,"functions":[],"group":{"filter":"/^Linux servers$/"},"host":{"filter":"/^mgc01$/"},"item":{"filter":"/^CPU (?!idle|usage|ready)/"},"minSeverity":3,"options":{"disableDataAlignment":false,"showDisabledItems":false,"skipEmptyValues":false,"useZabbixValueMapping":false},"proxy":{"filter":""},"queryType":"0","refId":"A","resultFormat":"time_series","table":{"skipEmptyValues":false},"tags":{"filter":""},"trigger":{"filter":""},"triggers":{"acknowledged":2,"count":true,"minSeverity":3},"itemTag":{"filter":"Application: CPU"},"datasource":"Zabbix","datasourceId":1,"intervalMs":10000,"maxDataPoints":931}],"range":{"from":"2021-08-12T05:34:20.111Z","to":"2021-08-12T08:34:20.111Z","raw":{"from":"now-3h","to":"now"}},"from":"1628746460111","to":"1628757260111"}
{"results":{"A":{"error":"error parsing regexp: invalid or unsupported Perl syntax:
(?!
","frames":[]}}}Software versions
The text was updated successfully, but these errors were encountered: