Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Build a prometheus-collector CCP test image, deploy it to an AKS standalone, and validate metric scraping and ingestion into Azure Monitor.
allowed-tools
["Bash","Read","Write","Grep","Glob"]
Prom-Collector Buddy-Build Standalone
Overview
This skill verifies that a new CCP component's managed Prometheus addon functions correctly by deploying a prometheus-collector test image into an AKS standalone environment. It automates the full end-to-end flow:
Building a CI/dev CCP image from a prometheus-collector branch.
Creating a standalone environment and test cluster.
Patching the ama-metrics-ccp deployment with the test image.
Validating metric scraping and ingestion into Azure Monitor.
When to Use
You have a prometheus-collector PR/branch with CCP changes (new scrape targets, config changes, etc.).
You need to validate CCP metrics ingestion end-to-end before merging.
You want to test in an isolated standalone environment rather than staging.
Repository Setup
This skill requires the prometheus-collector repo. Ask the user for their local checkout path.
VPN connection to MSFT-AzVPN-Manual (for aksdev operations)
aksdev binary (built or downloaded via the create-standalone skill)
kubectl installed
Inputs
Input
Description
Example
PROM_COLLECTOR_BRANCH
The prometheus-collector branch to test
user/my-ccp-feature
USER_ALIAS
Your Microsoft alias
dakydd
STANDALONE_NAME
Name of an existing standalone (if reusing)
standalone-260216bm47nl
Helper Script
The skill includes a helper script at tools/check_build.py that checks a prometheus-collector pipeline build for the CCP ORAS push stage status and extracts the image tag.
Run the build and wait for the ORAS Push Artifacts in /mnt/vss/_work/1/a/linuxccp/ stage inside Build: linux CCP prometheus-collector image to succeed.
Note: The pipeline can show as failed overall. You can continue as long as the ORAS push stage succeeded.
az account set -s $SUBSCRIPTION_ID
az aks update --enable-azure-monitor-metrics --enable-control-plane-metrics -n $AKS_CLUSTER_NAME -g $RESOURCE_GROUP# Note: --enable-control-plane-metrics requires the aks-preview CLI extension
az aks get-credentials -n $AKS_CLUSTER_NAME -g $RESOURCE_GROUP -f $AKS_CLUSTER_NAME.kubeconfig
Step 4: Create a Test Cluster with the Addon Enabled
Set environment variables:
export USER_ALIAS=<your-alias>
export WORKFLOW_NAME=buddybuild-standalone
export CX_CLUSTER_NAME=$USER_ALIAS-$WORKFLOW_NAMEexport MC_SUB=82acd5bb-4206-47d4-9c12-a65db028483d
export LOCATION=<standalone-location> # Must match standalone location
Note: All four must be scaled down. The eno-reconciler manages underlay deployment specs and will scale the other reconcilers back to 1 if left running.
Step 6: Identify and Annotate the CCP Namespace
Find the CCP namespace (starts with 6):
kubectl get ns --kubeconfig $AKS_CLUSTER_NAME.kubeconfig
export CCP_NS=<ccp-namespace-id>
Or delete the standalone entirely (auto-deletes after 3 days).
Why do we have to manually update the cx-1 underlay?
In standalone, we use a trick to get the ama-metrics-ccp pod an MSI token for ingestion to a real Azure Monitor workspace. The "cluster" created via aksdev isn't a real AKS cluster — it only exists within the standalone. There's no MSI token available for it.
However, the standalone underlay itself (the cx-1 cluster) is a real AKS cluster. We enable the AMA Metrics addon on cx-1, which gives it permission to ingest to an Azure Monitor workspace. We then configure the ama-metrics-ccp pod to use the cx-1 cluster's resource ID via the CLUSTER env var, which allows the addon-token-adapter to obtain the correct MSI token.
