---
title: ATP advanced features and intelligence layers
source: https://docs.newrelic.com/docs/opentelemetry/nrdot/atp/advanced-features
---

> #### 💡 PREVIEW
>
> We're still working on this feature, but we'd love for you to try it out!
>
> This feature is currently provided as part of a preview pursuant to our [pre-release policies](https://docs.newrelic.com/docs/licenses/license-information/referenced-policies/new-relic-pre-release-policy/).

ATP includes advanced intelligence layers that give you sophisticated, adaptive telemetry processing beyond simple threshold-based filtering.

## Advanced configuration options [#advanced-config]

You can add these **optional parameters** to your ATP processor configuration to enable advanced features.

**Dynamic thresholds**

### Dynamic thresholds [#dynamic-thresholds]

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

```yaml
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**

### Multi-metric composite scoring [#multi-metric-scoring]

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

```yaml
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**

### Anomaly detection [#anomaly-detection]

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

```yaml
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
```

## Complete advanced configuration example [#complete-example]

Here's a complete example with all advanced features enabled:

```yaml
processors:
  adaptivetelemetry:
    enable_storage: true
    retention_minutes: 30
    include_process_list:
      - "/usr/bin/postgres"
      - "/usr/sbin/nginx"
    metric_thresholds:
      process.cpu.utilization: 0.05
      process.memory.utilization: 0.05
    
    # All advanced features enabled
    enable_dynamic_thresholds: true
    dynamic_smoothing_factor: 0.2
    min_thresholds:
      process.cpu.utilization: 0.04
      process.memory.utilization: 0.04
    max_thresholds:
      process.cpu.utilization: 0.30
      process.memory.utilization: 0.30
    
    enable_multi_metric: true
    composite_threshold: 1.5
    weights:
      process.cpu.utilization: 0.5
      process.memory.utilization: 0.5
    
    enable_anomaly_detection: true
    anomaly_history_size: 15
    anomaly_change_threshold: 50.0
    anomaly_min_data_points: 3
```

## Configuration tuning guide [#tuning-guide]

The following sections explain each advanced configuration option in detail, along with guidance on how to tune them for your environment.

**Basic settings**

### 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

**Threshold settings**

### 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:**

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

**Metric thresholds**

### 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:**

```yaml
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**

### 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**

### 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**

### 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`

## Optimization strategy [#tuning-strategy]

**Getting started:**

1.  Begin with `metric_thresholds` only (disable dynamic/multi-metric/anomaly)
2.  Observe for 1-2 days, then adjust thresholds to reduce false positives
3.  Enable `enable_dynamic_thresholds` for variable workloads
4.  Add `enable_anomaly_detection` to catch sudden spikes
5.  Use `enable_multi_metric` if processes show correlated resource issues

**Common patterns:**

-   **Stable production services**: use static thresholds only
-   **Batch jobs**: use dynamic thresholds + anomaly detection
-   **Resource-intensive apps**: use multi-metric scoring
-   **Critical processes**: add to `include_process_list`

## Related resources [#related-resources]

[Troubleshooting](https://docs.newrelic.com/docs/opentelemetry/nrdot/atp/troubleshooting)

Learn how to troubleshoot ATP issues for your environment.

[Query your data](https://docs.newrelic.com/docs/opentelemetry/nrdot/atp/query)

Learn how to query ATP data in New Relic using NRQL.

[View your data](https://docs.newrelic.com/docs/opentelemetry/nrdot/atp/view-data)

Learn how to view the data collected by ATP in New Relic.