-
Change Request
-
Resolution: Unresolved
-
Minor
-
None
-
4.0.15
-
QA
I have the following scenario:
The Discovery Rule:
Key: jmx.discovery[beans,"*:type=GarbageCollector,name=*"]
The Item Prototype:
Key: jmx[{#JMXOBJ},CollectionCount]
It works fine and creates the items as I need it to do:
Item 1) jmx["java.lang:type=GarbageCollector,name=PS MarkSweep",CollectionCount]
Item 2) jmx["java.lang:type=GarbageCollector,name=PS Scavenge",CollectionCount]
And it doesn't create items for the other GC types.
This is cost-effective, because it will only create items for existing "bean".
The problem showed up when I tried to create the Trigger Prototype... The expression doesn't allow me to specify the exact two different "JMXNAME"s of the two items that I need to use. It validates if the keys of the expression is exact the same as it was defined at the item prototype. This is useless for triggers that compare the value of two different items (when they are actualy discovered and exists into the Host).
I think that LLD for JMX need something like "regsub" for the keys of the items that Zabbix really discovers (or an option to not validate the prototype ones):
{TEMPLATE:jmx[{#JMXOBJ}.regsub("java.lang:type=GarbageCollector,name=PS Scavenge", \0),ThreadCount].last(0)}<{TEMPLATE:jmx[{#JMXOBJ}.regsub("java.lang:type=GarbageCollector,name=PS MarkSweep", \0),ThreadCount].last(0)}
I've managed achieve success, but in the ugliest way and it may impact on Zabbix's performance:
The Discovery Rule:
Key: jmx.discovery[beans,"*:type=GarbageCollector,name=*"]
The Item Prototypes:
Key: jmx["{#JMXDOMAIN}:type={#JMXTYPE},name=PS MarkSweep",CollectionCount] Key: jmx["{#JMXDOMAIN}:type={#JMXTYPE},name=PS Scavenge",CollectionCount] Key: jmx["{#JMXDOMAIN}:type={#JMXTYPE},name=ConcurrentMarkSweep",CollectionCount] Key: jmx["{#JMXDOMAIN}:type={#JMXTYPE},name=Copy",CollectionCount] Key: jmx["{#JMXDOMAIN}:type={#JMXTYPE},name=MarkSweepCompact",CollectionCount] Key: jmx["{#JMXDOMAIN}:type={#JMXTYPE},name=ParNew",CollectionCount]
In this way, the discovery creates the items that I need, but also creates unsupported items that I do not need at this moment, generating a considerable backlog of unwanted "Not supported" items.