6:31 a.m.
IMHO, technically, you don't need the hierarchy to report the metrics in your
examples.
<metric-set name="my-metrics">
<metric name="active-sessions"
resource="/deployment=hwk.ear/subdeployment=alerts.war/subsystem=undertow"/>
<metric name="request-count"
resource="/deployment=hwk.ear/subdeployment=alerts.war/subsystem=undertow/servlet=App/"
</metric-set>
Now if you want to report the resources, too, then yes, hierarchy is needed.
But there is a distinction between metrics and resources and I think we should
keep them as separate concepts - metrics maybe logically included in resources
but they should exist as standalone entities not inherently tied to resources.
If for nothing else then for the fact that we somehow have to report the
metrics to hawkular-metrics, where there is no concept of a resource (and I
think there never should be).
Now to the way how you would define a resource hierarchy.
IMHO the way we've done it in RHQ is more or less right. You define the types
of the resources, the possible "hierarchizations" (in RHQ specified either
implicitly by the nesting of the definitions or explicitly by "runs-inside")
and then you discover the resources as "instances" of those types.
Also if you rather think of types than the concrete instances, the problem of
the "wildcards" that Heiko is highlighting finds a comfortable place in the
design.
With that in mind, I think something along the lines of the following could
work:
- metric sets are basically equivalent to hawkular inventory resource types:
<resource-type name="my-metrics">
<path expr="/deployment=(.*)/subdeployment=(.*)"/>
<!-- groups in the path's expr -->
<resource-name>${path.1}-${path.2}</resource-name>
<metric name="active-sessions"
subpath="/subsystem=undertow"/>
<metric name="request-count"
subpath="/subsystem=undertow/servlet=App"/>
<metric name="blah"
path="/deployment=${path.1}/something-else"/>
<parents>your-metrics, his-metrics</parents>
</resource-type>
- managed resource sets are I think no longer needed
- managed servers reference resource types they want managed on the servers.
The resource type definition above basically combines the resource type def as
it existed in RHQ (of sorts) with a simple discovery by querying the
management model and matching it with the regular expr.
On Monday, April 20, 2015 15:56:32 John Mazzitelli wrote:
Well, after staring at things today, I am coming to the conclusion I
probably should re-arrange my agent configuration before I get too far
ahead. Need to know what people think.
The current hawkular monitor agent defines things like this - you define
your metric definitions and then you define where your servers are
(host/port) and what metrics to collect from those servers. A very small
agent config would be something like:
<metric-set-dmr name="my-metrics">
<metric-dmr name="my-threads"
resource="/core-service=platform-mbean/type=threading"
attribute="thread-count" </metric-set-dmr>
<managed-resources>
<remote-dmr name="my-server" host="myhost"
port="9990"
metricSets="my-metrics" /> </managed-resources>
But after looking at the kinds of metrics we want to collect, I think we
need to introduce some intermediate data - specifically, resource
hierarchy.
For example, if you look at Kettle (which has a pretty interesting and
non-trivial DMR hierarchy) there are things like this:
Alerts EAR (/deployment=hawkular-alerts-ear-1.0.ear)
\-- Alerts REST WAR
(/deployment=hawkular-alerts-ear-1.0.ear/subdeployment=hawkular-alerts-rest
.war/)
\-- Undertow Subsystem
(/deployment=hawkular-alerts-ear-1.0.ear/subdeployment=hawkular-alerts-rest
.war/subsystem=undertow/)
\-- METRIC: active-sessions
\-- METRIC: sessions-created
\-- Servlet
(/deployment=hawkular-alerts-ear-1.0.ear/subdeployment=hawkular-alerts-rest
.war/subsystem=undertow/servlet=org.hawkular.alerts.rest.HawkularAlertsApp/)
\-- METRIC: max-request-time
\-- METRIC: min-request-time
\-- METRIC: request-count
There's also EJB3 subdeployments under the EAR which have singleton-beans
that have execution-time and other invocation metrics.
So, clearly, I think there has to be something like managed entities in
between those endpoint servers and metrics in the agent configuration.
Essentially, we need to define resources in the config.
I was thinking of renaming "managed-resources" to "managed-servers"
and then
have "managed-resources" in between servers and metrics:
<metric-set-dmr name="my-undertow-metrics">
<metric-dmr name="Active Sessions" attribute="active-sessions"
/>
<!-- resource denotes a child resource under the resource that has this
metric defined --> <metric-dmr name="Servlet Requests"
resource="/subsystem=undertow/servlet=org.hawkular.alerts.rest.HawkularAler
tsApp" attribute="request-count" /> </metric-set-dmr>
<managed-resource-set-dmr = "Alerts Application">
<resource-dmr name"Alerts EAR"
path="/deployment=hawkular-alerts-ear-1.0.ear"
<resource-dmr name="Alerts WAR"
parent="Alerts EAR"
path="/subdeployment=hawkular-alerts-rest.war"
metricSets="my-metrics"/>
</managed-resource-set-dmr>
<managed-servers>
<remote-dmr name="my-server" host="myhost"
port="9990"
resourceSets="Alerts Application" /> </managed-servers>
One difference between this and RHQ is I don't define those low-low level
resources as separate resources (in RHQ I would have to define the undertow
subsystem as a child under the WAR and then a servlet under the undertow
resource). There is only the EAR and the WAR resource with the low level
metrics from undertow and the servlet being "assigned" or linked to the WAR
resouce.
So the Hawkular inventory hierachy would be this (compare with the Wildfly
hierarchy):
Alerts EAR
\-- Alerts WAR
\-- METRICS: Active Sessions (coming from undertow)
\-- METRICS: Servlet Requests (coming from the servlet inside
undertow) _______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev