Dell PowerProtect Data Manager extension
- Latest Dynatrace
- Extension
- Published Oct 27, 2025
Ingest metrics, activities, and other logs from PowerProtect Data Manager.
Get started
Overview
PowerProtect Data Manager is a data protection software designed to secure modern workloads including backups, dev/test re-use, protecting cloud native applications, centralized governance and control, and self-service backup and restore.
Use the Dynatrace Dell PowerProtect Data Manager extension to collect performance and health data about your PowerProtect Data Manager deployment and get insights into activities, alerts, and audit logs.
Use cases
- Monitor overall system health to identify issues that can affect performance or reliability
- Monitor configuration changes
- Extract Dynatrace problem events from PowerProtect alert or health issue records
- Monitor the states of your storage systems
Requirements
-
A PowerProtect instance with the PowerProtect Data Manager REST API reachable from ActiveGates
-
A user with the "User" or "readonly" role
Compatibility information
This extension uses the PowerProtect Data Manager REST API.
Activation and setup
Find Dell PowerProtect Data Manager in the in-product Extensions or Hub page and activate it. If offline, you can download the extension from the Hub page in the Versions section and install as a custom extension.
Monitoring configuration
Once the extension is activated in your environment, you can create monitoring configurations. Each monitoring configuration can have one PowerProtect instance.
-
Select the desired ActiveGate group that will run the monitoring configuration.
- Host
- Authentication
- Username & password (credential vault is supported)
- Verify SSL (can be disabled if monitoring a local instance with a self-signed certificate)
- Activities
- Collection interval (0 to disable)
- Collect failed job group activites
- Collect completed with warnings job group activites
- Audit logs
- Collection interval (0 to disable)
- System issues
- Collection interval (0 to disable)
- Alerts
- Collection interval (0 to disable)
- Collect warning severity alerts (in addition to critical)
- Filter by time
- If Filter by time is disabled, reporting will be based on the "acknowledgement" state of the alert within PowerProtect. So this will result in any unacknowledged alerts continuing to be reported (can be used to keep extracted problems open).
- If Filter by time is enabled, we will only report alerts that occurred during that monitoring interval (based on the postedTime of the alert).
- Log level
-
Metrics
Review the list of feature sets to see which metrics are collected. Metrics are related to the overall system health and storage system statuses.
-
Log events
Many types of records from PowerProtect are ingested into Dynatrace in the form of log events. These log events can be manually reviewed as well as used in log event extraction and metric configurations. The following types of records can be ingested:
-
An activity represents a long running asynchronous execution in the system. It can represent a group of jobs, a single job, or a single task. These will have a 'record_type' attribute of 'activity'.
-
Audit log tracks configuration modification activity from users. These will have a 'record_type' attribute of 'audit_log'.
-
An issue affecting the health of the PowerProtect system. These events can affect the overall system health score. These will have a 'record_type' attribute of 'system_health_issue'.
-
Alerts enable you to track the performance of data protection operations in PowerProtect Data Manager so that you can determine whether there is compliance to service level objectives. These will have a 'record_type' attribute of 'alert'.
-
-
Log processing rules
One log processing rule is included that will extract and create a new column (vm.name) from log events for patterns of logs that include a virtual machine name in their content.
Details
Licensing and cost
There is no charge for obtaining the extension, only for the data (metrics & events) that the extension ingests. The details of license consumption will depend on which licensing model you are using. This will either be Dynatrace classic licensing or the Dynatrace Platform Subscription (DPS) model.
Metrics
License consumption is based on the number of metric data points ingested. The following formula will provide approximate annual data points ingested assuming all feature sets are enabled:
Calculation estimates yearly DDU usage:
(15 + <number_of_protection_engine_proxies>) * 525.6
Log records
The number of reported log records will be based on how many audit logs, activities, alerts, and system health issues occur.
Log management and analytics (powered by Grail)
License consumption is based on the size (in bytes) of data ingested & processed, retained, and queried so there is not a single formula to estimate the total consumption from this extension. Consult the log management and analytics documentation for details on the other dimensions that will effect license consumption.
-
Classic licensing
In the classic licensing model, log record ingestion will consume Davis Data Units (DDUs) at the rate of 100 DDUs per Gigabyte of log records ingested.
Log monitoring classic
In log monitoring classic, license consumption is based on the number of ingested log records.
-
Classic licensing
In the classic licensing model, log record ingestion will consume Davis Data Units (DDUs) at the rate of .0005 DDUs per ingested log record.
Multiply estimated ingested log records by .0005 to estimate DDU usage from log records.
Feature sets
When activating your extension using monitoring configuration, you can limit monitoring to one of the feature sets. To work properly the extension has to collect at least one metric after the activation.
In highly segmented networks, feature sets can reflect the segments of your environment. Then, when you create a monitoring configuration, you can select a feature set and a corresponding ActiveGate group that can connect to this particular segment.
All metrics that aren't categorized into any feature set are considered to be the default and are always reported.
A metric inherits the feature set of a subgroup, which in turn inherits the feature set of a group. Also, the feature set defined on the metric level overrides the feature set defined on the subgroup level, which in turn overrides the feature set defined on the group level.
| Metric name | Metric key | Description |
|---|---|---|
| Storage system status count (fair) | ppdm.storage.summary.fair | — |
| Storage system status count (good) | ppdm.storage.summary.good | — |
| Storage system status count (poor) | ppdm.storage.summary.poor | — |
| Storage system status count (total) | ppdm.storage.summary.total | — |
| Metric name | Metric key | Description |
|---|---|---|
| Availability | ppdm.availability | — |
| System health score | ppdm.system_health.score | — |
| System health status | ppdm.system_health.status | — |
| Metric name | Metric key | Description |
|---|---|---|
| Protection Engine Proxy Status | ppdm.protection_engine.proxy.status | — |
