[#RHQ-1064] default event purge time should be less than a month

RHQ Project

default event purge time should be less than a month

Created: 05/Nov/08 10:20 AM Updated: 19/Nov/08 11:20 AM

Component/s:

Core Server

Affects Version/s:

1.1

Fix Version/s:

1.2

Time Tracking:

Not Specified

Issue Links:

Dependency

This issue Is A Dependency Of:

RHQ-1122 throttle events

Relation

This issue Is Related To:

RHQ-1119 should we reduce the purge time for traits and availabilty?

Date of First Response:

05/Nov/08 10:22 AM

Description

« Hide

Right now, the default purge time is 31 days for events/OOBs. In other words, we retain a month's worth of event and OOB data - anything older is purged.

We should discuss whether or not this is too much. Event data (such as log information) can be very large. In addition, our large environment tests is showing large amounts of OOB data gathered within a week or less.

I recommend we consider lowering this default down to 14 or even 7 days. Are events worth maintaining that are older than a week or two old? Similarly, are OOBs worth anything when they are a week or two old?

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Joseph Marques - 05/Nov/08 10:22 AM

maybe this is feature creep, but why have global configurations at all? why not make this configurable at the resource-level, resourceType-level, and/or resourceGroup-level?

[ Permlink | « Hide ]

John Mazzitelli - 05/Nov/08 10:25 AM

joe - something to discuss for a new feature in future version. Definitely feature creep.

For now, this JIRA is to document the need to possibly reduce the global time frame from a default of 31 days to 14 or 7 days.

[ Permlink | « Hide ]

Jay Shaughnessy - 05/Nov/08 10:34 AM

A global config at least gives a default, even if you add granularity. An interesting idea although it may border on too much flexibility. I'd suggest waiting for customer feedback, if only for simplicity in the purge job.

I'm not sure generating events at that level is really worthwhile for a real customer. I'm still skeptical about event generation that isn't tied to alert firing. And that would imply that event's usefulness degrades fairly quickly. Seeing events on the timeline is interesting, maybe, but a month may be more than needed. So, I guess I'd favor a shorter, perhaps 14 day purge. Or, a limit on the number of events, as opposed to a date range.

[ Permlink | « Hide ]

John Mazzitelli - 12/Nov/08 07:33 AM

this is something I want to discuss for 1.2. If we do want to change the defaults, should be a very fast fix.

[ Permlink | « Hide ]

John Mazzitelli - 18/Nov/08 03:58 PM

FWIW, EventReport has this code in it to attempt to throttle events:

private static final int MAX_EVENTS_PER_SOURCE = 1000;
...
        if (eventSet.size() < MAX_EVENTS_PER_SOURCE)
            eventSet.add(event);
        else if (eventSet.size() == MAX_EVENTS_PER_SOURCE)
            LOG.warn(eventSource + " contains the maximum allowed Events per source (" + MAX_EVENTS_PER_SOURCE + ") - no more Events from this source will be added to this report.");