general RHQ feedback and roadmap
by Andreas Dietrich
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).
13 years, 7 months
Re: chart types discussion
by Charles Crouch
Thats an interesting idea Andreas. I had assumed that the "summary" and "detailed" charts being different was a bad thing, but maybe we could have the "summary" graphs be regular area charts, and the "detailed" chart view show the more precise floating column based chart. On the detailed chart page there should be more room for a textual description of what is going on too, which would help explain what the non-standard chart is trying to show.
Like I said before we need to have some of these different chart types rendered with real world data sets and pixel areas.
Cheers
Charles
----- "Andreas Dietrich" <adi(a)aspicon.de> wrote:
> Hi,
>
> sorry if I misundestood something ... I did not follow the whole
> discussion.
> If possible we should try to implement a solution supporting both
> graphical representations:
>
> 1. the standard "easy to understand, fancy looking, but maybe
> inaccurate" graphs and
> 2. the optional "unfamiliar, more complex, but (more) accurate" graphs
>
> Thanks
> Andreas :-)
>
>
> On 10/28/2010 11:10 AM, Joseph Marques wrote:
>
> On 10/28/2010 12:49 AM, Charles Crouch wrote:
>
> I * think * this was the point Greg was trying to make, the horizontal
> width of the bar implies to the user, since time is the y-axis, that
> there is a period of time related to the data collection which is
> important. When there really isn't, its just an artifact of how we are
> doing data bucketing. Actually, the horizontal width of the bar is
> important because provides boundaries for each timeslice, which have
> specific start/end times relative to the overall time range being
> viewed. This is a very accurate type of chart insofar as the
> mix/max/avg markers are calculated with respect to the timeslice
> boundaries.
>
> Contrast with that a line chart which turns those timeslices into
> single points (and then connects the dots between two points in
> temporal order). The algorithm for querying data uses buckets that
> have a non-zero width along the y-axis (time), but then the graph is
> displaying that bucket as a single point (no width) connected to the
> next single point (no width).
>
> All that said, I'm willing to concede that single points are probably
> more intuitive to a lay user than bars. I just wanted to be clear that
> intuitiveness was the driving factor here. I didn't and don't believe
> that candlestick is any worse at displaying point-in-time bucketed
> data than it is at displaying continuous bucketed data - the bucketing
> naturally normalizes the input from these sources. And it was agreed
> in #rhq that the jitter affect from bucketing would be present and
> need to be handled regardless of chart type. My primary concern was to
> thoroughly understand the ideas being presented, so that the wiki
> could be updated to better elaborate on the pain points of our current
> solution and accurately reflect how other solutions (such as line
> graphs) could mitigate those issues.
>
>
> If you use a point or line graph, then this initial confusion maybe
> mitigated. The actual datapoints don't change, so people could still
> ask over what period do we calculate the average, but its perhaps not
> the first thing they think of. Yes, this is what I thought the
> conclusion was in #rhq yesterday. It didn't seem like we were talking
> about getting rid of bucketing (and so any chart type would still need
> to deal with potential jitters, or somehow make the buckets
> consistent). I agree that a line chart is easier on the eyes, but
> don't believe that we are fundamentally changing what we are charting
> (bucketed data); we're just playing connect-the-dots (instead of
> bars/ticks) which, again, I'm willing to concede may be a more
> intuitive solution (even if it's not as accurate because it reduces
> data buckets [which have real width] to single points [which have no
> width]).
> _______________________________________________
> rhq-devel mailing list rhq-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
13 years, 7 months
RfC: Test group separation / module reorganisation
by Heiko W.Rupp
Hi,
currently (nearly) all tests run in the integration.ejb3 group. No matter if those are server side plugins or core domain
or real biz logic.
Tests should imho be separated out in more distinct groups and only run if relevant
e.g. only run UI tests when UI code or code the UI depends on is changed, but not
when e.g. plugin code has changed.
Another aspect to this is that our builds often build a lot of stuff even if no relevant code
has been changed. THis is e.g. the case when a plugin is changed, the UI code needs
no rebuild (and vice versa).
It looks like the issue is not entirely trivial for the automatic testing side, but there is hope:
- http://www.dzone.com/links/sibilla_first_release_experince_a_new_approach...
that is by a colleague, Stefano Maestri and seems to analyze the relevant changed path
and only run relevant tests
- JunitMax ($$-ware) for Eclipse sorts tests according to runtime and likelihood of failing, so that
the user gets fast feedback and sees failures in the usual error view
Anyway : server side plugins should move out of enterprise/server to modules/server-plugins
installer should move out of the enterprise/gui into modules/installer and I guess there are
a few more candidates.
John Sanda was also proposing to move the performance testing outside of enterprise/server
into some (more or less) toplevel module.
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 7 months
chart types discussion
by Charles Crouch
Greg, Joseph
I just wanted to summarize the discussion from IRC today (http://pastebin.com/SUt9Wi0N) and the updated wiki (http://rhq-project.org/display/RHQ/Design-NewChartingLib) and make sure I have it correct. Please reply, setting the record straight where I misunderstood.
Cheers
Charles
To be clear from the outset, this discussion seems to have nothing at all to do with charting libraries, but rather the style of chart we should be rendering. Also this discussion does not to appear to be about how we bucket data, it appears settled that the way we are doing it now is a necessary evil.
The idea seems to be that instead of the charts we show right now:
a) The summary metric (1-currentSummaryMetric.png)
Which I think we can all agree is not really a Candlestick (http://en.wikipedia.org/wiki/Candlestick_chart), more of a floating column chart (for high/low) with a tick mark for the average value.
and
b) The "detailed metric" (2-currentDetailedMetric.png)
Which I think could be best described as a slimmed down OHLC chart (http://en.wikipedia.org/wiki/Open-high-low-close_chart), overlaid on top of a regular bar chart showing the average value.
that they should be replaced by something like a standard area chart, as shown in the attached 3-areaGraphicMetric.png
My 2c...
First off, is there any merit to changing what we've got today? I think so...
1) User expectaions: The difficulty of describing the two chart types in the explanation above should be an indicator that these are fairly non-standard. Looking at the charts available in Google Docs and OpenOffice I couldn't readily create a chart that matched what we currently render, given a simple dataset consisting of min/max/avg datapoints. The data we are trying to plot is not unusual, I think there is merit in using a chart type users are familar with, or at least is fairly intuitive.
2) User understanding: When a new user see the metrics tab for the first time, the reaction is typically something like the following:
NewUser: Ooh, those graphs are cool, what do the bars and squiggles mean?
Me: The bar shows the min/max over the period and the squiggle is the average
NewUser: Cool. What period?
Me: Yeah...Right...you know the *period*.......If you take the start time from the end time and divide it by 60, then center it around the time indicated by the grey timeline, then thats the period. See...simple, really....
NewUser: rrrrrrrrrrrrrrrrright
I *think* this was the point Greg was trying to make, the horizontal width of the bar implies to the user, since time is the y-axis, that there is a period of time related to the data collection which is important. When there really isn't, its just an artifact of how we are doing data bucketing. If you use a point or line graph, then this initial confusion maybe mitigated. The actual datapoints don't change, so people could still ask over what period do we calculate the average, but its perhaps not the first thing they think of.
3) Consistency: Why do we use two different chart types for the "summary" and "detailed" charts? Also the "detailed" chart is no more detailed than the summary one, correct? Both have 60 datapoints, its just bigger?
So yes I think there is room for improvement.
What should that improvement look like?
Well on first inspection, the use of something like 3-areaGraphicMetric.png is appealing.
Its a normal area graph, which is readily understandable by most people: the min is below the average which is below the high.
However this is not an apples to apples comparison, the pixel area available to the summary graphs is vastly different to that shown at the bottom of http://rhq-project.org/display/RHQ/Design-NewChartingLib. So what looks good at large scale may not be so good at a much smaller scale.
I think to make an effective comparison of chart types (not saying chart libs) we're going to need to pick several datasets, and two pixel areas (one for the samll graphs and one for the large) and try rendering all the datasets acros both pixel areas using each chart type.
13 years, 7 months
pastebin
by Joseph Marques
If you use Chrome, you might find this to be a handy extension:
https://chrome.google.com/extensions/detail/ghipmampnddcpdlppkkamoankmkmc...
The extension's options allow you to pre-fill all the things you may
want to enter (lang for syntax highlighting, post expiration/exposure,
post name/title, subdomain, and email) as well as override any of those
defaults on a post-by-post basis.
After posting, it will give you the URL and a convenient button to copy
it for quick pasting into the #rhq channel. I've set my subdomain to
"rhq" so that URLs are generated like http://rhq.pastebin.com/GqgWqPZ3
-joseph
13 years, 7 months
problem with ResourceTypeCriteria
by John Mazzitelli
I seem to have discovered a very bad problem with ResourceTypeCriteria
and/or the Criteria Query engine. I may need Joe to help with this one.
I discovered this while stepping through ResourceTypeRepository,
specifically:
ResourceTypeRepository.getResourceTypes(Integer[],
EnumSet<MetadataType>, TypesLoadedCallback)
where the Integer[] array has a single ID (my Linux Platform type ID)
and the EnumSet contains MetadataType.operations, measurements, events,
and resourceConfigurationDefinition.
This boils down to a call to:
resourceTypeService.findResourceTypesByCriteria(criteria)
where my criteria has filterId null but filterIds is a one-element List
(I suspect the problem might be caused by using the
ResourceTypeCriteria.addFilterIds (plural) rather than the singlular
addFilterId form).
When I get back the results, the PageList has *48* resource types in the
list - ALL are the Linux Platform type. I should only have received *1*
back (remember, I only asked for 1 resource type, and the criteria's
filterIds had only a single item in it). There must be something wrong
with the dynamically built query that caused it to return 48 rows, as
opposed to just 1.
Note that if I do NOT ask for any MetadataType (i.e. the EnumSet is
empty, thus I just ask for the base ResourceType without any
relationship collections), things work fine and the fetch by criteria
returns a single item in the PageList as expected.
Debugging in the CriteriaQueryRunner, I see this as the query:
SELECT resourcetype
FROM ResourceType resourcetype
LEFT JOIN FETCH resourcetype.resourceConfigurationDefinition
LEFT JOIN FETCH resourcetype.metricDefinitions
LEFT JOIN FETCH resourcetype.eventDefinitions
LEFT JOIN FETCH resourcetype.operationDefinitions
WHERE ( resourcetype.id in ( :ids ) )
and this is the countQuery:
SELECT COUNT(resourcetype)
FROM ResourceType resourcetype
WHERE ( resourcetype.id in ( :ids ) )
the named parameter list looked correct, the "ids" appeared to only have
a single Id in it. But stepping in:
org.rhq.enterprise.server.util.CriteriaQueryRunner.execute()
and I see the query results come back with 48 rows but the countQuery
returns back with 1 (and 1 is what should be correct).
So, the countQuery returns the correct answer - 1 - but the query itself
returns 48 items!
Very odd. For some reason, hibernate returned us 48 times the data than
we expected. Unsure what we did wrong in building the query.
13 years, 7 months
alert templates done - initial alert def gwt conversion complete
by John Mazzitelli
I committed my final push to master - all the GWT alert definition
editing stuff should (finally!) be completed. This final commit includes:
1) the new Administration>Templates GWT based GUI (it shows essentially
the same data as the old jsp templates page, but in scrollable lists
views - the servers are in a tree view with the tree nodes collapsible
under all top level servers).
2) the alert template editor - same as the reource and group alert
definition editor forms (reusing components in GWT is very nice :). This
lets you create alert templates on a resource type basis.
Anyone knowledgeable in the way the old jsp pages work for alert
templates, please look at this new stuff to make sure I didn't forget
anything.
I think we are ready for testing/QA'ing of this. I have no doubt there
will be problems with it. But my eyes are blurry after working on this
for weeks x-| so I'm sure a fresh set of eyes to test this would be
beneficial.
John Mazz
13 years, 7 months
tree grid selection question
by John Mazzitelli
Look at the auto-discovery queue view in the GWT UI.
Notice that you cannot select JUST a platform (without selecting at
least one of the children). If you select a platform checkbox, all of
its children are auto-selected. If you de-select all the children, the
platform itself is auto-deselected. There is no way to get JUST the
platform checked with none of its children checked.
We need a way to say "I only want to import the platform, but I do not
want to import any child servers" (we just hit another user yesterday
that wanted to do this - it worked for them because they were on an old
RHQ version and the jsf pages let you do this).
In ResourceAutodiscoveryView, I see it builds the TreeGrid with these
settings:
treeGrid.setShowPartialSelection(true);
treeGrid.setCascadeSelection(true);
It seems that turning off the cascade selection will technically do what
I want (setCascadeSelection(false)). However, we are then at a point
where if I DO want every server under a platform imported, I can't just
select the platform - I have to select each child node individually
(which could potentially be a lot of individual clicks).
Thus, I want the best of both worlds :) Any one know a good GWT trick to
do this?
13 years, 7 months