Captured Metrics

Architecture and Design¶

DMC collects only the data needed for cloud migration and modernisation planning. Every command it runs inside a guest is listed on the platform pages below, so the collection can be reviewed before anything is uploaded.

Choose a platform to view detailed collection logic:

Available Metrics¶

Performance metric collection¶

The lookback window and sampling method depend on the scan type. Neither is configurable in DMC.

How DMC reduces a metric series to one value¶

A VMware scan returns about 360 samples per counter per VM. DMC reduces each series to a single sizing figure before writing the result. vCenter reports CPU and memory usage in hundredths of a percent, so every sample is first divided by 100.

1. DMC works out the standard deviation of the whole series, which measures how much usage swings around over the 30 days.
2. For each sample it estimates the 95th percentile of usage around that point, using the sample as the centre and the series standard deviation as the spread. Each sample is replaced by this higher value. The wider the swings, the further above the original the new value sits.
3. It takes the mean and standard deviation of those raised values and estimates the 95th percentile from them once more. That number, rounded to two decimals, is the reported value.

The estimate uses a curve that cannot go below zero, since utilisation cannot be negative, rather than a symmetric bell curve. A series of all zeros reports 0. A constant series has no spread, so it reports that constant. The same reduction is applied to the disk and network throughput series.

How vCenter stores performance data¶

vCenter does not log performance to a file. Each ESXi host samples its VMs every 20 seconds and keeps about one hour of those samples in memory. vCenter polls the hosts and rolls the samples up into four historical intervals in its database. The defaults are:

What this means for a DMC scan:

• A 30-day lookback lands on the 1 Month interval, so DMC receives one average every 2 hours, about 360 points per counter per VM. A spike that lasted minutes is smoothed into the surrounding average. That is why sizing from this data should be validated for critical workloads.
• Statistics level 1 stores the VM-level CPU and memory counters DMC uses, cpu.usage and mem.usage. The disk and network counters DMC requests are per virtual disk and per network adapter, and vCenter only stores those at level 2 or higher. For any counter not stored at the configured level, DMC falls back to the last hour of 20-second real-time samples, so that metric covers one hour rather than 30 days.
• vCenter only holds data for objects it managed during the window. A VM that was powered off, migrated in, or on a host that was disconnected for part of the 30 days has a gap for that period.
• Raising the level or the retention in vCenter only affects data collected from that point on. It does not backfill history.

To check or change the settings, select the vCenter in the vSphere Client and go to Configure > Settings > General > Statistics. To see what a VM has stored, select it and go to Monitor > Performance > Advanced, then pick a time range.

Azure and AWS scans read performance history from Azure Monitor and CloudWatch. See Azure Metrics and AWS Metrics for their lookback settings.

Network connection snapshot¶

The Network scan mode captures active connections and listening ports once, at the moment the script runs inside the guest. It does not monitor traffic over time. On Windows the script uses Get-NetTCPConnection, or netstat -ano where that cmdlet is unavailable. On Linux it uses netstat or ss. A connection that is idle at that moment is not recorded.

What DMC does not collect¶

DMC collects environment-level metadata only. None of the guest scripts read or export the following:

• Local user accounts, group memberships, or logged-on users
• Active Directory objects, or any directory query
• Windows event log or Linux system log contents
• File contents, file listings, or share paths
• Scheduled tasks or cron jobs
• Certificates or private keys
• Application data or database contents

Two entries in the command inventories are easy to misread. The Error Diagnostics category is DMC's own timestamped scan log, written by the collection script, and is not an operating system event log. On Linux, ls is used only to resolve the binary path of a running process through /proc for the dependency map, not to list user files.

The process list captured for the dependency map records the process name, ID and binary path. It does not record which user account runs the process.

Architected for Enterprise Environments¶

To meet the demands of complex, security-sensitive environments, DMC has been designed with a robust, modular architecture that balances efficiency, traceability, and safety. The following controls have been incorporated to ensure reliable operation at scale without compromising security or system stability:

Performance Management¶

• Built-in throttling for retries and timeouts on WMI and registry operations
• Optimized queries to minimize system load
• Output files are validated and kept lightweight

Security Best Practices¶

• Credentials are held in memory only, never written to disk
• Output files are protected by local access controls
• Registry and file system paths are validated prior to access
• Logs are sanitized to prevent any accidental data exposure

Recovery & Fault Tolerance¶

• Graceful fallback handling for WMI and registry errors
• Robust, timestamped logging to aid diagnostics
• Safe retry logic for handling transient issues

Scalable, Modular Design¶

• Modular command structure supports efficient execution
• Output is categorized into debug, results, and logs for clarity
• Fully compatible with Windows Server editions via PowerShell validation