What are the resources for these semi-dynamic metrics? Are they
somehow "added" to an existing type? Are they all consolidated under
some new, umbrella type? I'm not sure I get the intended model here.
What sort of meta-data other than the mbean name could be specified,
scheduling, etc.
On 2/15/2011 8:25 AM, Charles Crouch wrote:
----- Original Message -----
> On 2/14/11 10:46 AM, Charles Crouch wrote:
>> ----- Original Message -----
>>> Am 14.02.2011 um 14:33 schrieb Charles Crouch:
>>>
>>>> 1) Start off with a .txt file containing mbean names and attribute
>>>> values to be monitored
>>> There are two starting points imo:
>>>
>>> 1a) existing "binary" MBean that should be monitored
>>> 1b) new MBean to be written
>>>
>>>
>>>> 2) Generate an rhq-plugin.xml from the .txt file in 1). This would
>>>> extend the jmx plugin, and for basic monitoring require no java
>>>> code
>>>> in the plugin
>>> 2a) the .txt file could be partially created by connecting to the
>>> MBean server and reading the attributes and operations of the
>>> MBean.
>>> here the user needs to take the .txt file, and augment it with
>>> semantics
>>> 2b) use annotations from modules/helpers/pluginAnnotations and put
>>> them on the source so that the semantics are there. Then
>>> use a doclet in conjunction with the pluginGen to create a full
>>> plugin
>>> descriptor like Galder has done.
>>>
>> Good suggestions. There are lots of options for how to generate the
>> plugin descriptor.
>> Have you got a link to Galders work?
>>
>>>> 3) Package the rhq-plugin.xml from 2) into a plugin .jar file
>>>> 4) Deploy the plugin .jar from 3) into an RHQ server
>>>> 5) Tell the agents to go refresh their plugins
>>>> 6) Agents should now be collecting all the metrics mentioned in 1)
>>>>
>>>> In terms of automation I think all steps besides 4) should be
>>>> feasible right now? Regarding 4) I'm not seeing this in the remote
>>>> api. Any major reason it couldn't be added?
>>>>
>>> 4 can just be a (s)cp command to the plugin dropbox on the server.
>>>
>> I think thats a good work around for now, however this approach
>> doesn't have the best semantics, e.g. not synchronous, ugly edge
>> cases, in a multi server environment, jsanda can comment on
>> specifics. So ultimately I think having an api, similarly to the
>> bundle file creation apis that take a stream or a url would be
>> optimal.
>>
>>
> Not sure I completely understand the discussion, but there shouldn't
> be
> any problems with copying copying the plugin jar file to the plugin
> drop
> box in a multi-server environment. Let's say we have to servers A and
> B.
> Regardless of which server's plugin dropbox the plugin is copied to,
> the
> agent plugin scanner running on the server will detect the new plugin
> and add it to the database so that it can be handled by either server.
> When agents download plugins, they are always getting from the db. The
> possible problems I learned about in a multi-server environment
> involved
> my work with plugin deletion. We cannot delete the plugin row in the
> RHQ_PLUGINS table. If we did this on server A, it would know that the
> plugin has been deleted, but the agent plugin scanner on server B
> wouldn't know that. It would find the deleted plugin on its file
> system,
> not in the database, and would then proceed to reinstall it.
>
> I think the real issue is the lack of an api. There needs to be a
> mechanism to verify that the plugin has been updated on the server and
> I
> am not sure if we currently expose an api for that.
Right, I think its the plugin redeploy case that most needs a consistent api.
Using the drop directory is easy for initial install, but if you are making frequent
plugin updates, especially in a multi-server environment, I expect having an api would get
you much more consistent semantics.
> - John
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel