Page last updated:
This topic describes the VMware Customer Experience Improvement Program (CEIP) and the Pivotal Telemetry Program (Telemetry) used in the Enterprise PKS tile.
The CEIP and Telemetry program allow VMware and Pivotal to collect data from customer installations to improve your Enterprise PKS experience. Collecting data at scale enables us to identify patterns and alert you to warning signals in your Enterprise PKS installation.
You can configure Enterprise PKS to use one of the following CEIP and Telemetry participation levels:
None: This level disables data collection.
Standard: (Default) This level collects data anonymously. Your data is used to inform the ongoing development of Enterprise PKS.
Enhanced: This level enables VMware and Pivotal to warn you about security vulnerabilities and potential issues with your software configurations. For more information, see Benefits of the Enhanced Participation Level below.
Note: Enterprise PKS does not collect any personally identifiable information (PII) at either participation level. For a list of the data Enterprise PKS collects, see Data Dictionary.
For information about configuring CEIP and Telemetry participation, see the CEIP and Telemetry section of the installation topic for your IaaS:
- Installing Enterprise PKS on vSphere
- Installing Enterprise PKS on vSphere with NSX-T
- Installing Enterprise PKS on AWS
- Installing Enterprise PKS on Azure
- Installing Enterprise PKS on GCP
Benefits you receive with the Enhanced participation level include but are not limited to the following:
- Usage data: This gives you access to data about Kubernetes pod and cluster usage in your Enterprise PKS installation. See sample reports below for more details.
- Access to your telemetry data: This gives you access to configuration and usage data about your Enterprise PKS installation. See sample reports below for more details.
- Proactive support: This enables VMware and Pivotal to proactively warn you about unhealthy patterns.
- Benchmarks: This is your usage relative to the rest of the Enterprise PKS user base.
The table below compares the Standard and Enhanced participation levels.
|Benefit||Standard Level||Enhanced Level|
|Usage data||Raw data||Reports and trend analysis|
|Access to your telemetry data||No||Yes|
Note: VMware and Pivotal reserve the right to change the benefits associated with the Enhanced participation level at any time.
The CEIP and Telemetry programs use the following components to collect data:
Telemetry Server: This component runs on the PKS control plane. The server receives telemetry events from the PKS API and metrics from Telemetry agent pods. The server sends events and metrics to a data lake for archiving and analysis.
Telemetry Agent Pod: This component runs in each Kubernetes cluster as a deployment with one replica. Agent pods periodically poll the Kubernetes API for cluster metrics and send the metrics to the Telemetry server.
The following diagram shows how telemetry data flows through the system components:
For information about PKS Telemetry collection and reporting, see the PKS Telemetry Data spreadsheet, hosted on Google Drive.
- Consumption: As an Operator of PKS, I need a way to monitor pod consumption across my PKS environments over time, so I can:
- See which environments and clusters get the heaviest use
- See temporal patterns in pod consumption
- Scale capacity accordingly
- Show and charge back users of PKS within my organization
- API heartbeats + Cluster heartbeats: As an Operator of PKS I need a way to see the version of PKS each of my environments was running over time, so I can:
- Keep track of all my PKS environments and clusters
- Identify environments and clusters in need of upgrading
- Cluster creation events: As an Operator of PKS I want to see how often cluster creation succeeds across my PKS environments, so I can:
- Identify environments that encounter repeated failures and debug or intervene as appropriate to avoid frustration for cluster admins and users
- Cluster creation duration: As an Operator of PKS I want to see how long it takes to create clusters, so I can:
- Intervene when cluster creation significantly more time than expected, and adjust my plan and network configuration as appropriate
- Cluster creation errors: As an Operator of PKS, I want to see what errors are being encountered most frequently during cluster creation so I can:
- Quickly identify widespread problems and remediate (e.g. NSX errors)
- Container images: As an Operator of PKS, I want to see which container images are in use across my PKS installations so I can:
- Conduct an audit of container images and identify prohibited or problematic images
- Infer which workloads are running on PKS, to inform my planning, resourcing, and outreach
Please send any feedback you have to email@example.com.