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, 2 months
MeasurementUnits (EPOCH_MILLISECONDS, EPOCH_SECONDS)
by Jiri Kremser
Hi,
in plugin descriptor, there can be a metric definition with unit type "epoch_milliseconds" or "epoch_seconds" (rhq-configuration.xsd allows it). What kind of metric should could be represented by epoch_milliseconds? Shouldn't the exact time moments (what values epoch_milliseconds represent) be addressed rather by traits?
I am asking because the values of this type are not formatted (https://bugzilla.redhat.com/show_bug.cgi?id=857144).
I think these two unit types should be removed from MeasurementUnits and xml schema, however there might be some plugins out there using it, so what about deprecation? Are there any edge cases, when these unit types do make sense?
JK
10 years, 2 months
RHQ usage of SEAM and AS7 integration
by John Mazzitelli
OK, after looking at this, it appears the first major stumbling block for the AS7 work is our usage of SEAM and how we can run in AS7.
Here's the issue - it appears we are using an older version of SEAM that does not work on AS7. We simply can't use the SEAM we were using. This is not surprising at all (see example threads of similar issues we have or will have: https://community.jboss.org/message/608573#608573 - https://community.jboss.org/blogs/marek-novotny/2011/12/16/dvdstore-migra... ).
What I think we need to consider is one of the following:
a) rip out SEAM entirely and all code in RHQ using it/depending on it (this includes mainly core/gui and enterprise/gui/portal-war modules but also this content_http thing that i dont think we need/should have/is used)
or
b) refactor our GUI code (portal war) to either not use SEAM or to make use of a newer SEAM that can be deployed inside of AS7
Now - if we do b) it means there will be a lot of effort wasted for very little gain. Most of portal-war isn't even used anymore - our GWT UI handles the vast majority of UI features now. So if we do b) its merely work that isn't even going to be used - it will be just so we can successfully deploy the RHQ ear only to later rip out portal war at some point anyway. Now, I can't say how much effort it will take to do b), but clearly, the new SEAM isn't backward compatible with the old - I'm seeing missing classes and things like that at startup. We'd have to integrate with the latest SEAM libraries and all that would entail (e.g. refactoring code perhaps)
But we can't blindly do a) either - all of portal-war is not obsolete - there still are small portions still used (graphing and the content UI are the two main areas that I know still use portal-war - there is also that old content_http servlet thing). Graphing pages, IIRC, are actually still on the old struts stuff - so I'm not even sure if JSF is even used, let alone SEAM. We'd have to investigate that. The content UI I think does use code that relies on SEAM. So ripping out portal-war isn't going to be like ripping off a band-aid - it will still require some delicate maneuvering.
The third option I would like to discuss is porting the rest of portal-war to GWT. Rather than waste time doing b), I think we can take that time and do more useful things that have to get done anyway - that is, port over the final pages in portal war to GWT. Thus, when we do that, I think we can do a) more quickly and without worrying about doing too much damage. The only thing that I think we'd have to look out for are simple things like StartupServlet (which we can easily port into a startup servlet in the GWT app or make a singleton EJB, which is new in EJB 3.1 and is now supported because we'd be on AS7)
Thoughts?
11 years, 5 months
RHQ/JON Chart Types Decision -- Input needed
by mike thompson
Visualizing RHQ Metrics Data
On the issue of chart types... More specifically, how do we want visually depict our metric data?
We are nearing the end of implementing the RHQ chart replacement (using http://d3js.org) and want to get our chart types dialed in with input from our community before they are completely finished.
This isn’t a new issue, here is a link to previous design discussion: https://docs.jboss.org/author/display/RHQ/Design-NewChartingLib
Future Chart Types under consideration:
1) Line/Area chart - shows progression over time, needs to be supplemented with high/low and OOB data (but all these lines become an area graph and easy visual deciphering is lost)
2) Bar chart - familiar, easy to understand, needs high/low and OOB to convey complete information, not entirely accurate as lower bar near axis depicts values that were never part of the metric range
3) Candlesticks - accurately shows the range but not when values trended or fluctuated during that time slice; users might need training to understand. OOB data would need to be supplemented with high/low peak OOB data
4) Box Charts with whiskers: http://en.wikipedia.org/wiki/Box_plot; nice looking, sophisticated, but might be confusing to users. We could replace the quartiles with high/low data and whiskers with OOB data
Today, there is several ways of representing various time series metrics throughout RHQ. We are trying to consolidate these into a couple standardized charts. For reference to current RHQ Graph types please see attachments
There has been many opinions on this issue and we wanted further feedback from the community on their thoughts. So please, reply back with your thoughts...
11 years, 6 months
JMX Connection - Cassandra
by Stefan Negrea
Hello Everybody,
The new Cassandra plugin relies on the JMX plugin since most of the management is done via the exposed JMX interface. But I am running into a weird problem. After I restart the Cassandra node, all the JMX transactions from RHQ fail until the RHQ agent itself is restarted. I debugged the code and this is due to the fact the EMSConnection is no longer valid/connected after Cassandra is restarted. I looked at other plugins and there is no specific code do deal with this kind of situation. I also looked at the JMX plugin code and there is nothing that indicates a manual connection restart might be needed.
Restarting servers is a very common use case for JBoss AS servers; I am sure this detail was not overlooked so far.
Here is where I would need help:
1) What could be different with Cassandra and its JMX interface to cause this issue?
2) Did I miss something configuring the Cassandra plugin?
3) Should EMS take care of reconnecting to the server in case the underlying resource gets restarted?
Thank you,
Stefan Negrea
Software Engineer
11 years, 6 months
d3 Graphing in RHQ Live Google Plus Hangout
by mike thompson
Sorry for the late notice, but we have decided that d3 graphing talk will be G+ Hangout. It will be recorded for those who cannot attend.
We will cover d3 in general and how it is used in RHQ. I will start the hangout. Someone else can reply back to the list with the link once we have started.
11 years, 6 months
portal-war….our albatross
by John Sanda
This morning in between servicing breakfast requests for my kids, I read a good series of articles[1] on CDI that touches on several things including how CDI enables loose coupling and dependency injection *with* strong typing. Towards the end of the day my curiosity got the better of me and as I was updating some code I decided I would try out CDI in the cassandra-backend branch. The change was benign enough, just using @Inject to inject a pojo into an SLSB. After rebuilding however, rhq failed to deploy. After troubleshooting the deployment errors for a few minutes mazz cautioned me to avoid adding a beans.xml file to any of the rhq artifacts as it would result in deployment problems. CDI requires the presence of a beans.xml file which does not need to contain anything more that <beans/>. Upon further investigation, I realized that the problem was related to JSF due to this error message that I found in my server log,
21:24:40,797 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-2) Critical error during deployment: : com.sun.faces.config.ConfigurationException: Factory 'javax.faces.application.ApplicationFactory' was not configured properly.
After trying a few different things, I decided to just not deploy portal-war. Once I rebuilt and restarted my dev-container without portal-war deployed, sure enough everything started up fine. Even my embedded cassandra cluster deployed without a hitch. Since this problem is rooted in portal-war, I have no desire to investigate further to figure out how to resolve it. There are plenty of compelling reasons to utilize CDI, including the fact that we can use it on the client side. This is yet another reason to get rid of portal-war ASAP.
[1] http://antoniogoncalves.org/2011/04/07/injection-with-cdi-part-i/
- John
11 years, 6 months