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.
Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=494064
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.
spacewalk-schema-0.5.20-10 & spacewalk-java-0.5.44-17
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).
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.
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