For what version of Zabbix, agent "web.page.regexp[]" started to work?

[lserranov]

Hello, I installed the latest zabbix appliance and in this version I can create an item:

Type: Zabbix agent
Key: web.page.regexp[host,demo/DemoServlet,8080,"RUNNABLE : (.*)",,\1]

Then I created a template and then I assigned this template to some hosts and things work.

However in version 2.4.6 same configuration gives "Not Supported By Zabbix Agent". Please notice that I have seen other folks reporting similar problem in other versions.

So my question is, what is the version of zabbix where this problem got fixed? That way I can start thinking to migrate to such version.

Note: I wish a 2.X version fixed the problem so that the update is not a major one.

Please let me know.
Many thanks in advance.
Luis

[lserranov]

This is the only thing I see in the log when things fail:

32225:20180613:023813.643 item "hanabcf23:web.page.regexp[10.125.1.193,demo/DemoServlet,8080,"RUNNABLE : (.*)",,\1]" became not supported: Not supported by Zabbix Agent

[lserranov]

BTW, where this functionality is implemented, in the zabbix client or in the server? If is in the client, could I just upgrade the client?

Thanks!

[kloczek]

web.page.regexp[] is definitely working since 3.0.x.
I'm using it in my Apache template https://github.com/kloczek/zabbix-te...rvice%20Apache

[lserranov]

Hello kloczek , yes it works in latest version but not in 2.4.6.

I did a test yesterday nigth, zabbix server stayed in 2.4.6 version, I put one zabbix client in 3.4 version, things work.

So now the question is, can I upgrade just the clients to 3.4 and leave the server in version 2.4.6 at least for now?

Thanks
Luis

[kloczek]

Hello kloczek , yes it works in latest version but not in 2.4.6.

I did a test yesterday nigth, zabbix server stayed in 2.4.6 version, I put one zabbix client in 3.4 version, things work.

So now the question is, can I upgrade just the clients to 3.4 and leave the server in version 2.4.6 at least for now?

As you probably know 2.4.x is no longer supported. So that is one small pebble which needs to added to this stack of things :P
I would not recommend to do upgrade in one step.
Especially if you already have enough big database.
On each major version upgrade zabbix is able to treat database data in way which makes all this set of data more consistent.
In other words each major upgrade uhides/exposes some set of host settings, linked templates issue, or even some database contents issues like duplicated primary keys in some tables.
Usually after each major upgrade is necessary to review some number of hosts settings or server/proxies/agents warnings or errors or even some strange DB backend errors or warnings.
Longer history have some oldest database data than higher probability is that during upgrade new zabbix versions will be taking care of some number of issues which on previous version was not easy to spot or diagnose.
As you have under your hands zabbix 2.4 really IMO it would be better go over 2.4->3.0.x->3.2->3.4 steps.
Why? Because on each steps you will be dealing with only part of all hidden to your eyes now issues.
In other word it would be easier to bite one by one all those issues
Doing full upgrade to up-to-date state in few smaller steps will give you confidence about generally major upgrades procedures.
Confidence is really important at some point to have less stressful job :P
I can guaranteed you that first upgrade 2.4->3.0 upgrade will be the hardest.
Depends on database size and storage backend speed I would recommend organize slave database instance on which you would be able to optimize tables or add/change table tables partitioning.
With optimized/cleaned DB on slave than failover to this instance as master you would be able minimize downtime when new version of the zabbix server will be firs time touching database content to execute set of alter tables queries transforming database scheme to new version.
With slave db instance is possible as well to test full upgrade to prove that upgrade will be successful. It allows as well quite precisely test how long upgrade will take. This is especially important in envs with strict change control procedures.
On testing such upgrade using slave all what is needed is just add couple of FW rules to cut off communication of such temporary second instance of zabbix server with all prod zabbix stack parts (proxies, zabbix/IPMI/SNMP agents web front ends and other parts like JVM or VMware pollers).

If you don't have already this you should as well move all possible to move monitoring to proxies leaving on the server only monitoring the zabbix server themeselve.
If database alter queries may take hour by move all monitoring to proxies you will have not interrupted by upgrade process monitoring data.
After tested upgrade on slave database you would be able to measure for how many hours you need to have cyclic buffer on the proxies.

Remember that after server upgrade some monitoring may not be working as expected only because some nown changes in srv<>prx communication protocol. So after server upgrade to finally confirm that everything is OK all proxies upgrade to the same version as server needs to be done ASAP.

[[email protected]]

ABC posted in error