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
Release 4.1.0 beta available
by Heiko W.Rupp
The RHQ team is happy to announce the immediate availability of a BETA release of the upcoming
4.1.0 release.
This beta contains a wealth of new features and bug fixes and serves as a preview for 4.1 and
to gather feedback. Please note that some of the new features are still work in progress (and
will be for some time) - this means that *you* can still influence the new features by your
feedback.
You can find the release notes at http://rhq-project.org/display/RHQ/Release+Notes+4.1.0+beta
which also contain a link to the downloads.
We want to especially thank Elias Ross, Fusayuki Minamoto, Jijun Liu, Zhongqianglee
and Rafael Torres Coelho Soares for their contributions
Heiko on behalf of the whole team.
--
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: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
12 years, 6 months
REST is coming to RHQ
by Heiko W.Rupp
Hey,
I've written a new blog post about REST coming to RHQ, which illustrates the current state
and the possibilities this will give in the future: http://javablogs.com/Jump.action?id=672973
This is not at all a ready-made package, but a start to enhance. So please help us making
this great, so that you can build great stuff on top of it:
• Provide us with your requirements e.g. on the Design - REST page of the RHQ-Wiki
• Contribute to the code
• Show us your examples you have built on top of the API (and perhaps even contribute them)
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: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
12 years, 7 months
metric default intervals
by John Mazzitelli
re: https://bugzilla.redhat.com/show_bug.cgi?id=741331
I created a temporary branch for this work: feature/metric-tweek
After looking at the metrics and trying to see what we absolutely have
to have enabled, I came to the conclusion we don't have many that we
absolutely have to have enabled :) This is of course all IMHO, I'm sure
others have diametrically opposed opinions, and I reserve to change my
mind at any time for any reason.
But that said, out of box it would be nice to have "something" enabled
to at least a) give the user a warm and fuzzy feeling to see pretty
graphs which indicates things are working properly and b) provides a way
to do a "quick demo" or proof of concept to people that just want to
install and quickly see how things work and get a feel for the kind of
things RHQ can do. Without ANY metrics enabled, newbies will need to
know how to do the extra steps of enabling some metrics, which could be
annoying if all they want to do is quickly install and just see things
"work".
So, here's what I am enabling off the bat in this new branch:
PLATFORM PLUGIN
Platform resource type ("Windows", "Linux", "AIX", etc):
Architecture trait --\
Hostname trait -------\__ summary traits that show in the resource
OS Name trait -------/ view header, so we should enable these
OS Version trait------/
Free Memory
Free Swap Space
Used Memory
Used Swap Space
System Load
User Load
Distribution Name trait ----\__ these are on the Linux
Distribution Version trait--/ platform type only
"Network Adapter" resource type:
Inet4Address trait
JBOSS-AS 4 PLUGIN
"JBoss AS Server" resource type:
JVM Free Memory
JBOSS-AS 5 PLUGIN
"JBoss AS Server" resource type:
JVM Free Memory
Nothing else is enabled in any other plugin. Why not do anything in the
JBossAS 7 plugin? Because Heiko is still developing that so I didn't
want to touch its code - but we will want to probably enable something
in there too.
Well, that's it. The idea is that we show some basic platform metrics
and one basic metric for each EAP instance. Other than that, we don't
turn on anything else by default. We'll let the user tell us what
metrics they are interested in, rather than us telling them what we
think they might be interested in.
I also think we need to consider something that Jay proposed - some kind
of "template set" where we can say, "switch to template set 'common'"
and the "common" template set has collection intervals and default
enable settings for common metrics (these could be what our current
defaults are). We could pre-can some template sets like "debug" (this
enables everything) and "basic" (these enable very few metrics with long
collection intervals) and all things in between. Not sure how this could
look in the UI or how to implement it, but its an idea we could think
about to help users customize their metric collections and yet help them
avoid clobbering the metric subsystem with tons of metrics the user
isn't even interested in or wants to look at.
12 years, 7 months
Postgres 9.1 and string escapes
by Heiko W.Rupp
With Postgres 9.1 (out of the box) I can not log in and get this error in the console log:
Caused by: org.postgresql.util.PSQLException: ERROR: invalid escape string
Hinweis: Escape string must be empty or one character.
This comes from the fact that postgres 9.1 by default uses
"standard conforming strings" - those got introduced in 8.x already,
but were turned off and only warned about.
See http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.1#Backward_c...
We can put the following in postgresql.conf and signal Postgres to reload the
config in order to get it working again:
standard_conforming_strings = off
I have the impression that to fix this out of the box, we would need
a newer version of hibernate('s postgres dialect). Upgrading to the 9.1
driver does not fix 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
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
12 years, 7 months
Request for help: deploying of descriptor-only plugins
by Heiko W.Rupp
Hi,
I wonder if anyone would like to help us to get this BZ into RHQ:
"The custom jmx plugin is a plugin that basically only consists of the plugin
descriptor and which uses all the methods from the jmx-plugin to do its work.
Unfortunately this descriptor still needs to be packaged with in the plugin jar
- even if no classes are deployed alongside, which is a hassle for quick plugin
deployment."
With this enhancement in, jmx-based apps could much faster be added to
monitoring as only the XML-plugin descriptor needs to be written and deployed
without the need to packaging the result into a plugin jar.
See https://bugzilla.redhat.com/show_bug.cgi?id=741682
Mazz has outlined a possible implementation in his comment on the BZ
Ping us if you want to help implementing this.
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: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
12 years, 7 months
Re: new default metric collection intervals
by John Mazzitelli
I had in inventory one platform and one RHQ Server. DB had this for the
test:
Platform Total : 1
Server Total : 4
Service Total : 309
Prior to my changes, with all the RHQ plugins built and deployed
(including all the ones that aren't in JON, like MySQL, Cron, IRC,
Twitter, etc etc), here's what my DB had wrt metric definitions and
schedules:
==========
Number of metric definitions: 2652
Average Default Collection Interval: 783,295ms
Number of schedules (i.e. for those resources only in inventory): 2543
Average Collection Interval: 885,253ms (about 14 minutes)
==========
I then rebuilt and redeployed all plugins. All plugins had their metrics
turned off by default and collection intervals increased by the amount
my previous email mentioned.
==========
Number of metric definitions: 2652
Average Default Collection Interval: 2,511,033ms
Number of schedules (i.e. for those resources only in inventory): 2443
Average Collection Interval: 2,497,748ms (about 40 minutes)
==========
In short, on average, metric load was reduced by about 285% (that is,
more technically, our collection interval was increased on average by
about 285%). Whether or not that metric is relevant or not, I dunno -
but that's what the collection intervals increased to. That's all I
looked at so far - JUST what the intervals worked out to.
12 years, 7 months
new default metric collection intervals
by John Mazzitelli
This is : https://bugzilla.redhat.com/show_bug.cgi?id=642416
I am going to go through our plugin XML metadata for all plugins and I
will remove most of the default intervals. I will also turn off many
metrics (defaultOn="false")
This is because most of the metrics are not interesting to most people
so there is no need to collect them out of box (this will lessen the
load on the server, agent and DB backend as well).
Also, the fallback interval defaults will be increased. When a metric
definition is parsed from metadata and persisted, the default collection
interval (if not explicitly stated in the plugin descriptor XML) is
determined in: MetricsMetadataParser.parseMetricsMetadata().
Based on the kind of metric (dynamic, trait, calltime), whether it is a
"summary" metric or a "detail" metric, and based on if it is a metric
for a platform, server or service resource, we determine a default
collection interval. I am going to increase those defaults. Here is the
current defaults, along with my proposed increases - let me know what
you think about the new values (too high? too low?). The intervals
listed below are in minutes:
DEFAULTS
Metric Type Current, New
=================================================
NUMERIC METRICS:
SUMMARY:
Platform: 1 10
Server: 5 20
Service: 10 30
DETAIL: (these are just doubled from above)
Platform: 2 20
Server: 10 40
Service: 20 60
TRAITS:
SUMMARY: 10 30
DETAIL: 30 60
CALLTIME: 1 10
ANY OTHER METRIC: 10 30
(side note: for those not familiar, a metric is set as a "summary"
metric by the "displayType" attribute in the <metric> metadata - its
just a way to let the system know you want to show its graph on the main
Monitoring tab - if it is a "detail" as opposed to "summary" metric, the
graph isn't shown by default and we just show the data in the Tables
subtab of the Monitoring tab).
12 years, 7 months
quicker LDAP setup
by Deon Lackey
Hey, Simeon and Mike.
Just to follow up on the LDAP user auth setup, I have some links for the RHDS silent that may help it go a little faster. (Funny enough, I couldn't find anything on the 389 wiki about it, but it should work the same either way.)
Okay, to set up a DS instance to use for RHQ user authentication[1], you can run a silent setup[2] , and that passes all of the required information to the setup script using a single inf file[3]. So, you'd create the .inf file and run...
setup--admin.pl -s -f myfile.inf
And that's it. If you're using a lot of different machines, then you can leave the (required) machine name parameter out of the .inf file and just pass it with the setup command:
setup--admin.pl -s -f myfile.inf General.FullMachineName=ldap.example.com
Let's see, what else.
There are sample users and groups already available in Example.ldif in /usr/share/dirsrv/data/. You can import the LDIF file after the server is created using something like 'ldamodify -a -f my.ldif' or ldif2db. That's just for testing/dev, so you have some pre-populated users to work with.
Oh, and you don't have to do a full install if you don't want to. setp-ds-admin.pl installs the full Directory Server (LDAP/Berkeley db and stuff) and the Admin Server (basically a hyped up web server) and then the Java GUI and a bunch of tools. If you want, you can do all of the DS setup operations using LDAP tools and then you don't need the Admin Server and GUI. For that, you just need to install 389-ds-base and run setup-ds.pl (no -admin). I don't know how much time or space that really saves you, but it's an option if you want it.
Was there anything else I mentioned? I say a lot of things.
Deon
[1] http://rhq-project.org/display/RHQ/Design-LDAP+Integration
[2] http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Insta...
[3] http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Insta...
12 years, 7 months