WildFly metrics needs to be exposed to Prometheus.

      In the current implementation of the microprofile-metrics-smallrye subsystems, all WildFly metrics are exposed as Gauges[1] which represents a single numerical value that can goes up and down and may have a unit (e.g. bytes or seconds).

      We should be able to represent more correctly some metrics as Counters[2] which are "cumulative metric that represents a single monotonically increasing counter whose value can only increase or be reset to zero on restart"

      In its current state, metadata associated to WildFly metrics does not able to distinguish gauges and counters.

      • If the metric has a measurement unit (specified by, it can be represented as a Gauge
      • If the metric does not have a measurement unit, we can not reliably decide between gauge and counters.

      For example, the message-count[3] for the jms-queue resource is a gauge as this number will can go up (when messages are produced faster than they are consumed) or down (when messages are consumed faster than they are produced) to 0.

      Conversely, the messages-added[4] for the same jms-queue or request-count[4] for Undertow servlet are counters as they will always increase.

      Only the subsystem developers is able to specify which type of metrics it provides.
      I propose that we add 2 new values to to let the subsystem developers provides this information:


      In the absence of the COUNTER_METRIC, the metric would be identified as a Gauge.
      We had the GAUGE_METRIC value so that the subsystem developer can explicitly state that a metric is a gauge which is helpful when the same resource (e.g. jms-queue) provides metrics of the 2 different types (e.g. message-counter vs messages-added).

      This API change is backwards compatible.
      These 2 flags remain optional and would only be checked when the attribute definition is registered as a metric with


        Gliffy Diagrams




              • Assignee:
                jmesnil Jeff Mesnil
                jmesnil Jeff Mesnil
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: