Python ONTAP health and volume inventory scripts

01Install dependencies and edit inventory

1. Download daily-health.py, inventory-report.py, ontap_api.py, requirements.txt and inventory.csv into the same working directory. Use Python 3.10 or later, create a virtual environment, and install requests. Keep the helper alongside both scripts.
2. Replace sample documentation addresses with actual cluster management IP addresses. The Python helper deliberately accepts literal IPv4 or IPv6 addresses in inventory; if your TLS certificate uses a DNS identity, adapt the helper validation to allow your approved hostnames. Prepare a read-only REST identity and the CA PEM file if an internal CA signs the cluster certificate.
3. The helper checks pagination links before requesting another page and retains the original cluster host. All REST calls use timeouts; credentials are requested at the terminal unless your job supplies ONTAP_PASSWORD through a protected secret-injection mechanism.

python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
cat inventory.csv

02Run daily health and interpret results

1. Run with your ONTAP account and an optional CA bundle. The script prompts for the password without echoing it. It writes a timestamped CSV in reports/ and exits 1 when any cluster has WARN or ERROR. Threshold defaults to 85 percent and can be changed from 1 to 99.
2. Node state must be up; volumes must be online; aggregate physical block storage and volume space usage are tested against the threshold. A SnapMirror relationship with healthy=false is a warning. Investigate missing collections, unexpected lag, HA status and EMS alerts separately: these example checks do not cover them.
3. Status ERROR is captured per cluster, allowing the next cluster to run. Review the error detail and fix certificate trust, authorization, endpoint availability or firewall access before relying on the output. Do not send credentials as command-line arguments or disable TLS verification.

python daily-health.py --inventory inventory.csv --username monitor --ca-bundle /etc/ssl/certs/ontap-ca.pem --threshold 85 --out-dir reports
head -n 5 reports/health-*.csv

03Export volumes and schedule a daily run

1. Run inventory-report.py with the same inventory, user and CA bundle. It exports every returned volume as Cluster, SVM, Volume, State, SizeGiB and UsedGiB. It stops on an API failure to avoid presenting an incomplete list as complete.
2. For a daily unattended Linux run, provision a protected secret source that injects ONTAP_PASSWORD into the job at execution time, such as your existing secrets manager. Restrict the job account, report directory and environment exposure. Set the scheduler at the desired local time and monitor nonzero exit codes and stale reports.
3. For example, a service-account cron entry can invoke /opt/ontap/.venv/bin/python /opt/ontap/daily-health.py --inventory /opt/ontap/inventory.csv --username monitor --out-dir /var/log/ontap-reports. This only runs unattended when the password is supplied securely by the job environment; the interactive password prompt otherwise blocks it.

python inventory-report.py --inventory inventory.csv --username monitor --ca-bundle /etc/ssl/certs/ontap-ca.pem --out volume-inventory.csv
head -n 5 volume-inventory.csv

04Worked case: make an incomplete health run visible

Fictional report at 08:00. Two clusters respond; the third times out while volume pages are being collected. Preserve successful results from other clusters, but do not classify the incomplete inventory as healthy or empty.

1. Record expected targets separately from successful responses. For every target, keep timestamp, failed stage and a short sanitized error category.
2. Treat partial pagination as incomplete coverage. Keep partial counts labelled as partial, and never use them as a full inventory denominator.
3. Report collection failures alongside storage findings. A timeout means the collector could not establish status; investigate reachability, certificates and service health before deciding the cluster is down.
4. After restoring collection, rerun the failed target and confirm all checks and pages complete. Compare counts with the previous complete run and retain the original failure record.