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, 1 month
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
New design proposal for "External DynaGroup templates"
by Heiko W.Rupp
Hey,
as the current DynaGroup templates are hard coded in the server, and are thus not extensible,
I've witten down an initial design document as proposal for the implementation of a changed
way to create such templates in the future:
https://docs.jboss.org/author/display/RHQ/External+DynaGroup+templates
Please comment on it.
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
10 years, 3 months
Raw Config - can we drop it ?
by Heiko W.Rupp
Hey,
as far as I know is no one using raw config.
There was one person on irc the other day that wanted to do
something with it, but does any one know more?
I would love to completely drop it ...
10 years, 4 months
Plugin-validation and mysql driver?
by Heiko W.Rupp
Hey,
when I do a full build, it fails for me with an error in plugin validation that
the mysql driver can not be found.
I think someone found a solution recently ?
Or could we just disable validation of that plugin?
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
10 years, 4 months
Logging verbosity
by Lukas Krejci
Recently, I noticed this as part of one commit:
LOG.warn("Availability collection failed with exception on " + resource
- + ", availability will be reported as " + DOWN.name(), t);
+ + ", availability will be reported as " + DOWN.name() + ", reason=" + t.getMessage());
I am personally very much FOR having stacktraces in the log messages, especially in erroneous conditions like this one (i.e. IMHO almost any log message on WARN and ERROR levels SHOULD have a stacktrace attached). The reason is that including just the error message in the log loses information that would be very valuable during debugging potential bugs (even more so in a complex code like avail collection).
Is there a policy/consensus of sorts for inclusion/exclusion of full stacktraces in the log messages?
Cheers,
Lukas
10 years, 4 months
New Storage Cluster - Sizing Guidelines
by Stefan Negrea
Hello Everybody,
We've been working on sizing guidelines for the new Storage Cluster. We focused on two aspects: disk and compute power. We condensed all of our findings into a Google Spreadsheet and wiki page (more about this below). While we are still capturing data and refining results we wanted to get this in the hands of users to get feedback.
Data size on disk was our primary focus since it is relative to the number of metrics schedules and collection interval. The underlying data storage is not trivial but thanks to John Sanda's hard work we now have an algorithm that gives a baseline. In terms of computer power, we wanted to see how far we can scale a deployment with the new Storage Cluster. While we have collected some early numbers via simulations, this time we wanted to use a real life deployment. We are still collecting data for the compute part and we are still far from the upper limit.
The Google Spreadsheet:
URL: http://goo.gl/kWI29e
Sheets:
1. Disk Size Algorithm - Interactive algorithm to calculate the baseline for data size on disk. Either update rows 6 through 9, columns A & B or add new rows in that section as per your installation. Once all the data is inserted you will get a total the bottom of the spreadsheet with estimate size per node. The number of storage nodes is also configurable (row 28, column B). If you have more storage nodes the data will get distributed across the cluster so the amount of disk required per node decreases.
2. Discrete Data - data collected from running simulations for collecting metrics and running aggregation. The amount disk used was captured at the end of each run without forcing compaction.
3. Long Run Charts & Long Run Data - During the 60 days simulation, data size on disk was collected on an hourly basis. That gives an indication on the patterns for how data grows (along with occasional spikes due to compaction).
4. Metrics Collection testbed - Data captured during the compute power testing. Data here is very preliminary and we will augment it as we collect more.
5. Changelog - we will keep a change log as we update the content.
How Use it:
1. If you just want to explore our findings, just follow the link above.
2. If you want to get an estimate for your particular installation or future installation, make a copy of the spreedsheet on your Google Drive. Then update the columns/rows marked with bright bleu on the "Disk Size Algorithm" sheet. Make sure to check back periodically the original spreadsheet as we are still working on refinements.
Wiki with additional information:
https://docs.jboss.org/author/display/RHQ49/Storage+Sizing+Analysis
Please feel free to reach to us if you have any questions or comments, we will be glad to answer and help. Any feedback is more than appreciated.
Thank you,
Stefan Negrea
Software Engineer
10 years, 4 months
Fwd: [wildfly-dev] New JDK 8 tool: jdeps
by Heiko W.Rupp
This is probably not immediately important, but may be
a good tool going forward as JDK9 (or already 8?) will be more strict
and hide internal apis more than older JDKs
Anfang der weitergeleiteten Nachricht:
> Von: "Rory O'Donnell" <rory.odonnell(a)oracle.com>
> Betreff: [wildfly-dev] New JDK 8 tool: jdeps
> Datum: 17. Dezember 2013 14:11:13 MEZ
> An: Max Rydahl Andersen <manderse(a)redhat.com>, Tomaž Cerar <tomaz.cerar(a)gmail.com>, norman.maurer(a)googlemail.com
> Kopie: rory.odonnell(a)oracle.com, "BORG, CECILIA" <cecilia.borg(a)oracle.com>, "TOPIC, DALIBOR" <dalibor.topic(a)oracle.com>, wildfly-dev(a)lists.jboss.org, balchandra.vaidya(a)oracle.com
>
> Hi All,
>
> Here's a blog from Erik Costlow on a new tool in JDK 8 that lets you
> analyze your code
> for dependencies on JDK internal APIs :
>
> https://blogs.oracle.com/java-platform-group/entry/closing_the_closed_apis
>
> Please let me know if you have any feedback - I'd be interested to hear
> if you use any
> internal APIs.
>
> Rgds,Rory
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
10 years, 4 months
AS7 plugin: Hibernate Query Cache resource type
by Thomas Segismont
Hi everyone,
I fixed "Bug 1033130 - [AS7] Exception during discovery of Query Cache
resources of RHQ Server resource" this week.
So what? Well now if you inventory RHQ server resource you get more than
2000 query cache resources showing up. Which of course costs you CPU and
memory.
You can of course just ignore this resource type (via the admin pages).
So I was wondering: shouldn't we change such resource types to no longer
auto discover them but only allow manual add?
Opinions?
Thanks,
Thomas
10 years, 4 months