1 of 1 people found this helpful
from the RHQ plugin descriptor XML schema rhq-plugin.xsd:
<xs:attribute name="defaultOn" type="xs:boolean" default="false">
If true, this metric will get collected as soon as possible.
If false, a user must explicitly tell the plugin to collect this metric.
This is only used for metrics with a displayType of "detail". All
"summary" metrics are enabled by default, regardless of this value.
this is an attribute on the <metric> element.
Thanks for the tip. It is really simplest one.
But I think, This will not help to my use-case. Because, based on the discoveredResource, I have to disable the metric. For this case, Is there any idea to make it possible ? ? ?
Then are you sure it makes sense that you use the same resource type for the components you want to monitor?
Why not create different resource types?
I am pretty sure. We need a same resource Type.
My Use-Case :
Have to Monitor our records in the database for different datasources. Monitoring in the sense, has to collect the live data (Records or tuple) from our database (we are collecting specific values, coz we also concerned about performance). And moreover, Collecting different data( consider services eg: email service, webservice ) from each datasources. These data is our metrics.
Our Implementation :
Datasources are our resources. All the datasources has to be in one resourceType(That would make sense, and will help our team to monitor the data). I hope you have understood, my use-case.
All Datasources(Resources) having their own metrics. Which is unwanted for other datasource. What can I do it now ? ? ?
I'm not sure there is anything you can do that will be exactly what you want. You have to work with the constraint that metrics are pre-defined for a resource type. If you want a single resource type you have to work with the same set of metrics for each resource of the type.
In this fashion you have two choices.
1) Define all of the metrics that could possibly be collected and populate only the one that is relevant for a particular resource instance of the type. This will leave a lot of metrics with empty/meaningless data but at least the one relevant metric will be defined for each resource.
2) Define a "generic" metric, like "Data Value" that collects all of the data for the resource, and and maybe another *trait* metric like "Data Type", that is set once and maybe describes the type of data being collected. or something that can describe what this resource is actually collecting. Perhaps the resource name, or some other plugin configuration will be sufficient to describe what the resource is actually collecting. Basically, your stuffing values into a single, generic metric and determining what those values represent in some way *other than the metric name*.
What about having different resource types which would declare the same discovery class and resource component?
Thanks for your two awesome choices.
Choice 2 : I understand your point, But It will make me to think big and of course Still I dont have enough knowledge to do that. So I am not going for this choice.
I will go with choice 1. Because, That is easy to implement. If I have disable the metric what will happen exactly in the background. Could you please explain me ? ? ?
Yeah, That is also a awesome idea.
But My end user wants the following hierarchy. This is our mandatory Objective/Requirement which i have must follow. That is why I am thinking again and again.
---------------- Datasource 2
If you disable a metric it just means that it will not get collected at all. Perhaps you can create Group Definitions that generate dyna-groups for your resources such that you can disable metrics group-wise, as makes sense.
Thanks for the idea. I will follow this too.
I have seen a setEnabled() and isEnabled() methods in the MeasurementScheduleRequest class. I have tried to enable or disable the metric via those methods. But I have failed.
May I know the class( or If its methods i will be thanksful) by which you guys are enabling and disabling the metrics in RHQ. Why Cant I do in the plugin code. If You have provided a setEnabled and isEnabled methods in Measurement Facet Interface, that would be helpful for us to customize a plugin according to our needs.
1 of 1 people found this helpful
You can *not* enable/disable metrics for a resource from the plugin's facet code. The plugin only sets the *initial state* of the metric, either defaultOn=true or defaultOn=false, at the resource type level. It is false by default unless it is a summary metric, in which case it is true.
In other words, plugins can *not* affect metric enable/disable for individual resources. Having said that, it is possible, I think, for the getValues() impl to ignore requests for metrics if it so chooses. I'm fairly sure you could do this without generating errors. Having said THAT, I'm not sure it is a big issue to report some unnecessary metrics...
By design it is the user that decides what to collect. Which means only client interaction: GUI, CLI, etc, can enable/disable metrics. For what it's worth, in the API you would use the MeasurementScheduleManager.enableSchedulesForXXX() and MeasurementScheduleManager.disableSchedulesForXXX() methods. A CLI script that running on a schedule may be your best bet for actually affecting individual resources.
An idea for a possible enhancement, that you could create a bugzilla entry for, may be for RHQ to support script execution in response to certain lirfecycle events on resources (based on type). For example, execute a script on:
Note, we already have this ability on alerts.
Thank you so much for the detailed explanation. Please forgive me for the foolish way of asking questions. Now I have understood why you guys have not specified it. I will made it by GUI interaction itself.