Telemetry to Pure1

Telemetry, also called callhome, is a built-in support feature in PX-CSI. When enabled, PX-CSI sends cluster diagnostics, node metadata, and PX-CSI pod logs to Pure1. This data helps Pure Support proactively identify issues, correlate patterns across fleets, and accelerate root cause analysis.

PX-CSI deploys two types of telemetry components in the portworx namespace:

• The px-pure-csi-telemetry DaemonSet runs one pod per node. It collects telemetry data, compresses logs, and securely uploads them to Pure1.
  Each pod contains the following containers:

  • telemetry: Collects node-specific cluster metadata and telemetry payloads.
  • log-upload-service: Compresses and uploads controller and node plugin logs.
  • envoy: Acts as an HTTPS proxy for outbound telemetry traffic.

• The px-pure-csi-telemetry-registration Deployment runs as a single pod in the cluster. It registers the cluster with Pure1 and manages authentication and certificates.
  The pod contains the following containers:

  • telemetry: Coordinates registration operations and handles certificate rotation.
  • registration: Sends cluster identity and configuration to Pure1.
  • envoy: Handles HTTPS communication during registration.

important

Telemetry does not include workload or application data.

Data collected by telemetry

PX-CSI telemetry collects system metadata from the cluster and sends it to Pure1. The payload is structured as a JSON document and includes the following fields:

• Cluster identity

  • ClusterID: Internal PX cluster identifier.
  • ClusterUUID: Unique cluster identifier used across Pure1 and telemetry.

• Cluster status and metadata

  • Status: Numerical code representing overall cluster health.
  • ManagementURL: URL for out-of-band cluster management, if configured.

• Node information

  Each node entry contains:

  • Id: Internal PX node ID.
  • SchedulerNodeName: Kubernetes node name.
  • Cpu: CPU usage as a float (for example, 0.6 = 60%).
  • MemTotal: Total memory in bytes.
  • MemUsed: Used memory in bytes.
  • MemFree: Free memory in bytes.
  • Avgload: Load average at the time of snapshot.
  • MgmtIp and DataIp: IP addresses used for PX control and data planes.
  • Timestamp: Timestamp of the telemetry snapshot.
  • StartTime: PX service start time on the node.
  • NodeLabels: Includes:
    • Kernel Version
    • OS
    • PX Version
    • containerRuntime
    • kubeletVersion

• Storage backends

  Each backend array includes:

  • ID: Unique identifier for the backend.
  • Family: Product family (FlashArray or FlashBlade).
  • BackendType: Storage type (block or file).
  • PurityVersion: Version of Purity OS on the backend.
  • Model: Array model string.

• Component versions

  The ClusterImageVersions section reports PX-CSI sidecar versions:

  • OperatorVersion
  • CSINodeDriverRegistrarVersion
  • CSIProvisionerVersion
  • CSIAttacherVersion
  • CSIResizerVersion
  • CSISnapshotterVersion
  • TelemetryVersion

• Volume and snapshot data

  • Volumes: List of volumes deployed by PX-CSI.
  • LocalSnapshots: Number of volume snapshots present in the cluster.

Enable telemetry

Telemetry is enabled by default. If you disabled it during installation, follow these steps to enable it and verify that it's working.

1. Edit the StorageCluster specification to enable telemetry.

   StorageCluster

   ...
   spec:
     monitoring:
       telemetry:
         enabled: true
   ...

   Additional configuration for air-gapped clusters

   In air-gapped clusters, telemetry is supported through a simple or traditional proxy configured to use HTTP mode. If you use a next-generation firewall as a proxy, or if you experience issues with telemetry configuration, contact Portworx Support.

   To enable telemetry, configure a proxy and add it to the PX_HTTP_PROXY or PX_HTTPS_PROXY environment variable in your StorageCluster specification. Telemetry communicates through the specified proxy.

   StorageCluster

   ...
   spec:
     env:
       - name: PX_HTTP_PROXY
         value: "http://<IP:port>"
       - name: PX_HTTPS_PROXY
         value: "http://<IP:port>"
   ...

   After saving and applying the change, the Portworx Operator deploys telemetry pods in the portworx namespace.

2. Check that telemetry pods are running.

   kubectl get pods -n portworx | grep telemetry

   You should see output similar to the following:

   px-pure-csi-telemetry-ftph9                           3/3     Running   0          23m
   px-pure-csi-telemetry-q474h                           3/3     Running   0          23m
   px-pure-csi-telemetry-registration-659fbf8bd4-cqzww   3/3     Running   0          23m
   px-pure-csi-telemetry-zz9lt                           3/3     Running   0          23m

   You should see multiple pods named px-pure-csi-telemetry-* and one named px-pure-csi-telemetry-registration-*. All pods must be in the Running state, and each should show 3/3 containers ready.

3. Run the following command to check log upload activity.

   kubectl -n portworx logs pod/<telemetry-pod-name> -c log-upload-service --tail=100

   Look for lines indicating log bundle uploads, such as:

   Upload status 200
   Uploaded: /logs/csi-driver-node-2025-xxxx.tar.gz ...

Disable telemetry

To disable telemetry, set the spec.monitoring.telemetry.enabled field to false in the StorageCluster specification:

spec:
  monitoring:
    telemetry:
      enabled: false

After applying the change, the Portworx Operator removes the telemetry components from the cluster.