ATP advanced features and intelligence layers

Dynamic thresholds

This feature automatically adjusts thresholds based on your system's historical behavior, helping you catch anomalies while reducing false positives.

processors:
  adaptivetelemetry:
    # ... existing config ...
    # Dynamic threshold configuration
    enable_dynamic_thresholds: true
    dynamic_smoothing_factor: 0.2
    min_thresholds:
      process.cpu.utilization: 0.04  # Can't go below 4%
      process.memory.utilization: 0.04  # Can't go below 4%
    max_thresholds:
      process.cpu.utilization: 0.30  # Can't exceed 30%
      process.memory.utilization: 0.30  # Can't exceed 30%

Multi-metric composite scoring

This evaluates multiple metrics together to give you a holistic view of process health, catching processes that are problematic across multiple dimensions.

processors:
  adaptivetelemetry:
    # ... existing config ...
    # Multi-metric configuration
    enable_multi_metric: true
    composite_threshold: 1.2
    weights:
      process.cpu.utilization: 0.5
      process.memory.utilization: 0.5

Anomaly detection

This detects sudden metric spikes above historical averages, helping you catch processes that have gone rogue or experienced unexpected behavior changes.

processors:
  adaptivetelemetry:
    # ... existing config ...
    # Anomaly detection configuration
    enable_anomaly_detection: true
    anomaly_history_size: 15
    anomaly_change_threshold: 50.0  # 50% spike triggers anomaly
    anomaly_min_data_points: 3

Basic settings

• enable_storage: Enable persistent storage for historical metric data. This is required for persistence across restarts.

  • Default: true
  • Storage paths are automatically determined by the platform:
    • Linux: /var/lib/nrdot-collector/adaptiveprocess.db
    • Windows: %LOCALAPPDATA%\nrdot-collector\adaptiveprocess.db

• retention_minutes: How long (in minutes) to keep tracking a process after it last exceeded a threshold.

  • Default: 30 (max: 30)
  • Tuning: Use lower values (5-10) for short-lived processes; keep at 30 for stable workloads

Include process list

The include_process_list is a list of processes that always bypass all filters and get reported regardless of thresholds.

• Use case: Critical processes you always want to monitor (for example, database, web server)
• Security: Use full paths (/usr/bin/postgres) with separators such as /usr/bin/postgres. Entries without path separators such as "postgres" won't match any process.

Example:

include_process_list:
  - "/usr/bin/postgres"  # Always include PostgreSQL
  - "/usr/sbin/nginx"    # Always include Nginx

Metric thresholds

The metric_thresholds are static threshold values for each metric. A process gets flagged when it exceeds this value.

How to optimize:

• Start with baseline values from your average workload
• Increase thresholds to reduce noise for fewer alerts
• Decrease thresholds to catch smaller anomalies
• For utilization metrics (CPU/memory): Use percentages (0.0-1.0 = 0%-100%)
• For count metrics (threads, file descriptors): Use absolute numbers

Example values explained:

metric_thresholds:
  process.cpu.utilization: 0.0005      # 0.05% CPU - very sensitive
  process.memory.utilization: 0.0005   # 0.05% memory - very sensitive
  process.memory.virtual: 20971520     # 20 MB virtual memory
  process.threads: 16                  # 16 threads
  process.open_file_descriptors: 30    # 30 open files
  process.disk.io: 204800              # 200 KB disk I/O
  process.cpu.time: 0.01               # 0.01 seconds CPU time

Dynamic thresholds

Automatically adjusts thresholds based on historical behavior. Useful for processes with varying workload patterns.

• enable_dynamic_thresholds: Turns on adaptive threshold adjustment.

  • When to enable: Processes with fluctuating behavior, such as batch jobs, API servers
  • When to disable: Processes with stable, predictable behavior

• dynamic_smoothing_factor: How quickly thresholds adapt (0.0-1.0).

  • Lower (0.1): Slow adaptation, more stable (good for gradual changes)
  • Higher (0.5): Fast adaptation, more responsive (good for volatile workloads)
  • Default: 0.2 (balanced)

• min_thresholds: Floor values - thresholds won't drop below these. This is used to prevent thresholds from becoming too sensitive.

• max_thresholds: Ceiling values - thresholds won't exceed these. This is used to prevent thresholds from becoming too lenient.

Multi-metric scoring (composite scoring)

Evaluates multiple metrics together rather than individually. Useful for catching processes that are "bad actors" across multiple dimensions.

• enable_multi_metric: Enables composite scoring.

  • When to enable: Want to catch processes that are problematic in multiple ways (high CPU + high memory)
  • When to disable: Want to alert on individual metric violations

• composite_threshold: The combined score threshold. A process is flagged when: (weighted sum of metrics) > composite_threshold.

  • Lower (0.5): More sensitive, catches marginal cases
  • Higher (2.0): Less sensitive, only catches significant issues
  • Default: 1.5

• weights: Importance of each metric in the composite score. The higher the weight, the more influence the metric has.

Anomaly detection

This detects sudden spikes or unusual behavior by comparing current values against historical patterns.

• enable_anomaly_detection: Turns on spike detection.

  • When to enable: To catch sudden changes (process gone rogue)
  • When to disable: For absolute thresholds

• anomaly_history_size: Number of recent data points to keep for calculating baseline average.

  • Larger (50-100): Smoother baseline, catches bigger anomalies
  • Smaller (5-15): More responsive, catches smaller spikes
  • Default: 10 (max: 100)

• anomaly_change_threshold: Percentage spike above historical average to trigger an alert.

  • Example: 50.0 = flag if current value is 50% higher than average
  • Lower (20-50): More sensitive to changes
  • Higher (100-200): Only catch dramatic spikes
  • Default: 200.0

• anomaly_min_data_points: Minimum historical data points before anomaly detection activates.

  • This prevents false positives during startup
  • Recommended: Keep at 3 (default)
  • Must be ≤ anomaly_history_size