PowerShell Scripting via Nano

Step 1 – Implement Windows-Specific System Monitoring Logic

Here we have the initial creation and structure of a cross-platform monitoring script written in PowerShell Core (pwsh and edited on a Linux system.

This step represents the foundational setup of the monitoring script before platform-specific logic and metrics are added.

Scrolling down, the Windows branch of the script collects system telemetry using CIM-based queries for processor load, memory consumption, filesystem usage, and network addressing, and uptime.

Each query is fault-tolerant, ensuring the script remains operational even when individual data points are unavailable.

Step 2 – Implement Linux-Specific System Monitoring Logic

Here, we have the Linux execution branch of the monitoring script, where system metrics are collected using native Linux utilities and kernel interfaces.

CPU usage is gathered by first checking for the presence of mpstat, and if unavailable, falling back to directly parsing /proc/stat.

Ths layered approach ensures compatibility across minimal and full Linux installations. Memory and additional system metrics are handled within the same Linux-specific branch, maintaining consistency with the overall script structure.

By isolating Linux logic in its own conditional block, the script preserves cross-platform portability while respecting the differences between Windows and Linux system internals. This design reflects real-world systems administration practices, where tooling must remain resilient across varied Linux environments.

Continuing through the Linux branch, the script collects additional system health metrics using standard Linux command-line utilities.

Memory usage is calculated by parsing the output of free -m, allowing total, used, and available memory to be derived in a predictable format.

Disk usage is gathered using df -h, providing filesystem-level capacity and utilization data.

Network information is retrieved via hostname -I to capture the system's primary IP address, and system uptime is collected using uptime -p for human-readable runtime value.

Each metric is wrapped in a try/catch block to ensure fault tolerance, allowing the script to continue executing even if a specific command or data source is unavailable. This approach mirrors real-world monitoring practices, where resilience and continuity are prioritized over perfect data collection.

Step 3 – Build and Export a Unified Monitoring Report

All collected system metrics are consolidated into a single PowerShell object ([PSCustomObject, creating a normalized report structure that includes the timestamp, operating system, CPU usage, memory statistics, disk usage, IP address, and system uptime. This object acts as a consistent data model regardless of whether the script is executed on Windows or Linux.

An output directory is then created relative to the script’s location if it does not already exist, ensuring reports are stored in a predictable and portable location. Finally, the report is exported in both JSONand CSV formats, making the data suitable for logging, auditing, automation pipelines, or ingestion by external monitoring and analysis tools.

This design reflects real-world systems administration practices by separating data collection from data storage and ensuring monitoring output is structured, durable, and reusable.