Storage Admin Hub
All guides/Automation
Automation · Automation guide

Daily ONTAP health check with Bash and SSH

Collect read-only cluster, HA, alerts, capacity, volume and SnapMirror output from every inventory entry; schedule and review it daily.

By Hrishikesh Naik3 min read
Scope

Educational ONTAP 9 example. Confirm platform, protocol and release compatibility in the linked documentation.

Scenario

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.

About the command and output examples

Names, addresses and results are illustrative. Commands have not been executed against a live storage system or SAN switch for this publication. Confirm syntax and compatibility for your release, then rehearse in an approved lab. Existing-data recovery and destructive changes need an environment-specific plan. Read the editorial standards.

01Prepare access and the inventory

  1. 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.
  2. 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.
  3. 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.
Example inventory.csv 
Cluster,Address
lab-a,192.0.2.10
lab-b,192.0.2.11
Acceptance check

SSH from the monitoring host runs each read-only command against both clusters without a password and with verified host keys.

02Run the collector and read its output

  1. 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.
  2. 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.
  3. 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.
Linux monitoring host 
chmod 700 ./daily-health.sh
ONTAP_SSH_USER=monitor ./daily-health.sh ./inventory.csv ./reports
ls -ltr ./reports
Acceptance check

Two timestamped reports appear; review each command output and confirm no ERROR section.

03Schedule once daily and investigate exceptions

  1. 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.
  2. 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.
  3. 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.
Example service-account 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>&1
Acceptance check

Next scheduled run produces fresh reports for all listed clusters and monitoring notices a missing or failed run.

Continue learning

Use the section links to revisit a step, or follow a related guide below.

Download examples

Official references and further reading

Choose the matching release in the vendor documentation before using a command or design. References open on the publisher’s website; linked material remains with its publisher.