---
title: Monitor and troubleshoot ATP
source: https://docs.newrelic.com/docs/opentelemetry/nrdot/atp/troubleshooting
---

> #### 💡 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/).

Learn how to verify ATP is working correctly and troubleshoot common configuration issues across host and Kubernetes environments.

## Verify ATP is working [#verify-atp]

After installing ATP, verify that New Relic is receiving process data by running these queries in the [query builder](https://docs.newrelic.com/docs/query-your-data/explore-query-data/query-builder/introduction-query-builder/):

**Host environments**

-   To view recent process metrics:
    ```sql
    FROM Metric SELECT *
    WHERE metricName LIKE 'process.%'
    LIMIT 100
    ```

-   To count unique process metric types:
    ```sql
    FROM Metric SELECT uniqueCount(metricName)
    WHERE metricName LIKE 'process.%'
    ```

**Kubernetes environments**

-   To view recent process metrics for your cluster:
    ```sql
    FROM Metric SELECT *
    WHERE k8s.cluster.name='your-cluster-name'
    AND metricName LIKE 'process.%'
    LIMIT 100
    ```

-   To count unique process metric types for your cluster:
    ```sql
    FROM Metric SELECT uniqueCount(metricName)
    WHERE k8s.cluster.name='your-cluster-name'
    AND metricName LIKE 'process.%'
    ```

## Troubleshoot ATP issues [#troubleshoot]

**ATP not filtering metrics**

**Problem**: All process metrics are being sent, not filtered.

**Host environment solutions**

1.  Verify ATP is in the pipeline processors list.
2.  Check whether `metric_thresholds` are configured.
3.  Ensure process metrics are being collected.
4.  Review collector logs for ATP initialization errors.

**Kubernetes environment solutions**

1.  Verify ATP is enabled:
    ```bash
    kubectl get configmap -n newrelic nr-k8s-otel-collector-daemonset-config -o yaml | grep adaptivetelemetry
    ```

2.  Check ATP is in the pipeline: Look for `adaptivetelemetry` in the `metrics/nr` pipeline

3.  Verify you're using the correct collector image:

    ```bash
    kubectl get daemonset -n newrelic nr-k8s-otel-collector-daemonset -o yaml | grep "image:"
    ```

    Expected: `newrelic/nrdot-collector:11.0` (or later)  
    **NOT**: `newrelic/nrdot-collector-k8s:1.11.0`

4.  **Verify `enable_atp` is set to `true`** in your `values.yaml` or ConfigMap

**High memory usage**

**Problem**: Collector memory increases over time

**Solution**: Adjust retention settings:

```yaml
processors:
  adaptivetelemetry:
    retention_minutes: 15  # Reduce from default 30
```

**Processes not being captured**

**Problem**: Expected processes are missing from telemetry

**Solution**: Must use full path to add processes to include list. Entries without path separators won't match any process. For example:

```yaml
processors:
  adaptivetelemetry:
    include_process_list:
      - "/usr/bin/myapp"  # Always captured regardless of thresholds
```

**ATP data stopped populating**

**Problem**: Earlier, ATP data was shown but now it is not. This could be due to hitting cardinality limits. ATP filters out many processes to reduce telemetry volume, but if you have a very high number of unique processes, you could still hit limits. You can [monitor your cardinality usage](https://docs.newrelic.com/docs/data-apis/ingest-apis/metric-api/monitor-cardinality/) to track this.

**Solution**:

To troubleshoot, check whether you've hit cardinality limits by going to the [cardinality management page](https://docs.newrelic.com/docs/data-apis/ingest-apis/metric-api/cardinality-management/#per-metric-limit-adjustment) in New Relic. If you've breached limits, you can increase your [cardinality limit](https://docs.newrelic.com/docs/data-apis/ingest-apis/metric-api/cardinality-management/#per-metric-limit-adjustment).

> #### 💡 TIP
>
> If this is a recurring issue, you can also increase ATP's `metric_thresholds` to filter out more processes and reduce the volume of incoming metrics. This will help prevent hitting cardinality limits in the future. For example, you could increase the CPU and memory utilization thresholds to only capture more resource-intensive processes:
>
> ```yaml
> processors:
>   adaptivetelemetry:
>     metric_thresholds:
>       process.cpu.utilization: 0.10  # Increase from 0.05 to 0.10 (10% CPU)
>       process.memory.utilization: 0.10  # Filter out more processes
> ```

**Storage path or permission issues**

**Problem**: ATP logs show storage-related errors or warnings about being unable to create storage directories.

**Solution**:

ATP automatically selects and creates storage directories based on your installation method. If storage fails, verify the following:

1.  **For systemd installations**: Ensure the service is running as the `nrdot-collector` user and the systemd service file includes the `StateDirectory` directive:
    ```bash
    sudo systemctl cat nrdot-collector.service | grep StateDirectory
    ```
    Expected output: `StateDirectory=nrdot-collector`

2.  **For manual binary installations**: Verify your user has write permissions to `~/.local/state/`:
    ```bash
    mkdir -p ~/.local/state/nrdot-collector
    touch ~/.local/state/nrdot-collector/test && rm ~/.local/state/nrdot-collector/test
    ```

3.  **Check collector logs** for storage-related messages:
    ```bash
    sudo journalctl -u nrdot-collector | grep -i storage
    ```

> #### ⚠️ IMPORTANT
>
> If ATP cannot create or access storage, it automatically disables persistence and continues operating with in-memory state only. ATP's retention feature continues to work normally during the collector's runtime, but the tracking state will be lost on collector restarts since it's not saved to disk.

## Configuration requirements [#config-requirements]

**Storage and persistence configuration**

ATP automatically manages storage paths based on your installation method:

**For systemd service installations (DEB/RPM packages):**

-   Storage is automatically configured at `/var/lib/nrdot-collector/`
-   The systemd service uses `StateDirectory` to create and manage the directory
-   No manual configuration required

**For manual binary installations:**

-   Storage uses `~/.local/state/nrdot-collector/` for regular users
-   No root privileges required for storage
-   Directory is automatically created if writable

> #### 💡 TIP
>
> If storage cannot be created (for example, due to permission issues), ATP automatically disables persistence and continues operating with in-memory state only. The retention feature works normally during runtime, but tracking state is lost on collector restarts. Check collector logs if you need to verify storage status.

**Enable disk.io data**

To enable `disk.io` data collection by the OpenTelemetry hostmetrics receiver, you need escalated privileges because the io data stored at `/proc/[PID]/io` requires root user access. This is not an ATP requirement, ATP only processes data that's already been collected by OpenTelemetry.

Add the following security context to your Helm chart:

```yaml
securityContext:
  allowPrivilegeEscalation: true
  privileged: true
  readOnlyRootFilesystem: false
  runAsNonRoot: false
  runAsUser: 0
```

## Related resources [#related-resources]

[Advanced-features](https://docs.newrelic.com/docs/opentelemetry/nrdot/atp/advanced-features)

Learn how to enable advanced features for your ATP deployment.

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

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