fix(monitoring): prevent double-counting partition I/O in disk stats (#5385)

[fliptrigga13]

Summary

Fixes #5385

Problem

In /proc/diskstats, Linux reports I/O metrics for both whole physical block devices (e.g. sda, nvme0n1, vda, mmcblk0) and their constituent partitions (e.g. sda1, sda2, nvme0n1p1, vda1). Because the whole-device counters already aggregate all read and write traffic across all its partitions, iterating over all devices returned by osutils.disk.stats() and summing their readBytes and writeBytes caused every byte of disk activity to be counted twice in Dokploy host monitoring.

Solution

• Introduced shouldIncludeDiskStat(device: string, allDevices: string[]):
  1. Filters out virtual pseudo-devices (loop*, ram*, sr*, fd*).
  2. Detects partition suffix patterns (p\d+$ for digit-bearing parents like nvme0n1p1 / mmcblk0p1 / md0p1, and \d+$ for letter-bearing parents like sda1 / vda1).
  3. If a partition row's parent disk is present in allDevices, the partition row is skipped to avoid double-counting.
  4. If only the partition is present (common in certain restricted containers or virtualized setups), the partition stats are preserved.
• Added comprehensive unit test suite in apps/dokploy/__test__/monitoring/disk-stats-double-count.test.ts covering NVMe, SCSI/SATA, MMC, MD, virtual disks, and standalone partition fallback scenarios (5/5 tests passing).

Confidence Score: 4/5

The production change appears safe to merge, with a non-blocking test-quality issue that weakens regression protection.

Summary

• Adds partition-parent detection for common SATA, virtio, NVMe, MMC, and MD naming schemes.
• Applies the filter while aggregating node-os-utils disk statistics.
• Adds representative test cases, although they currently exercise a copied helper rather than production code.

_{Reviews (1) · Last reviewed commit: "fix(monitoring): prevent double-counting..."}

[greptile-apps]

Tests Duplicate Production Logic

This test recreates shouldIncludeDiskStat instead of exercising the exported production implementation. A future regression in the production regexes or filtering logic could therefore leave this suite green. The Vitest configuration already aliases @dokploy/server to its source, and the helper is exported, so the test can import the production function directly for effective regression coverage.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!