Uploaded image for project: 'ZABBIX BUGS AND ISSUES'
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-21841

Silly trigger prototypes in pool discovery rules for the WildFly template

XMLWordPrintable

    • Icon: Problem report Problem report
    • Resolution: Unresolved
    • Icon: Trivial Trivial
    • None
    • 6.2.2
    • None
    • None

      Steps to reproduce:

      1. Configure the jmx for wildfly server with the highly used (DS1) and slightly used (DS2) datasources with idle timeout configured
      2. Add the "WildFly Server by JMX" template to server (Official JMX Template for WildFly)
      3. Wait until DS1 will be overflowed several times
      4. Don't trigger DS2 connections usage

      Result:

      • Trigger "WildFly DS1: Too many waiting connections" will be raised, but never solved until server restart.
      • Trigger "WildFly DS2: There are timeout connections" will be raised periodically.

      Expected:
      Usually, we expect that triggers will be solved by themself after the solution of problem. Also, we don't expect any trigger raising during the system idle.

      Comments:
      Trigger prototype "WildFly {#JMX_DATA_SOURCE}: Too many waiting connections" from "Pools metrics discovery" has expression:

      min(/WildFly Server by JMX/jmx["{#JMXOBJ}",WaitCount],5m)>{$WILDFLY.CONN.WAIT.MAX.WARN}

      which seems expect WaitCount parameter to return the value of current waiting connection. Actually, according to the documentation: "WaitCount The number of requests that had to wait to obtain a physical connection", and, according to the ironjacamar project's source (datasource engine in wildfly), the WaitCount will never decreased until clearing statistics. So, it's ok to use the change speed for the trigger, but not the absolute value (because such trigger will never be solved).

      Trigger "WildFly {#JMX_DATA_SOURCE}: There are timeout connections" from "Pools metrics discovery" has expression:

      last(/WildFly Server by JMX/jmx["{#JMXOBJ}",TimedOut])>0

      so it will be raised each time when the connection is removed from the pool and closed physically due to the exceeding of the configured "Idle Timeout Minutes". Removing the excess of connections during idle is normal process, so it's strange to raise trigger.

      Suggestions:

      1. Change "WildFly {#JMX_DATA_SOURCE}: Too many waiting connections" trigger to the differential value
      2. Disable trigger "WildFly {#JMX_DATA_SOURCE}: There are timeout connections" by default

            zit Zabbix Integration Team
            a_marinchuk Andrey Marinchuk
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: