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:
- 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
- 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?
- Package the rhq-plugin.xml from 2) into a plugin .jar file
- Deploy the plugin .jar from 3) into an RHQ server
- Tell the agents to go refresh their plugins
- 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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel