Synchronise RHQ Server
by Romain Pelisse
Hi all,
I'm a bit sorry I meant to open this topic with the RHQ topic for more than
year now, and I've never came around that. I must confess that being a Red
Hat employee, I know quite well JON (supported version), but not the
upstream project - so if my knowledge of RHQ internal seems out date, I
apologize.
Here comes the question / topic:
Up to my knowledge, if I create (for instance) a set of custom alerts,
tweak some other settings and add plugins to one RHQ server, there is no
mechanism at our disposal to say "now, replicated this configuration in
those other instance of RHQ Server".
The purpose being that is obviously maintaining different env in sync (Dev,
QA, Prod,...), but also scalabilty (being able to deploy several instance
of RHQ server to partition a large scale env that would otherwise overun
the RHQ server ).
Last time I checked (2 years ago, with JON 3.1.x) , this feature was not
there, and we build a tool called RHQ
Sync<https://github.com/rpelisse/rhq-sync-tool>to try to cope with
that. Where are we on this topic now ?
--
Romain PELISSE,
*"The trouble with having an open mind, of course, is that people will
insist on coming along and trying to put things in it" -- Terry Pratchett*
Belaran ins Prussia (blog) <http://blog.wordpress.belaran.eu/> (...
finally up and running !)
9 years, 11 months
RHQ 4.11 released
by Heiko W.Rupp
It is my pleasure to announce the release of RHQ 4.11.
Notable changes are:
• Plugins can now define plugin specific DynaGroup expressions, which can even be auto-activated
• Further agent footprint reduction for jmx-clients (especially if the agent runs on jdk 1.6)
• Much improved agent install via ssh from the RHQ UI.
• Support for Oracle 12 as backend database
• New login screen that follows patternfly.org
As always RHQ is available for download in form of a zip archive. If you want to try out RHQ without too much setup, you can also use a pre-created Docker image fromhttps://index.docker.io/u/gkhachik/rhq-fedora.20/ (the link contains setup information).
Please consult the release notes for further details and a download link.
https://docs.jboss.org/author/display/RHQ/Release+Notes+4.11
Special thanks goes to
• Elias Ross
• Michael Burman
for their code contributions for this release.
--
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, Michael O'Neill,
Charlie Peters
9 years, 11 months
Revamped RHQ Subcategories - Engineering Review
by Stefan Negrea
The following is a new meeting request:
Subject: Revamped RHQ Subcategories - Engineering Review
Organizer: "Stefan Negrea" <snegrea(a)redhat.com>
Location: Elluminate + Conference Line
Time: Wednesday, May 7, 2014, 10:30:00 AM - 11:30:00 AM GMT -06:00 US/Canada Central
Invitees: rhq-devel(a)lists.fedorahosted.org
*~*~*~*~*~*~*~*~*~*
Hello Everybody,
I would like to schedule an engineering review for the subcategories mini-feature because the changes are extensive. The plan is to show the existing problem, both visual and with the design, and then go into the details of the fix. This will be a code oriented meeting.
Pull Request:
https://github.com/rhq-project/rhq/pull/22
Elluminate:
https://sas.elluminate.com/m.jnlp?sid=819&password=M.AF6578A00508D827BDCB...
Conference Line:
(regular conference line)
9 years, 11 months
RHQ trait storage
by Elias Ross
I was thinking about how to do trait storage.
https://planet.jboss.org/post/modeling_metric_data_in_cassandra
This document doesn't really explain the major problem with how to
deal with repeated inserts.
I came up with three approaches for consideration:
1. Select and insert
The schema:
CREATE TABLE IF NOT EXISTS measurement_data_trait (
schedule_id int,
value varchar,
timestamp int, -- when it was inserted
PRIMARY KEY (schedule_id)
);
CREATE TABLE IF NOT EXISTS measurement_data_trait_history (
schedule_id int,
timestamp x,
value varchar,
PRIMARY KEY (schedule_id, timestamp)
);
Approach is to:
1) Select the current value. (*)
2) If it is different then insert into the history table. Use TTL
columns to delete old records.
3) In any case, update the measurement_data_trait table with the most
current value
Benefits:
1) Easy to select the most recent value
2) Logic is straightforward
Problems:
1) Select than insert is slow.
2) Hard to do transactionally and with a lot of traits.
3) Race condition exists where insert may happen twice. (Not really likely.)
(*) Probably the most efficient way is to select is to submit the
select asynchronously, then when it completes, do the update and
insert. This does mean, potentially, an insert or update is lost if
the server is shutdown. The mitigating factor, of course, is trait
reports are periodic and effectively retried.
2. Insert then cleanup
Insert in history every time a new value is reported, also update the
most current value.
Then periodically remove any duplicates.
Benefits:
1) Insert only, no round trips
Problems:
1) Basically defers the 'select' as before, so the same amount of work, really
2) Extra disk space/storage. Cassandra data compression may mitigate
disk usage, but still lots more writes. (Worst case would be a trait
reporting the same value every 30 seconds.)
3) Cannot really update the 'when the trait changed' timestamp --
since we are only inserting
Possible alternatives:
1) Defer compression to when data is selected.
3. Map values to timestamps
Similar to above, but using a set of timestamps.
CREATE TABLE IF NOT EXISTS measurement_data_trait_history (
schedule_id int,
value varchar,
timestamps set<x>,
PRIMARY KEY (schedule_id, value)
);
Benefits:
1) Insert only
Problems:
1) The number of timestamps may be ever increasing and so a process is
needed to clean it up. TTL expiration doesn't work, if the value
flip-flops back and forth between two sets of values.
2) Therefore, there needs to be another cleanup process to deal with
this. This could be done using a counter that increases for every
update, and once it reaches a certain value forces a "garbage
collection" of sorts.
Thoughts?
9 years, 11 months