Data Model Changes#

The alerting system has introduced significant updates to its data models, specifically the Alert struct and the AlertingConfig configuration.

Alert Struct Updates#

The Alert struct now includes two new fields: detection_rule_id and deduplication_key (source).

• detection_rule_id is a string identifier for the detection rule that triggered the alert. This field enables precise rule identification and supports correlation across alerts.
• deduplication_key is a string constructed as <severity>:<detection_rule_id>:<title>. It uniquely identifies alerts for deduplication purposes within the alerting system.

Example construction:

let deduplication_key = format!("{severity}:{detection_rule_id}:{title}");

The struct derives Serialize and Deserialize traits, ensuring that both new fields are included in JSON and YAML representations.

AlertingConfig Enhancements#

AlertingConfig now includes the recent_threshold_seconds field (source). This field determines the time window (in seconds) for considering an alert as "recent", with a default value of 3600 seconds (1 hour). This parameter influences deduplication and prioritization logic in the detection engine.

Serialization and Formatting#

Alerts are serialized and deserialized using the serde library, with both detection_rule_id and deduplication_key included in all output formats (source). Supported formats include JSON, YAML, CSV, and a human-readable string. For example, the human-readable format displays:

[severity] detection_rule_id - title: description

Example JSON serialization:

{
  "id": "uuid",
  "severity": "High",
  "title": "CPU spike",
  "description": "High CPU usage observed",
  "detection_rule_id": "rule-123",
  "deduplication_key": "High:rule-123:CPU spike",
  ...
}

Detection Engine Logic#

The detection engine and AlertManager now use detection_rule_id and deduplication_key for enhanced deduplication and alert correlation (source).

• Alerts are suppressed if an alert with the same deduplication_key was delivered within the deduplication window (dedup_window_seconds, default 300 seconds).
• The recent_threshold_seconds parameter from AlertingConfig is used to determine if an alert is recent, affecting prioritization and deduplication.
• The detection engine leverages these fields to avoid duplicate alerts and to correlate alerts triggered by the same rule.

Example deduplication logic:

if self.is_duplicate(alert) {
    // Suppress duplicate alert
    return Ok(vec![]);
}

Configuration Usage#

Configuration parameters can be set in configuration files or overridden via environment variables.

• recent_threshold_seconds can be set in the config file under the [alerting] section or overridden with the environment variable {COMPONENT}_RECENT_THRESHOLD_SECONDS (source).
• The deduplication window (dedup_window_seconds) is configurable in the same section.

Example YAML configuration:

alerting:
  recent_threshold_seconds: 1800
  dedup_window_seconds: 600

Example environment variable override:

export DAEMONEYE_RECENT_THRESHOLD_SECONDS=1200

Testing Guidance#

Testing for the updated alerting system should cover serialization, deduplication, configuration, and alert delivery (source, source).

• Unit tests should verify that alerts serialize and deserialize correctly with all fields, including detection_rule_id and deduplication_key.
• Tests should confirm that deduplication logic suppresses duplicate alerts within the configured window.
• Tests for is_recent and is_recent_with_config should validate alert recency calculations for various thresholds.
• Integration tests should exercise alert delivery to sinks in all supported formats and confirm configuration overrides via environment variables.

Example unit test for deduplication:

let results1 = manager.send_alert(&alert).await.unwrap();
let results2 = manager.send_alert(&alert).await.unwrap();
assert_eq!(results1.len(), 1);
assert_eq!(results2.len(), 0); // Duplicate suppressed

Example unit test for configuration:

let config = AlertingConfig::default();
assert_eq!(config.recent_threshold_seconds, 3600);

let custom_config = AlertingConfig { recent_threshold_seconds: 1800, ..Default::default() };
assert_eq!(custom_config.recent_threshold_seconds, 1800);

System Architecture Diagram#

This diagram illustrates the flow from detection to alert management, deduplication, and delivery, with configuration influencing deduplication and recency logic.