[abonillabeeche]

Summary

Adds a portworx StackPack for Portworx Enterprise 3.x on Kubernetes.

Data path. No Prometheus server is needed:

• Metrics: the agent's OpenTelemetry scraper reads a ServiceMonitor labelled observability.suse.com/agent: scrape on the Portworx service (px-api, :9001/metrics).
• Topology: the agent's k8s resource collector sends the StorageCluster and StorageNode CRs (core.libopenstorage.org).

Topology.

• A portworx cluster component per StorageCluster.
• Each StorageNode merges into its Kubernetes node, through additionalIdentifiers and ranked below the Kubernetes source, so the node keeps type node.
• Portworx volumes merge into their Kubernetes persistent volumes. They're driven by px_volume_replication_status, the only volume metric reported for every volume.
• Relations: node member of cluster, volume provided by cluster.

Presentations. A Portworx main menu group with Clusters, Storage nodes and Volumes lists, plus a Portworx metrics tab on each of the three component kinds:

• capacity (including volumes in the trashcan)
• quorum and nodes
• KVDB
• license
• latency, IOPS, throughput, long I/Os per volume
• pools and disks
• replication / HA level

Monitors. 20 monitors, each with a remediation hint that uses pxctl commands checked against 3.7.1. Most port the Portworx operator's PrometheusRule with Portworx's thresholds:

• Volume usage above 70% / 80%; volume replication unhealthy; volume down or in error; filesystem health 2 (safe to fix) / 3 (needs inspection).
• Storage node usage above 70% / 80%; storage that will fill within 14 days.
• Node not OK; KVDB unhealthy (node view).
• Pools: offline, full or not found; degraded; nearly full per pool. "Nearly full" means free space below 1.5x Portworx's own full limit of min(10%, 100 GiB), which catches one pool filling while the node total looks fine. Maintenance (4) and background activity (6) are not alerted on.
• Storage node down; member down; quorum unhealthy; KVDB unhealthy (cluster view).
• License expiring; license invalid.

Dashboards. Cluster overview, Volumes and Nodes and pools, modelled on the Portworx Grafana dashboards.

Setup (in resources/configuration.md):

1. exportMetrics: true on the StorageCluster.
2. Apply the so-agent-portworx ServiceMonitor. Its labelkeep drops the PVC labels Portworx copies onto every volume series, which would otherwise create many series.
3. Add core.libopenstorage.org to otel.k8sResourceCollector.crDiscovery.apiGroups.include.
4. Install the StackPack.

Testing

Tested on Portworx 3.7.1 (operator, internal KVDB) on a 3-node RKE2 / SUSE Virtualization cluster, with agent chart 1.6.12:

• stack-pack-validator from the CI image passes (33 nodes).
• Deployed with sts stackpack test-deploy:
  • 1 cluster component; 3 storage nodes merged into the Kubernetes nodes; Portworx volumes merged into their PVs.
  • Relations resolved.
  • All monitors bound to their components (CLEAR on a healthy cluster).
• Every presentation, list column, summary and dashboard query was run against the live data.
  • The only ones that come back empty are KVDB watch p99 and "Missing replicas", and both are empty because nothing is wrong.

Notes:

• Volume performance metrics exist only while a volume is attached.
• px_volume_reads_total / px_volume_writes_total carry only volumeid, so per-volume IOPS use the *_iops gauges.

Coverage was checked against Portworx's alert reference (https://docs.portworx.com/portworx-enterprise/reference/portworx-alerts) and its Grafana dashboards. Stork, Autopilot and KVDB/etcd metrics (:9091, :9628, :9019) need extra scrapes and are left for a follow-up.

[craffit]

@abonillabeeche Thanks for contributing. We are still getting used to the stackpacks flow and have to figure out in what way this will land in the product, who will review.

Merging this as is would put it on equal footing with our current stackpacks, but prooably we want to first mark this experimental and list this under 3rd party technologies, we'll keep you posted.