Bug 461704 - Monitoring probes data in time_series table are not cleaned up when probes/system profiles are deleted
Monitoring probes data in time_series table are not cleaned up when probes/sy...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Monitoring (Show other bugs)
423
All Linux
medium Severity medium
: ---
: ---
Assigned To: Milan Zazrivec
Preethi Thomas
:
Depends On:
Blocks: 463877
  Show dependency treegraph
 
Reported: 2008-09-09 20:35 EDT by Xixi
Modified: 2010-10-14 02:53 EDT (History)
2 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-10 14:48:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Xixi 2008-09-09 20:35:50 EDT
Description of problem:
While investigating another issue, I noticed that time_series table seems to retain all data even though the relevant systems and probes have long been deleted.  For example on this test Satellite with no monitoring probes whatsoever, time_series table can have 523844 rows due to past events.

Version-Release number of selected component (if applicable):


How reproducible:
Always.

Steps to Reproduce:
1. Enable Monitoring on a satellite, create and run some probes on some systems to accumulate some data.
2. Delete the probes and/or system profiles.
3. Look in time_series table.
  
Actual results:
Data still there.

Expected results:
Should it be cleaned up?  At least based on time, otherwise it seems it can grow without limitation.

Additional info:
Seeing this on at least 4.2.3 and 5.0.2 satellites.
Comment 1 Milan Zazrivec 2009-04-23 10:14:49 EDT
Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=494064
Comment 2 Milan Zazrivec 2009-04-29 05:44:01 EDT
spacewalk.git master:
58879eb2e8ce14ab8eb0978c7bc62699d42ca647
b6563aabd7370a09152379a8c7bed6359a026696
3a729bfabe3812587337ba650daecb9353303f65

spacewalk.git VADER:
6c8b1a2e436ec9adcca0dcf7a1f874a526162247
541e9e211958344d1338d2685d16bb772a8ffa6f
d8e8df4e94fd5d59b2ee89cea673001f14af8ee9

Relevant rows from time_series are being dropped when deleting
probe & deleting a server. Sadly enough, data from deleted probes
will still flow into time_series table until scout config push
is done.
Comment 3 Milan Zazrivec 2009-05-11 13:25:23 EDT
spacewalk-schema-0.5.20-10 & spacewalk-java-0.5.44-17
Comment 5 Milan Zazrivec 2009-06-05 05:47:00 EDT
Naturally, time_series table will still contain rows / data for other
created probes.

The key here is the O_ID column, which is a string formed in following
way: org_id-probe_id-probe_data_type (e.g. 1-1-pctlost, 1-2-pingtime).

probe_id can be easily read for example from web ui, when on monitoring
probe details page, look at probe_id=... parameter in the url bar.

The procedure to reproduce the issue here would be:
1) create couple of probes, do scout config push, wait for some probe
results
2) sqlplus into your database:
   SQL> select O_ID from time_series;
3) delete some probe in web ui
4) sqlplus into your database:
   SQL> select O_ID from time_series;

After the probe delete, the rows representing the deleted probe should
be gone (the fact that the table will receive new data for the deleted
probe until the next scout config push is not so relevant here).
Comment 7 Jan Pazdziora 2009-09-07 05:32:22 EDT
Stage validated with Satellite-5.3.0-RHEL5-re20090820.1. I had a system with two probes, one ping, one ssh:

SQL> select o_id, count(*) from time_series group by o_id ;

O_ID								   COUNT(*)
---------------------------------------------------------------- ----------
1-1-pingtime								822
1-1-pctlost								822
1-22-latency								  1

I've deleted the ping probe and the output is:

SQL> select o_id, count(*) from time_series group by o_id ;

O_ID								   COUNT(*)
---------------------------------------------------------------- ----------
1-22-latency								  1

I've deleted the system and the output is:

SQL> select o_id, count(*) from time_series group by o_id ;

no rows selected

SQL> 

Moving to RELEASE_PENDING.
Comment 8 Brandon Perkins 2009-09-10 14:48:46 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html

Note You need to log in before you can comment on or make changes to this bug.