[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.

[abonillabeeche]

Thanks @craffit, makes sense. Happy to mark it experimental and move it under 3rd-party technologies whenever you settle on the layout. Just point me at the convention.

[aacevedoosorio]

@abonillabeeche, the contribution flow is ready: Portworx stays in contrib as an opt-in community integration. We tested validation, packaging, installation and local Helm delivery with your unchanged pack.

Please:

1. Refresh this branch with current main to run the new per-pack CI.
2. Add Maintainer: @github-handle to the pack README.
3. Mark the README and user-facing overview as experimental, as discussed above, and state that community maintainers own support and updates.
4. Document removal and the tested SUSE Observability version. If applicable, document the permissions needed to create the ServiceMonitor and update the agent configuration.

CONTRIBUTING.md covers ownership. The repository README covers installation.

For adding the image through Helm, see the StackPack installation docs, which explain stackstate.stackpacks.extraImages.

After approval and merge, CI publishes the individual image to Quay. Customers add it through Helm or upload its .sts package, and the product lists it under Third-party StackPacks.

I also left one inline question about the Volume down query's handling of missing metrics. We reproduced that case with synthetic data; we did not test real Portworx alert behavior.

[abonillabeeche]

Thanks both — pushed 85140db covering everything:

1. Merged current main in (clean merge, no conflicts; the diff against main now only touches stackpacks/portworx/).
2. Added Maintainer: @abonillabeeche to the README.
3. Marked the README, overview and detailed overview experimental/community-maintained, with support/update ownership on me.
4. Added "Required permissions" (ServiceMonitor create/get/list, agent Helm-values change) and "Removing the integration" sections, plus the tested SUSE Observability platform version (2.12.0, via sts context validate against our sa-experimental tenant).

On the inline question: not intentional, and I can't promise Portworx always emits both metrics together, so I fixed the query instead of just documenting an assumption. The original + does a PromQL inner join on (k8s_cluster_name, volumename), so a volume reporting only px_volume_status or only px_volume_state dropped out of the result entirely — exactly the silent-miss you found. The query now does (A + B) or A or B (clamped to 1) so either metric alone still triggers "Volume down". Verified the new query parses and the pack validates (stack-pack-validator, 33 nodes). I haven't re-run this specific case against a real Portworx cluster yet — still synthetic/logical verification like your own test — happy to do that if you'd like it before merge.