Problem/Motivation

The monitoring_sensor_result entity is written on every non-cached sensor run when monitoring.settings:sensor_call_logging is set to all, and on every status change when set to on_request. There is no built-in retention or cleanup: the table grows unbounded. monitoring_cron() only runs sensors (monitoring.module, around line 576), it never prunes old rows, and no Drush command is shipped for this either.

On sites with many sensors and short cron intervals, this accumulates rapidly — especially in all mode, which is useful when correlating sensor history with incidents but currently makes the table too expensive to keep enabled for long.

Steps to reproduce

  1. Install Monitoring, set Monitoring event logging to Log all events.
  2. Enable Run sensors during cron runs and let cron run for a while.
  3. Inspect SELECT COUNT(*) FROM monitoring_sensor_result — grows linearly with time × enabled sensor count.

Proposed resolution

Add a Result retention setting to monitoring.settings (integer, in days, with 0 meaning "keep forever") and a prune step in monitoring_cron() that deletes monitoring_sensor_result entities with timestamp < now - retention_days * 86400. An index on timestamp in the entity schema keeps the delete cheap.

Expose the setting in MonitoringSettingsForm alongside the existing logging toggles.

Remaining tasks

  • Add result_retention_days to monitoring.settings.yml (default 0) and schema.
  • Extend MonitoringSettingsForm with the new field.
  • Add an index on timestamp in SensorResultEntity::baseFieldDefinitions() (and a hook_update_N to apply it to existing installs).
  • Implement the prune in monitoring_cron().
  • Kernel test covering both "0 = keep forever" and "prune past N days".

User interface changes

One new number field on the monitoring settings form.

API changes

New monitoring.settings:result_retention_days config key. No behavioural change when left at the default 0.

Data model changes

New index on monitoring_sensor_result.timestamp. Optional hook_update_N to install the index on existing sites.

Issue fork monitoring-3586550

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

mably created an issue. See original summary.

mably’s picture

Status: Active » Needs review