2:56 p.m.
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.HawkularAlertsApp"
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)