Need advice about agent plugin design
by Steven North
I am trying to design an RHQ/JON agent plugin to manage a software
resource with the following characteristics:
- there is the software itself (the installation);
- there are a variable number of "bundles" of configuration information
about 250KB in size each which need to be read from and written to the
agent; and
- there are "log" files which can 10-50MB in size each which need to be
read from the agent.
I think I am pretty clear on how to handle the software itself--just
like any number of other agents.
I am not sure how to handle the configuration bundles and the large log
files.
We might want to have the RHQ/JON server manage different versions of
these configuration files and distribute them to multiple remote agents.
Is there some existing domain object that would handle the read/write
aspect of the configuration bundles (zip files)? Could the "package"
concept be used for these? Would we need to create a new domain object
on the server side for these bundles? If so, is there an example of
this kind of thing?
For the log files, I see some mention of the SupportFacet. Would this
be appropriate for retrieving large log files? Is there an example of this?
We expect to access the configuration bundles and the log files using
remote client operations because we have a separate GUI tool to
build/edit the configuration bundles and to correlate and analyze the
log files. Is there an example of using a remote client to pull files
from and push files to remote agents?
Thanks in advance for any advice you can give or examples you can point to.
Steve
10 years
Server side Event bus
by Heiko W.Rupp
Hi,
so the other day we were talking about agents forwarding some information out-of-band to the server
so that the messages can be shown in the message center.
We should perhaps pick that idea up and extend it in a way that the server can push
information into the UI without requiring the user to select a different tab or clicking some
refresh button.
There are many use cases for this:
- out-of band messages from agents to be shown in the message center : mark the message center button accordingly
- updating of the tree when a new child resource has been added
- updating of history pages when an entry has changed
- updating of metrics pages when new data was received
...
The general idea here is to make the UI more responsive in the sense that the
user gets actively informed and does not have to remember to manually check
here and there (and to remember to do it in case X while it is not needed in case Y).
While the above is a nice use case of Errai, I think we don't necessarily use it
for implementation; it could server as example on how to do it though.
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
11 years, 5 months
supporting proxies in front of RHQ
by Charles Crouch
Quick straw poll:
1) How many people are using http proxy server in front of RHQ?
2) How many people would benefit from using such a setup?
Thanks
Charles
11 years, 8 months
Maven modules dependency graph
by Jiri Kremser
Hi,
as mentioned during today's scrum call, I've added a dependency visualization plugin to the root pom.xml which is capable of creating dependency graph when running mvn site:site (it is part of the generated website, or directly accessible from target/site/images/overview.png). The mvn task responsible for generating this graph can be run also by typing "mvn com.googlecode.maven-overview-plugin:maven-overview-plugin:RELEASE:overview". I am not saying it is perfect, but it can help to get oriented for start.
JK
11 years, 8 months
[GSoC 2012, PyAgent] Changes in the configuration of PyAgent
by Krzysztof Kwaśniewski
Hi!
There are two ideas for future development of PyAgent in terms of
its configuration. I would like to ask you for your opinions on that.
The first idea is connected with reducing the flexibility that the
agent allows for now. The rationale for this is that it can be too
complicated for a regular user to get accustomed to all the
possibilities that the agent can provide. Many people won't like to
spend much time on learning how to configure the agent. Meanwhile much
of the functionality that the agent will provide won't be used in fact.
And also the easier the configuration, the less errors will be made.
Let's assume you just have one source server identified with an
URI, a name of its resource, an index for choosing one of the instances
of the resource (for instance the second CPU out of ten) and the
property of the resource (for a CPU - a clock rate, a load and so on).
Then you also have the same for the destination resource. You can
control an update interval for each mapping separately - it is an amount
of time between two consecutive queries for data at its source - when
reporting to RHQ, it is the one to decide on the update interval value.
Will you need a possibility of:
1) mapping one resource in the source server (CIM) to many destination
servers (RHQ)?
2) getting data from multiple source servers (CIM) with a single
instance of PyAgent?
3) sending gathered data to multiple destination servers (RHQ) with a
single instance of PyAgent?
4) easily adapting PyAgent to get data from another kind of source (not
CIM)?
5) easily adapting PyAgent to send data to another kind of destination
(not RHQ, for instance a file)?
6) configuring the update interval for each single measurement
separately? Generally RHQ is responsible for managing such an update
interval, but maybe not all the destination servers will be RHQ instances?
If you don't need some of those options, the configuration may be much
simpler than it is now.
The other idea is a completely different approach to the problem of
having too complicated configuration. For that I can prepare an
interactive generator that will ask a set of questions and then prepare
an xml file. My opinion is that it will be time-consuming and error
prone to prepare a configuration file this way, but maybe you like this
idea? If yes, what should I especially take into account when preparing
the generator? Do you have any advice for me?
Cheers
Krzysiek
11 years, 8 months
Include Python support in the CLI by default?
by Lukas Krejci
Hi everyone,
so now that we support Python as a CLI language, do you think it would be
worth including that support by default in the CLI? The jar is kinda hefty
10MBs because it embeds the whole jython but on the other hand it does bring a
whole new language to RHQ ;)
Or do you think it'd be better to add another section to RHQ's downloads
section in the UI to offer different language support modules that the users
could then install?
Or some other way?
11 years, 8 months