[jboss-jira] [JBoss JIRA] (WFCORE-4190) Distinguish undefined metric value

Distinguish undefined metric value ---------------------------------- Key: WFCORE-4190 URL: https://issues.jboss.org/browse/WFCORE-4190 Project: WildFly Core Issue Type: Bug Components: Management Affects Versions: 7.0.0.Alpha4 Reporter: Jeff Mesnil Assignee: Jeff Mesnil Priority: Critical WildFly resources can registered metrics for runtime read-only attributes whose value change during server activity. Some of these metrics are "disabled" by default (as they may be expensive to compute) and are enabled using a boolean attribute named statistics-enabled in their resource tree. When these metrics would not be able to compute their value, they could register a "undefined metric value" that would be returned by the :read-attribute handler if the metric read handler would return an undefined value. This causes a significant issue when one observes WildFly as it generates metrics figures that gives an incorrect observation of the server activity. Typical example is undertow metrics to see bytes sent and received on its http(s)-listeners[1]. When the metric is defined[2], it specifies an undefined metric value of 0. From the outside, when a monitoring tool will fetch value for the bytes-sent metric, it may return 0 in 2 different cases: * the metric is not enabled if the statistics-enabled attribute at [3] is false (which is the case by default). This does not mean that there is no network traffic. * statistics-enabled is true but there is no network traffic on the HTTP listener These 2 cases are wildly different but it is not possible to distinguish between them In order to distinguish these 2 cases, the :read-attribute operation (and by extension the :read-resource operation) will be enhanced with a "include-undefined-metric" operation parameter. This parameter is taken into account only for metric attribute: * if include-undefined-metric is true, the operation will return a undefined value from the metric's read handler *without substituting it by the *undefined metric value* from the metric AttributeDefinition * if the flag is false (by default), the current behaviour is used (if the read handler returns an undefined value, uses the *undefined metric value* from the metric AttributeDefinition. This will allow external monitoring tool (as well as the metrics subsystem from WFLY-10712) to know that the metric does not return a meaningful value. When I looked at various metrics registered in WildFly, some of them returns a meaningless value if the runtime code can not compute the value (e.g. Undertow statistics returns 0 if they are not able to obtain the underlying statistics[4]) in addition to defined an "undefined metric value" from the metric AttributeDefinition. These read handlers would have to be fixed so they MUST NOT return a defined value that does not correspond to the actual value required by the operation. [1] http://wildscribe.github.io/WildFly/14.0/subsystem/undertow/server/http-l... [2] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98... [3] http://wildscribe.github.io/WildFly/14.0//subsystem/undertow/index.html#a... [4] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...