Bug 461704

Summary:	Monitoring probes data in time_series table are not cleaned up when probes/system profiles are deleted
Product:	Red Hat Satellite 5	Reporter:	Xixi <xdmoon>
Component:	Monitoring	Assignee:	Milan Zázrivec <mzazrivec>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Preethi Thomas <pthomas>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	423	CC:	jpazdziora, xdmoon
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	sat530	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-09-10 18:48:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	463877

Description Xixi 2008-09-10 00:35:50 UTC

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 Zázrivec 2009-04-23 14:14:49 UTC

Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=494064

Comment 2 Milan Zázrivec 2009-04-29 09:44:01 UTC

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 Zázrivec 2009-05-11 17:25:23 UTC

spacewalk-schema-0.5.20-10 & spacewalk-java-0.5.44-17

Comment 5 Milan Zázrivec 2009-06-05 09:47:00 UTC

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 09:32:22 UTC

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 18:48:46 UTC

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