Hello dear RHQ developers,
I just googled for "rhq roadmap" (this is what I found:
https://fedorahosted.org/rhq/roadmap) and then had a look at the wiki
(
http://www.rhq-project.org/display/RHQ/Releases) and did not really find something
similar.
... let's start a bit earlier so you could understand me as a production user (in the
first place; in the second place a developer) ...
We as a company have quite some customers that want to have their machines and databases
monitored. The same applies to our systems as well.
We have a self-developed monitoring tool in-place, but were searching for something more
capable and extandable. In the end we decided to use RHQ.
Now that we are using it for quite some time and had to build quite a lot upon it to work
for us, I would like you to give some feedback about how we use it, where the benefits
are, what's missing and priorities we would see, where the development should go (I
could research on existing ideas/feature issues etc. and create tons of feature requests,
but I don't have the time and would like to summarize it for now).
Benefits:
- we can easily rollout RHQ agents to our platforms (Linux, Windows, AIX, HP-UX, ...) and
it basically works (adjustments on JVM params necessary to stabelize agents on AIX,
HP-UX)
- the setup of all the agents and the server takes some time, but it's not
complicated
- we could rather easily integrate our own agent plugins (Oracle db monitoring, log file
monitoring)
- we can setup alarms for our resources and manage them hierachically, with some useful
bulk functionality (e.g. groups, templates, individual read-only rules)
- we can investigate issues based on detailed, aggregated and graphically represented data
(enough and efficient for the monitoring itself and to track down potential problematic
resources)
- there are much more, but the above is the essential part
Situation without our own modifications/extensions (most important first):
- managing up to 100 alerts per day is cumbersome (especially for maintenance situation on
networks/tunnels and machines)
... the currently implemented screens and fitler pages are insufficient for this if you
have a lot of resources and machines where alerts can't be ignored and deleted easily
( remember that one has to keep track of problems and is responsible for noticing details
that might lead to future problems ... especially if it is on a b2b contract basis)
... a lot of this maintenance work is an essential part of our daily work and our
customers and not so exceptional!
... we need auto-acknowledgement and deletion rules (combinable of customer /
machine-regexp / resource-regexp / resource-type-regexp / resource-type-natkey*-regexp /
resource-natkey*-regexp / alert-condition-type [AVAILABILITY|MEASUREMENT] / individually
setable acknowledgement-status ["false", "recovered",
"ignore", "todo", "maintenance", ... ] / start-time /
end-time )
* natkey = natural key, e.g. "Platforms - Linux - CPU 0" or
"mach1.company1.com - CPU 0"
-- all this must be managable in an easy to use (click- and scoll-optimized control view /
dt. "Leitstand") (aggregated data displayed with meaningful colors, tooltips
etc.)
(I will provide some anonymized screenshot if I have time to develop it so you have an
idea how this looks like)
... imagine monitoring personal is informed via some notifications, now it needs to filter
out the most critical customer/machine/database/resource that needs attention
... furthermore we need to fastly categorize or delete alerts so another person or myself
do not have to deal with them again (or sees why it's there, who will work on it, what
is planned todo there, how further similar alarms should be treated, ...)
- compatible groups do not inherit alert templates which makes them less useful
...e.g. a general "Log ERROR found" without some notification setup can't be
modified for DB alerts "DB alert logs" group (e.g. we would like to get an email
for this one)
- we can't auto-setup customer groups (the group definitions do not allow
"and/or" conditions
... you can't say something like 'machine-*.area1.company1.com' and
'machine-*.area2.company1.com' belong to group 'company1'
- customers setup for RHQ usage (setup with view only rights on their group) can see all
other users available
- of course there is more, but the above again are the more important to us (if I did not
forget something ... I am in a hurry since I have a home office day and have to change the
diapers of my son *puh* ;-))
I could write some more pages about this, but I think the alarm and resource management is
the most important to work on for the current stage of the project.
I would leave e.g. the ongoing graphical enhancements (GWT, graph types) aside and
concentrate on the essential and much more important features if it would be for our usage
scenarios.
Of course I understand that a "fancy" looking project sells much better
especially to managers, but if this is not an important point on the "roadmap" I
would skip it for now and concentrate on the user that "does not like to use RHQ if
possible". Because RHQ is only there to notice, track down and recover problematic
resources", RHQ-setup and -cleanup are necessary evils that should be kept minimal.
The real work (~95% of the time) should be spent on the problematic resource or some
related one itself ... db setup/recovery, router, firewalls, os setup, application
changes/restarts etc.
Kind regards
Andreas :-)
PS: Currently our own management overview is heavily based on Eclipse BIRT reports based
itself on RHQ description XML tags (in description of inventories, alert definitions,
groups), Oracle DB Views and Table Functions working over the RHQ DB. This is rather easy
to implement and fast. We plan to extend it to utilize the RHQ client API to not only
visualize the data, but modify it. Of course this is not nice since we should build this
into RHQ itself. But it's easier to start with some DB schema you know than with the
big RHQ monolith itself (We know hibernate, Struts, ADF, JSF and alike, but it's still
hard to say for us how much time has to be spend then).