-
Problem report
-
Resolution: Fixed
-
Minor
-
4.0.1
-
GNU/Linux
-
Sprint 46, Nov 2018, Sprint 47, Dec 2018
-
3
Steps to reproduce:
1. Create item with 9 captured groups in regexp and all 10 possible groups in "output template":
log[/home/zabbix/test.log,(ABC)(DEF)(GHI)(JKL)(MNO)(PQR)(STU)(VWX)(YZ),,,,g1:\1 g2:\2 g3:\3 g4:\4 g5:\5 g6:\6 g7:\7 g8:\8 g9:\9 g0:\0]
2. Append to logfile a string: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Result is correct:
g1:ABC g2:DEF g3:GHI g4:JKL g5:MNO g6:PQR g7:STU g8:VWX g9:YZ g0:ABCDEFGHIJKLMNOPQRSTUVWXYZ
3. Reduce number of captured groups in regexp to 3, but leave all 10 groups in "output template" (do not restart agent):
log[/home/zabbix/test.log,(ABC)(DEF)(GHI),,,,g1:\1 g2:\2 g3:\3 g4:\4 g5:\5 g6:\6 g7:\7 g8:\8 g9:\9 g0:\0]
4. Append to logfile a string: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Result is incorrect:
g1:ABC g2:DEF g3:GHI g4:JKL g5:MNO g6:PQR g7:STU g8:VWX g9:YZ g0:ABCDEFGHI
Not-captured groups happen to contain their old values, although documentation https://www.zabbix.com/documentation/current/manual/config/items/itemtypes/zabbix_agent#supported_item_keys says that not-captured group is "an empty string if the N exceeds the number of captured groups".
This bug is not limited to log[] and logrt[] items. Similar results can be demonstrated with item preprocessing if output template references capture groups which do not exist in the regexp.
- caused by
-
ZBX-13730 High CPU / Faliure to Match REGEX
- Closed