[ZBXNEXT-1812] Definition of string mappings to return a string that is referenced by an other string found in item value Created: 2013 Jul 07 Updated: 2017 Nov 14 |
|
Status: | Open |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Proxy (P), Server (S) |
Affects Version/s: | 2.0.6 |
Fix Version/s: | None |
Type: | New Feature Request | Priority: | Minor |
Reporter: | Marc | Assignee: | Unassigned |
Resolution: | Unresolved | Votes: | 1 |
Labels: | macros, trigger, valuemapping | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
Linux, CentOS-6.4, PostgreSQL 9.1.9, Apache HTTPD-2.2.15, PHP-5.3.3 |
Description |
Beside value mapping used in frontend I would like to have something similar for use in simple macros within triggers. Think about applications with a lot of error codes like Oracle error messages or messages produced by Tivoli Storage Manager.
I would neither want to use triggers with common filters like .count(5m,"ORA-")#0 => A common Oracle error occured... nor to create thousands of triggers with exact filters. I think about the possibility to import one generic mapping definition per application (Oracle, TSM,...) that might be used to map thousands of error codes to error messages. This way one could define very generic triggers with pretty messages even on varying error code positions in item values. |
Comments |
Comment by Marc [ 2013 Jul 07 ] |
Distantly related to |
Comment by richlv [ 2013 Jul 08 ] |
maybe you can provide an example on how a global regexp does not solve this, as it's not so easy to figure out what the need is |
Comment by Marc [ 2013 Jul 09 ] |
Can't imagine how to achieve this by global regular expressions. What I think about is having the ability to put possible error code<->message mapping from here or here in some kind of bundled mappings similar to value maps: Oracle mapping bundle: or a Tivoli Storage Manager mapping bundle: If you take a look at the amount of possible error codes it's obviously one wants to do this only one time for general usage (and exchange by import/export in a bundle context) There are several use cases that may benefit from this. in trigger name or in notifications. In short: |