Monitoring and metrics are essential for understanding whether the OpenShift platform, Portworx storage layer, and FlashArray backend are healthy, efficient, and predictable. In a mixed VM and container environment, monitoring should do more than prove that individual components are up. It should help operators correlate issues across layers and detect trends before they become incidents.
This section focuses on GUI-first operational monitoring, with an emphasis on how Prometheus, Grafana, Portworx, and FlashArray telemetry work together.
Prometheus Metrics from FlashArray and Portworx
Prometheus metrics provide the day-to-day visibility needed to understand whether storage and platform behavior remain within expected operating boundaries. In this environment, the most important metrics are not just raw counters, but the ones that help correlate application symptoms to storage and platform state.
Key metrics to monitor from both platforms
| FlashArray Metrics | Portworx Metrics |
|
|
Operational indicators for performance, availability, and capacity
Useful indicators include:
pool utilization trends
abnormal growth in consumed capacity
rising storage latency
degraded volume count
increased provisioning failures
unusual node-specific storage behavior
imbalance across nodes or arrays
Monitoring should allow operators to spot drift, not just outages.
Grafana Dashboard Setup
Grafana is most useful when it helps operators visualize the relationship between the OpenShift platform, the Portworx storage layer, and the FlashArray backend in one operational view. Rather than maintaining isolated dashboards for each technology, administrators should aim for dashboards that make topology and dependency relationships obvious.
Building dashboards that map OpenShift, Portworx, and FlashArray topology together
A strong operational dashboard should help answer questions such as:
which worker nodes are serving which storage roles
whether a Portworx issue is node-specific or cluster-wide
whether a FlashArray performance change aligns with workload symptoms
whether capacity pressure is isolated or systemic
whether a transport issue is affecting only a subset of workloads
Topology-aware dashboards reduce troubleshooting time because they connect symptoms across layers
Recommended dashboard views for operators
Recommended dashboard categories include:
cluster and node health
Portworx cluster summary
pool capacity and utilization
volume health and attachment state
FlashArray capacity and performance
transport path health indicators
VM and PVC operational dependencies
Operators should be able to move from a red alert to a likely fault domain quickly.
Alerting for Storage Path Failures
Storage path failures should be detected before they become application-facing outages. In FlashArray-backed OpenShift environments, alerting should cover not only full connectivity loss, but also degraded redundancy and early indicators of transport instability.
Detecting FC or iSCSI path issues early
Alerting should help operators detect when:
FC paths have been reduced unexpectedly
iSCSI sessions have dropped or become unstable
NVMe/TCP path or subsystem connectivity has degraded
only a subset of storage-serving nodes is affected
VM or PVC behavior is starting to reflect path problems
Alert design for multipath degradation and backend connectivity failures
For FC and iSCSI environments, alerts should focus on:
reduced path count
host-level multipath degradation
storage node behavior inconsistent with the rest of the cluster
volume attachment anomalies tied to transport issues
For NVMe/TCP environments, alerts should focus on:
subsystem connectivity loss
transport instability on storage-facing nodes
namespace visibility issues
backend access anomalies that affect only part of the environment
Portworx Autopilot for Capacity Management
Portworx Autopilot helps automate capacity-related operations so that administrators can respond to growth before it causes provisioning failures or workload impact. Used correctly, it reduces manual intervention and improves platform resilience.
Using Autopilot to automate growth and capacity Handling
Autopilot can be used to:
expand PVCs based on thresholds
trigger storage growth actions before pools become critically full
reduce the need for emergency manual expansion
enforce repeatable capacity behavior across workloads
Safe operational boundaries and review practices
Autopilot should not be enabled without clear boundaries. Administrators should define:
which workloads are allowed to expand automatically
which thresholds trigger action
how much growth is allowed in one action
whether approvals or observation windows are required
who monitors the results after expansion