6:18 p.m.
Emanuel,
FYI I think this pretty much summarizes the various IRC etc discussions
today about metrics. Thoughts?
1) Metrics are represented in the model description at the same level as
"configuration" attributes.
2) Metrics are represented in a "read-resource" result the same as
configuration attributes.
3) Metrics are stored in a ModelNodeRegistration in the same map as
attributes
a) but they need to have a custom read handler registered, as the
default model-reading one won't work
4) Multi-server queries will not be done via the domain/host level
resources. This eliminates the "expense" issue of treating metrics
as attributes on a domain resource (expense due to need to read the
metrics across all servers in order to
generate the full result.) Instead, domain and host level resources will
not have metrics, and attributes will just return
the domain/host level value.
Instead, for multi-server results, wildcards and lists will be used:
e.g. host=*,server=*,subsystem=web,connector=http attribute=pool-size
e.g. host=[hostA,hostB],server=*,subsystem=web,connector=http
attribute=pool-size
e.g. server-group=group1,host=*,server=*,subsystem=web,connector=http
attribute=pool-size
e.g.
server-group=[group1,group2],host=*,server=*,subsystem=web,connector=http
attribute=pool-size
This needs thought as to how to implement; sounds nice conceptually.
5) The model description for an attribute will include two additional
pieces of metadata:
storage (alternative term -- applies-to): Either
configuration = Derived from and stored in the persistent configuration
(i.e. domain.xml/host.xml/standalone.xml).
runtime = Derived from and stored in runtime state only, and not in any
persistent configuration.
There's an ongoing debate over "storage" vs "applies-to".
access-type: One of
read-only = Not modifiable via a simple write-attribute operation. Value
will not change without some sort of management action.
read-write = Modifiable via a simple write-attribute operation. Value
will not change without some sort of management action.
metric = Value may change without any management action. Not directly
modifiable via a management action.
6) The value for said "storage" and "access-type" fields in the
attribute description will be generated by the
READ_RESOURCE_DESCRIPTION operation handler. It will not come from the
resource's DescriptionProvider (i.e. we
don't rely on developers correctly adding this metadata for each attribute.)
TBD:
1) "storage" vs "applies-to"
2) How to ensure the "storage" and "access-type" fields are correctly
set? Likely replace/overload ModelNodeRegistration's
void registerReadOnlyAttribute(String attributeName, OperationHandler
readHandler);
void registerReadWriteAttribute(String attributeName, OperationHandler
readHandler, OperationHandler writeHandler);
with
void registerReadOnlyAttribute(String attributeName, OperationHandler
readHandler, Storage storage);
void registerReadWriteAttribute(String attributeName, OperationHandler
readHandler, OperationHandler writeHandler, Storage storage);
void registerMetric(String attributeName, OperationHandler readHandler);
2) We briefly touched on the concept of a "runtime entity" aka a
"runtime resource". A resource that
only exists in the registry, but has no persistent representation in
domain.xml,
host.xml or standalone.xml.
a) Said runtime resource cannot have attributes with storage=configuration
b) We briefly mentioned having recursive model reads stop at runtime
resources, in order to avoid excessive cost.
3) If we have runtime resources, this status should probably be
reflected in the resource description.
And probably should be stored directly in the ModelNodeRegistration,
e.g. via
ModelNodeRegistration registerSubModel(PathElement address,
DescriptionProvider descriptionProvider, Storage storage);
4) Does storage/applies-to have a 3rd value: "both"? IOW does
"configuration" always imply "runtime"?
5) The "storage/applies-to" concept is relevant to operations in
general, not just reads/write of attributes.
6) We need to know whether execution of an operation (including
write-attribute) on a server puts that server
in a state where it requires a restart. If the operation will always
trigger a restart requirement, we use
the interface implemented by the handler for the operation to determine
this. Some operations may or may
not trigger a restart requirement; it depends on the value of the
parameters and the current state when
they are applied.
Clients are likely to want to know about the restart impact before
executing an operation (i.e. if it will/may/won't
trigger the need to restart). So this should be added to the
operation/attribute description.
7) Some operations can be applied to the runtime even if a previous
operation has triggered the requirement
for a restart is required. Some may always work, some may or may not
work depending on the params and
the runtime state. We currently have no mechanism for informing the
server controller of this kind of thing;
we just disable all runtime updates once restart is required. It would
be better to make this information
available to the server controller. Clients may want to know as well, so
this should be added to the
operation/attribute description.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
7:35 a.m.
On 01/26/2011 01:18 AM, Brian Stansberry wrote:
FYI I think this pretty much summarizes the various IRC etc
discussions
today about metrics. Thoughts?
1) Metrics are represented in the model description at the same level as
"configuration" attributes.
2) Metrics are represented in a "read-resource" result the same as
configuration attributes.
3) Metrics are stored in a ModelNodeRegistration in the same map as
attributes
a) but they need to have a custom read handler registered, as the
default model-reading one won't work
4) Multi-server queries will not be done via the domain/host level
resources. This eliminates the "expense" issue of treating metrics
as attributes on a domain resource (expense due to need to read the
metrics across all servers in order to
generate the full result.) Instead, domain and host level resources will
not have metrics, and attributes will just return
the domain/host level value.
This does seem to go a bit beyond metrics - In general it's the logical
configuration view vs. the actual runtime state of a domain. Where i'm
not sure it makes much sense trying to combine them into one single view
(well let's say one which can be retrieved with recursive=true).
First from a tooling perspective i don't think you want to have the
metrics from possibly 100 servers together with the configuration (where
you rather either pick one of them). Also if we allow system property
replacement for standalone the actual runtime state is again different
from the configuration. So having the runtime information as i.e. a
separate operation sounds more interesting to me. This should also make
the "cost" of the operation more obvious. Obviously we could create
some convenience operations which just get both.
Instead, for multi-server results, wildcards and lists will be used:
e.g. host=*,server=*,subsystem=web,connector=http attribute=pool-size
e.g. host=[hostA,hostB],server=*,subsystem=web,connector=http
attribute=pool-size
e.g. server-group=group1,host=*,server=*,subsystem=web,connector=http
attribute=pool-size
e.g.
server-group=[group1,group2],host=*,server=*,subsystem=web,connector=http
attribute=pool-size
This needs thought as to how to implement; sounds nice conceptually.
I do like the concept of using wildcards to query the domain model in
general - also for standalone, otherwise you would have to e.g. first
query the description to know which subsystems are present in order to
retrieve the model for them. Additionally a query mechanism based on
server-groups might be interesting as well.
5) The model description for an attribute will include two
additional
pieces of metadata:
storage (alternative term -- applies-to): Either
configuration = Derived from and stored in the persistent configuration
(i.e. domain.xml/host.xml/standalone.xml).
runtime = Derived from and stored in runtime state only, and not in any
persistent configuration.
There's an ongoing debate over "storage" vs "applies-to".
Well as said i'm not a big fan of having runtime state as an simple
attribute. Declaring it as part of the metadata makes sense though.
access-type: One of
read-only = Not modifiable via a simple write-attribute operation. Value
will not change without some sort of management action.
read-write = Modifiable via a simple write-attribute operation. Value
will not change without some sort of management action.
metric = Value may change without any management action. Not directly
modifiable via a management action.
Sounds good to me.
6) The value for said "storage" and "access-type"
fields in the
attribute description will be generated by the
READ_RESOURCE_DESCRIPTION operation handler. It will not come from the
resource's DescriptionProvider (i.e. we
don't rely on developers correctly adding this metadata for each
attribute.)
TBD:
1) "storage" vs "applies-to"
I don't like either of them, although "impact" might not be much better :)
2) How to ensure the "storage" and "access-type"
fields are correctly
set? Likely replace/overload ModelNodeRegistration's
void registerReadOnlyAttribute(String attributeName, OperationHandler
readHandler);
void registerReadWriteAttribute(String attributeName, OperationHandler
readHandler, OperationHandler writeHandler);
with
void registerReadOnlyAttribute(String attributeName, OperationHandler
readHandler, Storage storage);
void registerReadWriteAttribute(String attributeName, OperationHandler
readHandler, OperationHandler writeHandler, Storage storage);
void registerMetric(String attributeName, OperationHandler readHandler);
Having a metric handler per attribute-name / metric-name seems too much.
I'd rather have an optional attribute-name, so the metric handler can
either filter or just get one metric.
2) We briefly touched on the concept of a "runtime entity"
aka a
"runtime resource". A resource that
only exists in the registry, but has no persistent representation in
domain.xml,
host.xml or standalone.xml.
a) Said runtime resource cannot have attributes with storage=configuration
b) We briefly mentioned having recursive model reads stop at runtime
resources, in order to avoid excessive cost.
3) If we have runtime resources, this status should probably be
reflected in the resource description.
And probably should be stored directly in the ModelNodeRegistration,
e.g. via
ModelNodeRegistration registerSubModel(PathElement address,
DescriptionProvider descriptionProvider, Storage storage);
4) Does storage/applies-to have a 3rd value: "both"? IOW does
"configuration" always imply "runtime"?
A third one might be useful, like when you change a system property. It
can be applied to the runtime without requiring a restart. However it
will most likely only affect the runtime after a restart.
5) The "storage/applies-to" concept is relevant to
operations in
general, not just reads/write of attributes.
Yeah, i think operations should be able to declare their impact.
6) We need to know whether execution of an operation (including
write-attribute) on a server puts that server
in a state where it requires a restart. If the operation will always
trigger a restart requirement, we use
the interface implemented by the handler for the operation to determine
this. Some operations may or may
not trigger a restart requirement; it depends on the value of the
parameters and the current state when
they are applied.
Clients are likely to want to know about the restart impact before
executing an operation (i.e. if it will/may/won't
trigger the need to restart). So this should be added to the
operation/attribute description.
7) Some operations can be applied to the runtime even if a previous
operation has triggered the requirement
for a restart is required. Some may always work, some may or may not
work depending on the params and
the runtime state. We currently have no mechanism for informing the
server controller of this kind of thing;
we just disable all runtime updates once restart is required. It would
be better to make this information
available to the server controller. Clients may want to know as well, so
this should be added to the
operation/attribute description.
Yeah, additional metadata for this kind of information sounds reasonable
as well (applies to both).
8:19 a.m.
On 1/26/11 7:35 AM, Emanuel Muckenhuber wrote:
On 01/26/2011 01:18 AM, Brian Stansberry wrote:
> FYI I think this pretty much summarizes the various IRC etc discussions
> today about metrics. Thoughts?
>
> 1) Metrics are represented in the model description at the same level as
> "configuration" attributes.
>
> 2) Metrics are represented in a "read-resource" result the same as
> configuration attributes.
>
> 3) Metrics are stored in a ModelNodeRegistration in the same map as
> attributes
> a) but they need to have a custom read handler registered, as the
> default model-reading one won't work
>
> 4) Multi-server queries will not be done via the domain/host level
> resources. This eliminates the "expense" issue of treating metrics
> as attributes on a domain resource (expense due to need to read the
> metrics across all servers in order to
> generate the full result.) Instead, domain and host level resources will
> not have metrics, and attributes will just return
> the domain/host level value.
>
This does seem to go a bit beyond metrics - In general it's the logical
configuration view vs. the actual runtime state of a domain. Where i'm
not sure it makes much sense trying to combine them into one single view
(well let's say one which can be retrieved with recursive=true).
Yes, this is what lead to the idea below of "runtime resources" where a
recursive=true flag wouldn't traverse into the child resource.
Logically, at the DC level host=hostA is a "runtime resource" and at the
HC level server=server1 is a "runtime resource".
First from a tooling perspective i don't think you want to have
the
metrics from possibly 100 servers together with the configuration (where
you rather either pick one of them). Also if we allow system property
replacement for standalone the actual runtime state is again different
from the configuration. So having the runtime information as i.e. a
separate operation sounds more interesting to me. This should also make
the "cost" of the operation more obvious. Obviously we could create some
convenience operations which just get both.
So are you ok with 1) and 2) above, but don't want a read-resource call
to pull in metrics, unless perhaps a flag is set?
> Instead, for multi-server results, wildcards and lists will be
used:
> e.g. host=*,server=*,subsystem=web,connector=http attribute=pool-size
> e.g. host=[hostA,hostB],server=*,subsystem=web,connector=http
> attribute=pool-size
> e.g. server-group=group1,host=*,server=*,subsystem=web,connector=http
> attribute=pool-size
> e.g.
> server-group=[group1,group2],host=*,server=*,subsystem=web,connector=http
> attribute=pool-size
>
>
> This needs thought as to how to implement; sounds nice conceptually.
>
I do like the concept of using wildcards to query the domain model in
general - also for standalone, otherwise you would have to e.g. first
query the description to know which subsystems are present in order to
retrieve the model for them. Additionally a query mechanism based on
server-groups might be interesting as well.
See the 3rd and 4th e.g. above. :)
> 5) The model description for an attribute will include two
additional
> pieces of metadata:
>
> storage (alternative term -- applies-to): Either
> configuration = Derived from and stored in the persistent configuration
> (i.e. domain.xml/host.xml/standalone.xml).
> runtime = Derived from and stored in runtime state only, and not in any
> persistent configuration.
>
> There's an ongoing debate over "storage" vs "applies-to".
>
Well as said i'm not a big fan of having runtime state as an simple
attribute. Declaring it as part of the metadata makes sense though.
> access-type: One of
> read-only = Not modifiable via a simple write-attribute operation. Value
> will not change without some sort of management action.
> read-write = Modifiable via a simple write-attribute operation. Value
> will not change without some sort of management action.
> metric = Value may change without any management action. Not directly
> modifiable via a management action.
>
>
Sounds good to me.
> 6) The value for said "storage" and "access-type" fields in the
> attribute description will be generated by the
> READ_RESOURCE_DESCRIPTION operation handler. It will not come from the
> resource's DescriptionProvider (i.e. we
> don't rely on developers correctly adding this metadata for each
> attribute.)
>
> TBD:
>
> 1) "storage" vs "applies-to"
>
I don't like either of them, although "impact" might not be much better :)
> 2) How to ensure the "storage" and "access-type" fields are
correctly
> set? Likely replace/overload ModelNodeRegistration's
>
> void registerReadOnlyAttribute(String attributeName, OperationHandler
> readHandler);
> void registerReadWriteAttribute(String attributeName, OperationHandler
> readHandler, OperationHandler writeHandler);
>
> with
>
> void registerReadOnlyAttribute(String attributeName, OperationHandler
> readHandler, Storage storage);
> void registerReadWriteAttribute(String attributeName, OperationHandler
> readHandler, OperationHandler writeHandler, Storage storage);
> void registerMetric(String attributeName, OperationHandler readHandler);
>
Having a metric handler per attribute-name / metric-name seems too much.
I'd rather have an optional attribute-name, so the metric handler can
either filter or just get one metric.
A simple "void registerMetricHandler(OperationHandler handler)" doesn't
give the controller any information about what's a metric and what
isn't. The only way to find out is to invoke the DescriptionProvider for
the resource and read the metadata. And hope the dev did it right.
If it's important to just register a single handler per-resource, then
we'll need to register some sort of MetricHandler interface:
public interface MetricHandler {
Set<String> getHandledMetricNames();
Cancellable execute(NewOperationContext context, String metricName,
ResultHandler resultHandler);
}
> 2) We briefly touched on the concept of a "runtime
entity" aka a
> "runtime resource". A resource that
> only exists in the registry, but has no persistent representation in
> domain.xml,
> host.xml or standalone.xml.
> a) Said runtime resource cannot have attributes with
> storage=configuration
> b) We briefly mentioned having recursive model reads stop at runtime
> resources, in order to avoid excessive cost.
>
> 3) If we have runtime resources, this status should probably be
> reflected in the resource description.
> And probably should be stored directly in the ModelNodeRegistration,
> e.g. via
>
> ModelNodeRegistration registerSubModel(PathElement address,
> DescriptionProvider descriptionProvider, Storage storage);
>
> 4) Does storage/applies-to have a 3rd value: "both"? IOW does
> "configuration" always imply "runtime"?
>
A third one might be useful, like when you change a system property. It
can be applied to the runtime without requiring a restart. However it
will most likely only affect the runtime after a restart.
> 5) The "storage/applies-to" concept is relevant to operations in
> general, not just reads/write of attributes.
>
Yeah, i think operations should be able to declare their impact.
> 6) We need to know whether execution of an operation (including
> write-attribute) on a server puts that server
> in a state where it requires a restart. If the operation will always
> trigger a restart requirement, we use
> the interface implemented by the handler for the operation to determine
> this. Some operations may or may
> not trigger a restart requirement; it depends on the value of the
> parameters and the current state when
> they are applied.
>
> Clients are likely to want to know about the restart impact before
> executing an operation (i.e. if it will/may/won't
> trigger the need to restart). So this should be added to the
> operation/attribute description.
>
> 7) Some operations can be applied to the runtime even if a previous
> operation has triggered the requirement
> for a restart is required. Some may always work, some may or may not
> work depending on the params and
> the runtime state. We currently have no mechanism for informing the
> server controller of this kind of thing;
> we just disable all runtime updates once restart is required. It would
> be better to make this information
> available to the server controller. Clients may want to know as well, so
> this should be added to the
> operation/attribute description.
>
Yeah, additional metadata for this kind of information sounds reasonable
as well (applies to both).
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
9:18 a.m.
On 01/26/2011 03:19 PM, Brian Stansberry wrote:
On 1/26/11 7:35 AM, Emanuel Muckenhuber wrote:
> On 01/26/2011 01:18 AM, Brian Stansberry wrote:
>> FYI I think this pretty much summarizes the various IRC etc discussions
>> today about metrics. Thoughts?
>>
>> 1) Metrics are represented in the model description at the same level as
>> "configuration" attributes.
>>
>> 2) Metrics are represented in a "read-resource" result the same as
>> configuration attributes.
>>
>> 3) Metrics are stored in a ModelNodeRegistration in the same map as
>> attributes
>> a) but they need to have a custom read handler registered, as the
>> default model-reading one won't work
>>
>> 4) Multi-server queries will not be done via the domain/host level
>> resources. This eliminates the "expense" issue of treating metrics
>> as attributes on a domain resource (expense due to need to read the
>> metrics across all servers in order to
>> generate the full result.) Instead, domain and host level resources will
>> not have metrics, and attributes will just return
>> the domain/host level value.
>>
>
> This does seem to go a bit beyond metrics - In general it's the logical
> configuration view vs. the actual runtime state of a domain. Where i'm
> not sure it makes much sense trying to combine them into one single view
> (well let's say one which can be retrieved with recursive=true).
>
Yes, this is what lead to the idea below of "runtime resources" where a
recursive=true flag wouldn't traverse into the child resource.
Logically, at the DC level host=hostA is a "runtime resource" and at the
HC level server=server1 is a "runtime resource".
Ok, great.
> First from a tooling perspective i don't think you want to
have the
> metrics from possibly 100 servers together with the configuration (where
> you rather either pick one of them). Also if we allow system property
> replacement for standalone the actual runtime state is again different
> from the configuration. So having the runtime information as i.e. a
> separate operation sounds more interesting to me. This should also make
> the "cost" of the operation more obvious. Obviously we could create some
> convenience operations which just get both.
>
So are you ok with 1) and 2) above, but don't want a read-resource call
to pull in metrics, unless perhaps a flag is set?
I was more thinking of having them separate - at least i'd also like to
get the runtime state separate from the configuration. So i'm not sure
if they should be mixed with the configuration attributes at the same
level and 2 flags sounds a bit weird. Also if you have like
max-thread-pool-size=${max.thread.pool.size:10} - then you'd need a
separate attribute with actual-thread-max-pool-size?
>> 2) How to ensure the "storage" and
"access-type" fields are correctly
>> set? Likely replace/overload ModelNodeRegistration's
>>
>> void registerReadOnlyAttribute(String attributeName, OperationHandler
>> readHandler);
>> void registerReadWriteAttribute(String attributeName, OperationHandler
>> readHandler, OperationHandler writeHandler);
>>
>> with
>>
>> void registerReadOnlyAttribute(String attributeName, OperationHandler
>> readHandler, Storage storage);
>> void registerReadWriteAttribute(String attributeName, OperationHandler
>> readHandler, OperationHandler writeHandler, Storage storage);
>> void registerMetric(String attributeName, OperationHandler readHandler);
>>
>
> Having a metric handler per attribute-name / metric-name seems too much.
> I'd rather have an optional attribute-name, so the metric handler can
> either filter or just get one metric.
>
A simple "void registerMetricHandler(OperationHandler handler)" doesn't
give the controller any information about what's a metric and what
isn't. The only way to find out is to invoke the DescriptionProvider for
the resource and read the metadata. And hope the dev did it right.
Hmm, another reason why it would make sense to have them separate ;)
If it's important to just register a single handler per-resource,
then
we'll need to register some sort of MetricHandler interface:
public interface MetricHandler {
Set<String> getHandledMetricNames();
Cancellable execute(NewOperationContext context, String metricName,
ResultHandler resultHandler);
}
One thing which i think is interesting about having one metricHandler
per "runtime resource" is that you have to call execute only once to get
all the metrics rather than running execute N times for each name.
1:54 p.m.
On Jan 26, 2011, at 4:18 PM, Emanuel Muckenhuber wrote:
> If it's important to just register a single handler
per-resource, then
> we'll need to register some sort of MetricHandler interface:
>
> public interface MetricHandler {
>
> Set<String> getHandledMetricNames();
>
> Cancellable execute(NewOperationContext context, String metricName,
> ResultHandler resultHandler);
>
> }
One thing which i think is interesting about having one metricHandler
per "runtime resource" is that you have to call execute only once to get
all the metrics rather than running execute N times for each name.
IMO the separation makes sense. For use cases that don't require metrics,
that data should not be send over the wire. I would prefer a custom operation opposed to
another operation attribute switch, like "includeMetrics=false".
On the API level this separation highlights that metrics run under different performance
considerations
and different semantics apply in general. It should not be intermingled with config data.
Anything we build atop of that (caching, aggregation, etc) would clearly benefit from a
distinction build into the API
right from the beginning.
But to make sure I understand you correctly:
- Does this means you have a custom operation to retrieve the metrics per resource?
(probably yes)
- Could metrics also be retrieved when reading the configuration?
I.e. separate payload element, but still one request?
- Although there is one handler per resource, will it be possible to retrieve just a
single metric value?
Ike
2:02 p.m.
On Jan 27, 2011, at 8:54 PM, Heiko Braun wrote:
On the API level this separation highlights that metrics run under
different performance considerations
and different semantics apply in general. It should not be intermingled with config
data.
Anything we build atop of that (caching, aggregation, etc) would clearly benefit from a
distinction build into the API
right from the beginning.
Another thing that just came to my mind, with regard to semantics:
Will metrics be 'pulled' from a subsystem component with every request,
or is a subsystem component forced to 'push' state changes to domain runtime
state?
The later would force the domain store these values redundantly (and stale)
whereas the 'pull' semantic would more work like a snapshot of the state the each
subsystem manages on it's own.
IMO this further justifies a separation of those two aspects.
Ike
6:21 a.m.
On 01/27/2011 09:02 PM, Heiko Braun wrote:
On Jan 27, 2011, at 8:54 PM, Heiko Braun wrote:
> On the API level this separation highlights that metrics run under different
performance considerations
> and different semantics apply in general. It should not be intermingled with config
data.
> Anything we build atop of that (caching, aggregation, etc) would clearly benefit from
a distinction build into the API
> right from the beginning.
Another thing that just came to my mind, with regard to semantics:
Will metrics be 'pulled' from a subsystem component with every request,
or is a subsystem component forced to 'push' state changes to domain runtime
state?
The later would force the domain store these values redundantly (and stale)
whereas the 'pull' semantic would more work like a snapshot of the state the each
subsystem manages on it's own.
Yeah, we are thinking of pushing metric values in future, but for now
metrics have to be pulled.
2:32 a.m.
Am 27.01.2011 um 20:54 schrieb Heiko Braun:
- Could metrics also be retrieved when reading the configuration?
I.e. separate payload element, but still one request?
RHQ will in any case pull a lot more metrics than it will pull configuration.
I.e. metrics are always pulled at regular intervals, while configuration is
pulled when the user wants to access it.
- Although there is one handler per resource, will it be possible to
retrieve just a single metric value?
It has to for RHQ, as otherwise we would pull a lot more data than what it needed.
I think we should also in a relatively early stage do a load test with e.g. 50 AS
instances
in a domain and pulling metrics for all of them at once every e.g. 10 seconds.
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
6:15 a.m.
On 01/27/2011 08:54 PM, Heiko Braun wrote:
But to make sure I understand you correctly:
- Does this means you have a custom operation to retrieve the metrics per resource?
(probably yes)
- Could metrics also be retrieved when reading the configuration?
I.e. separate payload element, but still one request?
We are trying to have a single view of the resource containing
configuration and runtime attributes. So in the end you have a parameter
in case runtime attributes (incl. metrics) should be queried as well.
This is more for the standalone view though. The runtime view in the
domain would be a separate operation - also because the returned value
will contain the result of each server.
- Although there is one handler per resource, will it be possible to
retrieve just a single metric value?
Yes, there are general read-attribute operations which also cover metrics.
6:30 a.m.
Am 31.01.2011 um 13:15 schrieb Emanuel Muckenhuber:
configuration and runtime attributes. So in the end you have a
parameter
in case runtime attributes (incl. metrics) should be queried as well.
Please don't make this "in addition" -- metrics will from RHQ be queried
magnitudes
more often.
This is more for the standalone view though. The runtime view in the
domain would be a separate operation - also because the returned value
will contain the result of each server.
The above applies to standalone hosts and domains that are managed/monitored
by RHQ.
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
6:57 a.m.
On 01/31/2011 01:30 PM, Heiko W.Rupp wrote:
Am 31.01.2011 um 13:15 schrieb Emanuel Muckenhuber:
> configuration and runtime attributes. So in the end you have a parameter
> in case runtime attributes (incl. metrics) should be queried as well.
Please don't make this "in addition" -- metrics will from RHQ be queried
magnitudes
more often.
Hmm, so if i understand you correctly - you are asking for an operation
which includes all runtime attributes / metrics for a resource, not the
configuration values?
7:04 a.m.
Am 31.01.2011 um 13:57 schrieb Emanuel Muckenhuber:
On 01/31/2011 01:30 PM, Heiko W.Rupp wrote:
> Please don't make this "in addition" -- metrics will from RHQ be
queried magnitudes
> more often.
>
Hmm, so if i understand you correctly - you are asking for an operation which includes
all runtime attributes / metrics for a resource, not the configuration values?
s/all/only/ :-)
But yes, this is what I am asking.
Metrics will be gathered every 30sec to 20min depending on what metric and what the user
needs
(actually users would like to see even much shorter intervals).
Always sending whole configuration too puts a lot more stress on the AS, the HC/DC , the
network
etc.
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
7:16 a.m.
On 01/31/2011 02:04 PM, Heiko W.Rupp wrote:
Am 31.01.2011 um 13:57 schrieb Emanuel Muckenhuber:
> On 01/31/2011 01:30 PM, Heiko W.Rupp wrote:
>> Please don't make this "in addition" -- metrics will from RHQ be
queried magnitudes
>> more often.
>>
>
> Hmm, so if i understand you correctly - you are asking for an operation which
includes all runtime attributes / metrics for a resource, not the configuration values?
s/all/only/ :-)
But yes, this is what I am asking.
Metrics will be gathered every 30sec to 20min depending on what metric and what the user
needs
(actually users would like to see even much shorter intervals).
Always sending whole configuration too puts a lot more stress on the AS, the HC/DC , the
network
etc.
Ok, maybe i should have explained better - Currently we have an
operation which returns the configuration of a resource and can
optionally contain metrics (this might be more useful to other clients
than RHQ). Additionally we have a single read attribute operation -
which can be used to retrieve a single metric value.
We can certainly add a 'query-metrics' operation which will only return
the metrics for a given resource. Additionally you will have the option
to do a 'composite operation' of multiple single read attribute queries
you are interested in.
7:27 a.m.
What's the defining feature between configuration info & (runtime) metrics?
On 31/01/2011 15:16, Emanuel Muckenhuber wrote:
On 01/31/2011 02:04 PM, Heiko W.Rupp wrote:
>
> Am 31.01.2011 um 13:57 schrieb Emanuel Muckenhuber:
>> On 01/31/2011 01:30 PM, Heiko W.Rupp wrote:
>>> Please don't make this "in addition" -- metrics will from RHQ
be queried magnitudes
>>> more often.
>>>
>>
>> Hmm, so if i understand you correctly - you are asking for an operation which
includes all runtime attributes / metrics for a resource, not the configuration values?
>
> s/all/only/ :-)
> But yes, this is what I am asking.
> Metrics will be gathered every 30sec to 20min depending on what metric and what the
user needs
> (actually users would like to see even much shorter intervals).
> Always sending whole configuration too puts a lot more stress on the AS, the HC/DC ,
the network
> etc.
Ok, maybe i should have explained better - Currently we have an
operation which returns the configuration of a resource and can
optionally contain metrics (this might be more useful to other clients
than RHQ). Additionally we have a single read attribute operation -
which can be used to retrieve a single metric value.
We can certainly add a 'query-metrics' operation which will only return
the metrics for a given resource. Additionally you will have the option
to do a 'composite operation' of multiple single read attribute queries
you are interested in.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
Software Engineering Manager
JBoss Application Server
by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
http://dandreadis.blogspot.com/
7:37 a.m.
What if I have a transient writable field, e.g. enable-metrics, that is not part of the
configuration info and I am not interested in persisting?
Also, can a subsystem update it's configuration without external intervention, e.g., I
haven't specified a certain field, or it's set wrong and the subsystem falls back
to some
default.
On 31/01/2011 15:29, Kabir Khan wrote:
On 31 Jan 2011, at 13:27, Dimitris Andreadis wrote:
> What's the defining feature between configuration info&
max-pool-count
> (runtime) metrics?
current-pool-count
7:48 a.m.
On 31 Jan 2011, at 13:37, Dimitris Andreadis wrote:
What if I have a transient writable field, e.g. enable-metrics, that
is not part of the
configuration info and I am not interested in persisting?
I don't really
understand what you mean here? The operation handlers will only look for known attributes
and deal with those
Also, can a subsystem update it's configuration without external intervention, e.g.,
I
haven't specified a certain field, or it's set wrong and the subsystem falls back
to some
default.
Yes that shoiuld/would be handled by the subsystem add handler
On 31/01/2011 15:29, Kabir Khan wrote:
> On 31 Jan 2011, at 13:27, Dimitris Andreadis wrote:
>
>> What's the defining feature between configuration info&
> max-pool-count
>
>> (runtime) metrics?
> current-pool-count
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
7:54 a.m.
On 01/31/2011 02:37 PM, Dimitris Andreadis wrote:
What if I have a transient writable field, e.g. enable-metrics, that
is not part of the
configuration info and I am not interested in persisting?
You can have runtime attribute handlers - which interact with services
directly but don't affect the state of the domain model itself.
Also, can a subsystem update it's configuration without external
intervention, e.g., I
haven't specified a certain field, or it's set wrong and the subsystem falls back
to some
default.
The operation handlers registered by each subsystem would be responsible
for validation and proper handling in case you define a wrong value.
"default values" wouldn't be present in the configuration model itself,
since we don't want them to get persisted. However they should be part
of the metadata description of the model.
On 31/01/2011 15:29, Kabir Khan wrote:
> On 31 Jan 2011, at 13:27, Dimitris Andreadis wrote:
>
>> What's the defining feature between configuration info&
> max-pool-count
>
>> (runtime) metrics?
> current-pool-count
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
7:58 a.m.
Makes sense, thanks.
On 31/01/2011 15:54, Emanuel Muckenhuber wrote:
On 01/31/2011 02:37 PM, Dimitris Andreadis wrote:
> What if I have a transient writable field, e.g. enable-metrics, that is not part of
the
> configuration info and I am not interested in persisting?
>
You can have runtime attribute handlers - which interact with services
directly but don't affect the state of the domain model itself.
> Also, can a subsystem update it's configuration without external intervention,
e.g., I
> haven't specified a certain field, or it's set wrong and the subsystem falls
back to some
> default.
>
The operation handlers registered by each subsystem would be responsible
for validation and proper handling in case you define a wrong value.
"default values" wouldn't be present in the configuration model itself,
since we don't want them to get persisted. However they should be part
of the metadata description of the model.
> On 31/01/2011 15:29, Kabir Khan wrote:
>> On 31 Jan 2011, at 13:27, Dimitris Andreadis wrote:
>>
>>> What's the defining feature between configuration info&
>> max-pool-count
>>
>>> (runtime) metrics?
>> current-pool-count
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
Software Engineering Manager
JBoss Application Server
by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
http://dandreadis.blogspot.com/
7:33 a.m.
On Jan 31, 2011, at 2:27 PM, Dimitris Andreadis wrote:
What's the defining feature between configuration info &
(runtime) metrics?
metrics are maintained by each subsystem.
whereas the configuration is maintained by the domain (controller)
the later is changed infrequently, but metrics are subject to change
in very short intervals.
which is why I think we should treat them separately.
Ike
9:30 a.m.
Am 31.01.2011 um 14:16 schrieb Emanuel Muckenhuber:
Ok, maybe i should have explained better - Currently we have an
operation which returns the configuration of a resource and can optionally contain metrics
(this might be more useful to other clients than RHQ). Additionally we have a single read
attribute operation - which can be used to retrieve a single metric value.
So one metric of one resource?
We can certainly add a 'query-metrics' operation which will
only return the metrics for a given resource. Additionally you will have the option to do
a
This query-metics would then return all metrics of a single resource
'composite operation' of multiple single read attribute
queries you are interested in.
Or in this case of all respective instances of that resource throughout the domain.
But with the query-metrics operation, I think things look good.
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
9:03 p.m.
I thought I'd sent this a couple days ago, but apparently not. :(
On 1/27/11 1:54 PM, Heiko Braun wrote:
On Jan 26, 2011, at 4:18 PM, Emanuel Muckenhuber wrote:
>> If it's important to just register a single handler per-resource, then
>> we'll need to register some sort of MetricHandler interface:
>>
>> public interface MetricHandler {
>>
>> Set<String> getHandledMetricNames();
>>
>> Cancellable execute(NewOperationContext context, String metricName,
>> ResultHandler resultHandler);
>>
>> }
>
> One thing which i think is interesting about having one metricHandler
> per "runtime resource" is that you have to call execute only once to get
> all the metrics rather than running execute N times for each name.
IMO the separation makes sense. For use cases that don't require metrics,
that data should not be send over the wire. I would prefer a custom operation opposed to
another operation attribute switch, like "includeMetrics=false".
Why?
We were going with a "include-runtime" flag on the read-resource
operation, with a default of "false". Do you see a case where people
want to query all the metrics for a resource but not the configuration
values? I'd think the norm would be just show me the configuration data,
with runtime information retrieved individually.
On the API level this separation highlights that metrics run under
different performance considerations
and different semantics apply in general. It should not be intermingled with config
data.
Anything we build atop of that (caching, aggregation, etc) would clearly benefit from a
distinction build into the API
right from the beginning.
But to make sure I understand you correctly:
- Does this means you have a custom operation to retrieve the metrics per resource?
(probably yes)
No; but we could consider one if retrieving all non-configuration values
for a resource is an expected use-case.
Jason, would this cause a problem for how you are mapping requests to
the HTTP interface?
- Could metrics also be retrieved when reading the configuration?
I.e. separate payload element, but still one request?
Yes and no. Yes the metrics can be retrieved along with configuration,
via read-resource with include-runtime=true. But no, they don't come as
a separate payload element
Right now the actual model data that comes from a read-resource has a
flat structure, with no intermediate level to group certain "types" of
data. So, if the resource has a configuration attribute max-size, a
metric current-size, and a child resource of type "foo" the data would
conceptually look like:
+
++ max-size=10
++ current-size=5
++ foo
++++ foo-1
++++++ bar="XYZ"
and not:
+
++ attributes
++++ max-size=10
++++ current-size=5
++ children
++++ foo
++++++ foo-1
++++++++ bar="XYZ"
Basically this assumes that the read-resource-description data would be
used to differentiate the types of data, if necessary. Let me know if
this is a problem.
- Although there is one handler per resource, will it be possible to
retrieve just a single metric value?
Yes, any attribute (whether configuration or metric) can be read
individually. Now it's a simple read-attribute name="xxx".
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
9:23 p.m.
On 2/1/11 9:03 PM, Brian Stansberry wrote:
> - Does this means you have a custom operation to retrieve the
metrics per resource?
> (probably yes)
>
No; but we could consider one if retrieving all non-configuration values
for a resource is an expected use-case.
Jason, would this cause a problem for how you are mapping requests to
the HTTP interface?
No I would just add a query param like ?runtime-only or something.
--
Jason T. Greene
JBoss, a division of Red Hat
2:17 a.m.
Am 02.02.2011 um 04:03 schrieb Brian Stansberry:
We were going with a "include-runtime" flag on the
read-resource
operation, with a default of "false". Do you see a case where people
want to query all the metrics for a resource but not the configuration
values? I'd think the norm would be just show me the configuration data,
with runtime information retrieved individually.
I guess this now depends on the definition of "individually".
If a resource has e.g. 20 metrics, I would like to be able to
retrieve them all in one batch and not call the domain controller
20 times.
RHQ will much more often query metrics (runtime values) than
configuration values.
I am also not sure how much sense it makes to pile up a request for the
metrics individually to be returned in one go
Request.getResource(xyz).getMetric("a"
.getMetric("b")
....
.getMetirc("x")
This is good when someone only wants one or two metrics, but not for 20 of them.
Here some
Request.getResource(xyz).getMetrics();
call would be probably better.
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
4:12 a.m.
Please see my comments inline.
On Feb 2, 2011, at 4:03 AM, Brian Stansberry wrote:
>
> IMO the separation makes sense. For use cases that don't require metrics,
> that data should not be send over the wire. I would prefer a custom operation opposed
to
> another operation attribute switch, like "includeMetrics=false".
>
Why?
We were going with a "include-runtime" flag on the read-resource operation,
with a default of "false". Do you see a case where people want to query all the
metrics for a resource but not the configuration values? I'd think the norm would be
just show me the configuration data, with runtime information retrieved individually.
Yes, I can see that case: RHQ. Furthermore I believe, that metrics follow different rules
then the domain configuration data.
They will be requested more frequently and are subject to be maintained by each subsystem,
not the domain controller.
It the subsystem that updates the metrics, but the domain controller that modifies the
configuration.
This also means that metrics will easily cause thread synchronization/locking issues when
being requested from an external component (external to the subsystem). In a previous
email I tried to get to this point, when asking about "pull vs. push" of runtime
data.
Does that make sense?
> On the API level this separation highlights that metrics run under different
performance considerations
> and different semantics apply in general. It should not be intermingled with config
data.
> Anything we build atop of that (caching, aggregation, etc) would clearly benefit from
a distinction build into the API
> right from the beginning.
>
> But to make sure I understand you correctly:
>
> - Does this means you have a custom operation to retrieve the metrics per resource?
> (probably yes)
>
No; but we could consider one if retrieving all non-configuration values for a resource
is an expected use-case.
Jason, would this cause a problem for how you are mapping requests to the HTTP
interface?
> - Could metrics also be retrieved when reading the configuration?
> I.e. separate payload element, but still one request?
>
Yes and no. Yes the metrics can be retrieved along with configuration, via read-resource
with include-runtime=true. But no, they don't come as a separate payload element
How do we identify metrics in this case?
6:39 a.m.
On 02/03/2011 11:12 AM, Heiko Braun wrote:
On Feb 2, 2011, at 4:03 AM, Brian Stansberry wrote:
>
> We were going with a "include-runtime" flag on the read-resource operation,
with a default of "false". Do you see a case where people want to query all the
metrics for a resource but not the configuration values? I'd think the norm would be
just show me the configuration data, with runtime information retrieved individually.
Yes, I can see that case: RHQ. Furthermore I believe, that metrics follow different rules
then the domain configuration data.
They will be requested more frequently and are subject to be maintained by each
subsystem, not the domain controller.
It the subsystem that updates the metrics, but the domain controller that modifies the
configuration.
This also means that metrics will easily cause thread synchronization/locking issues when
being requested from an external component (external to the subsystem). In a previous
email I tried to get to this point, when asking about "pull vs. push" of runtime
data.
Does that make sense?
In the end you would have three ways (operations) to retrieve a metric:
1) "read-resource" with "include-runtime=true"
- this gives you the the configuration incl. metrics
2) "read-attribute"
- reads a single attribute value
3) "query-metrics" (TBD)
- retrieves the metrics only for a resource
In the domain case you would need to use a operation address like:
host=*,server*,subsystem=web,connector=web - to actually query the
runtime state.
The reason why metrics look more like an attribute is that a potential
JMX mapping would be easier. However they have to explicitly register
handlers to retrieve the value and therefore not part of the
configuration model - the operations just provide an aggregated view.
For now the metrics have to pulled, we are thinking of a push model for
the future.
>
>
>> - Could metrics also be retrieved when reading the configuration?
>> I.e. separate payload element, but still one request?
>>
>
> Yes and no. Yes the metrics can be retrieved along with configuration, via
read-resource with include-runtime=true. But no, they don't come as a separate payload
element
>
How do we identify metrics in this case?
The "type" of an attribute is part of the model description.
7:52 a.m.
Am 26.01.2011 um 14:35 schrieb Emanuel Muckenhuber:
>
This does seem to go a bit beyond metrics - In general it's the logical
configuration view vs. the actual runtime state of a domain. Where i'm
not sure it makes much sense trying to combine them into one single view
(well let's say one which can be retrieved with recursive=true).
First from a tooling perspective i don't think you want to have the
metrics from possibly 100 servers together with the configuration (where
you rather either pick one of them). Also if we allow system property
replacement for standalone the actual runtime state is again different
I guess this is also a question of scaling.
RHQ for example may come in and request metrics every few seconds (*) while
configuration changes / updates / reads are a lot less frequent. So the load on the
DC and HCs will probably increase with the number of items processed.
So a separation between runtime state and configuration may make sense for
processing (not for metadata).
Heiko
*) Actually the user can give for each metric a different interval, so that there will be
many
single item reads
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
5046
days inactive
5054
days old
26 comments
7 participants
participants (7)
-
Brian Stansberry -
Dimitris Andreadis -
Emanuel Muckenhuber -
Heiko Braun -
Heiko W.Rupp -
Jason T. Greene -
Kabir Khan