Example: two lab clusters at 192.0.2.10 and 192.0.2.11. A Linux monitoring host uses an SSH key and a dedicated ONTAP account with only the read commands it needs. The script writes one timestamped text report per cluster and exits nonzero on connection or command failure. It does not infer that a cluster is healthy just because SSH succeeded.
Commands and screens can differ by release and platform. Replace example names and documentation IP addresses. Check prerequisites, impact, current health and rollback with your change owner.
1. Prepare access and the inventory
- Download daily-health.sh and inventory.csv below to one directory. Replace the documentation IPs with the cluster-management IPs or hostnames approved in your environment. The inventory header must be Cluster,Address; use simple unique names without spaces.
- Create a dedicated monitoring identity using your organization’s ONTAP role policy. Grant the minimum read access needed for cluster show, storage failover show, system health alert show, storage aggregate show, volume show and snapmirror show. Test each command interactively before scheduling.
- Install the monitoring host public SSH key for that identity by your approved access workflow. Connect interactively to each cluster once to verify the SSH host key fingerprint against a trusted source and populate known_hosts. Do not disable host-key checking. Keep the private key restricted to the monitoring service account.
Cluster,Address
lab-a,192.0.2.10
lab-b,192.0.2.11SSH from the monitoring host runs each read-only command against both clusters without a password and with verified host keys.
2. Run the collector and read its output
- Run the script from the directory containing the inventory. Pass the inventory path and report directory explicitly. The first argument defaults to inventory.csv, and the second to reports. ONTAP_SSH_USER selects the ONTAP login; no password is embedded.
- Each report contains the UTC timestamp and six command sections. Review system health alert show for active alerts; cluster show for node eligibility; storage failover show for takeover readiness; storage aggregate show and volume show for capacity; snapmirror show for replication state and lag. Compare observations with your approved per-workload limits.
- The script returns 1 when a command fails or an inventory row is invalid, 2 for missing inputs, and 0 when commands completed. A zero exit code proves collection completed, not that every metric is acceptable.
chmod 700 ./daily-health.sh
ONTAP_SSH_USER=monitor ./daily-health.sh ./inventory.csv ./reports
ls -ltr ./reportsTwo timestamped reports appear; review each command output and confirm no ERROR section.
3. Schedule once daily and investigate exceptions
- Choose a local operations window and timezone. In a service-account crontab, use absolute paths for the script, inventory, report directory and SSH key configuration. Keep stdout/stderr in a protected log. The example runs at 07:00 host local time.
- Check the scheduled task exit status and report age daily. Set an external alert from your scheduler or monitoring platform on nonzero exit or stale reports. Establish a separate rule for health alerts, utilization and lag because the Bash example collects raw output. Rotate reports under your retention policy.
- If authentication fails, check the key and ONTAP account role; if host-key verification fails, verify the new fingerprint before updating known_hosts; if only one command fails, test its role permission on that ONTAP version. Never put a password in the crontab.
0 7 * * * ONTAP_SSH_USER=monitor /opt/ontap/daily-health.sh /opt/ontap/inventory.csv /var/log/ontap-reports >> /var/log/ontap-collector.log 2>&1Next scheduled run produces fresh reports for all listed clusters and monitoring notices a missing or failed run.