general RHQ feedback and roadmap

Joseph Marques jmarques at redhat.com
Wed Nov 10 04:42:51 UTC 2010


Andreas, thanks for the detailed feedback.  Responses in line below...

n 10/29/2010 05:46 AM, Andreas Dietrich wrote:
> ...
> 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)
Can you characterize, explain, or copy/paste the tweaks you found 
necessary?  It might necessitate a change to the default scripts, or at 
the very least be useful input to the FAQ and/or installation guide.
> - the setup of all the agents and the server takes some time, but it's not complicated
And in case you haven't seen it -- 
http://www.rhq-project.org/display/JOPR2/RHQ+Agent+Installation#RHQAgentInstallation-AutoUpdatingTheAgent

Also, we'd be interested in your feedback around -- 
http://management-platform.blogspot.com/2010/08/remotely-installing-agent.html 

> - 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)
Do you have any ideas for how to help alleviate this?
> ... 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"
Today, alert history can be viewed a single resource at a time, a group 
at a time, or for any resource visible to the user via the alert history 
subsystem view.  Filters vary between the screen but generally have 
time/date, priority (low,medium,high), type (measurement-based 
condition, operation-based condition, etc).

In the future, it's likely that we would extend the new search facility 
in RHQ to alerts -- 
http://josephmarques.wordpress.com/2010/08/04/rhqs-powerful-new-search-facility/

Implementing the search bar contract for alerts would mean that you 
could then have saved searches for alert history, to help manage that 
daily flow.

As for the individually settable acknowledgement-status, I've filed this 
enhancement request for you -- 
https://bugzilla.redhat.com/show_bug.cgi?id=651504
> -- 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)
Alert templates and group alert definitions are both convenience 
mechanisms.  If you create an alert template, it will clone that 
definition to all resources of that type.  If you create a group alert 
definition, it will clone that definition to all members in that group.

I'm a bit unsure of what you mean by "do not inherit alert templates."  
Are you saying you want to be able to create alert template 1 for type 
A, then to a compatible group of type A, and edit template 1 just for 
the members in the group?  Or that you want to be able to create a new 
group alert definition by starting from the current state of one of the 
alert templates?  Please provide your thoughts on what features you'd 
like to see in this area to make alerting more useful.
> - 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'
Agreed, and group definitions will eventually be expanded to include 
more robust condition rules.  In the meantime, would 
"resource.name.endswith = company1.com" work?
> - customers setup for RHQ usage (setup with view only rights on their group) can see all other users available
This is working as intended.  One of the primary use cases is found in 
the alerting subsystem.  When you create an alert definition and want to 
set up notifications, you need to choose from valid users and roles in 
the system.  This is why all users have visibility into that type of data.
> - 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).
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list