Improving recent alerts porlet - recovering question

Michael Burman yak at iki.fi
Sun Aug 25 22:05:15 UTC 2013


Hi,

While improving the recent alerts portlet with some filtering options (no,
I haven't created a BZ for this yet), I've come up with some questions.
What I've initially done is to add filtering options for not displaying
acknowledged alerts, nor recovery type (as these didn't require any complex
changes). I also wanted to filter "recovered" alerts and include a column
in the recent alerts view that indicates the alert has recovered. The
use-case for us has been some BAM alerts that quite often fix themselves
(we send these events to RHQ), and also our automatic processes that try to
patch some issues. That's when I ran into an issue.

Considering the following SQL query to find out if alerts have recovered:

SELECT id, alert_definition_id, ctime, recovery_id, will_recover, ack_time,
       ack_subject,
       (CASE WHEN will_recover = 't' THEN
        (SELECT MAX(ra2.id) FROM rhq_alert AS ra2
        WHERE ra.ctime < ra2.ctime AND ra.alert_definition_id =
ra2.recovery_id) END) AS recovered_by
  FROM rhq_alert AS ra
  ORDER BY ctime DESC

I then hit my head against the CriteriaQueryBuilder and related data source
stuff, and could use some hints how to get this sort of things working with
the JPA implementation in this case. Then I read the BZs and noticed there
are already issues with performance with large number of alerts (this would
require new index to be efficient), and also assuming RHQ might some day
store alerts on something else than relational store, and wondered should I
instead process this on the write-path?

Adding new field to the alert table, indicating which alert recovered it,
or just a boolean like the "will_recover"-column. This creates one update
clause on the alert writing process, but saves I/O on the reading-path.
Opinions? This would also make the "recovered_by" id a real one, not the
latest one like in my SQL query (a small shortcut).

These also bring me to an UI question. Two of these filters are "status"
filters, (acknowledged & recovered) while one is "type" filter (recovery
alerts). Should these be in a same dropdown menu? Will the UI run out of
space soon if recent alerts has a lot of options in the upper part?

And continuing this, while I can do view -> dynagroups -> alerts and view
only those alerts, I can't do this to a dashboard. Any reason why? I know
the dashboard is very static and could use a lot of work, but I'd really
hope for usability reasons, that any view I can find in the RHQ, I could
also apply to my dashboard. I don't know if this is technically possible in
current GWT/SmartGWT structure, but I'd like to know. It would be seriously
.. useful.

  - Micke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20130826/9ead5a1b/attachment.html>


More information about the rhq-devel mailing list