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)
2:37 a.m.
Le 20/04/2015 21:56, John Mazzitelli a écrit :
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)
It surely makes sense when the sub-resource is unique, but in this case
precisely, there could be more than one servlet, correct? We may want to
distinguish the metrics for each end point.
3:10 a.m.
On 20 Apr 2015, at 21:56, John Mazzitelli wrote:
But after looking at the kinds of metrics we want to collect, I think
we need to introduce some intermediate data - specifically, resource
hierarchy.
Yes. Didn't we talk about that on the meeting with Lukas last week?
<metric-dmr name="Servlet Requests"
resource="/subsystem=undertow/servlet=org.hawkular.alerts.rest.HawkularAlertsApp"
attribute="request-count" />
</metric-set-dmr>
We need wildcard support here
resource="/subsystem=undertow/servlet=*" as we could have more
than one servlet per app
<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"
Same here as the outer EAR may have many WARs inside.
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)
Makes certainly sense to gather them in one place if they logically
belong together as you show them. This is certainly an issue in RHQ
right now.
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
3538
days inactive
3539
days old
3 comments
4 participants
participants (4)
-
Heiko W.Rupp -
John Mazzitelli -
Lukas Krejci -
Thomas Segismont