Script icon
Docker icon
If icon
SlackIncomingWebhook icon
Log icon
Return icon
Schedule icon

GCP Vertex AI Endpoint Traffic Split Discrepancy Guard

Audits Google Cloud Vertex AI model serving endpoints for skewed traffic splits and orphaned deployed models, alerting MLOps teams via Slack.

Categories
AICloud

Modern artificial intelligence platforms and machine learning engineering teams deploy production predictive models, embedding engines, and classification microservices to Google Cloud Vertex AI Model Serving endpoints. To support continuous deployment, canary testing, and A/B bakeoffs, Vertex AI endpoints allow hosting multiple deployed models behind a single unified HTTPS endpoint, distributing incoming inference traffic according to configurable integer percentages (e.g. 90% to baseline model, 10% to canary candidate). However, when automated CI/CD deployment pipelines fail mid-flight, canary models are undeployed without recalculating split weights, or unrouted models remain deployed consuming expensive GPU/TPU node quotas with 0% traffic allocation, inference budgets are squandered and user requests risk unhandled 404 or 503 routing failures. This sentinel interrogates Google Cloud Vertex AI endpoints hourly, inspects deployed model weights and traffic percentages, and notifies MLOps on Slack with remediation actions.

How it works

  1. Scheduled triggering: Executes hourly via automated cron trigger (0 * * * *) or runs on-demand via manual execution.
  2. Endpoint metadata inspection: Interrogates the Google Cloud AI Platform API using the google-cloud-aiplatform SDK to fetch endpoint details.
  3. Deployed model enumeration: Gathers all active model revisions bound to the target endpoint, recording model IDs and display names.
  4. Traffic split validation: Verifies that the sum of all traffic weights equals exactly 100% and identifies any deployed models receiving 0% traffic.
  5. Conditional alerting: An io.kestra.plugin.core.flow.If flowable checks if traffic splits are inconsistent and dispatches an alert to #mlops-serving-alerts.
  6. Manifest export: Emits a structured JSON audit payload detailing model weights and deployment parameters for MLOps governance.

Architecture diagram

flowchart TD
  A[hourly_vertex_traffic_audit Schedule Trigger] --> B[scan_vertex_traffic_split Python Script]
  B --> C[check_traffic_split_anomaly Flowable If]
  C -- Routing Discrepancy Found --> D[notify_slack_traffic_split_anomaly Webhook]
  C -- Model Routing Nominal --> E[log_serving_health_state Log]
  D --> E
  E --> F[export_vertex_manifest Return]

What you get

  • Proactive detection of stalled canary rollouts and unrouted candidate model deployments.
  • Identification of idle GPU and TPU machine resources driving unnecessary Google Cloud compute costs.
  • Contextual Slack alerts detailing active model IDs, current split percentages, and console triage links.
  • Structured JSON audit records tracking model serving evolution and production traffic routing over time.

Who it's for

  • Machine Learning Engineers (MLEs) managing real-time model serving and progressive canary rollouts.
  • MLOps Platform Teams maintaining shared Vertex AI endpoints across multiple data science units.
  • FinOps Practitioners optimizing cloud AI compute budgets and eliminating orphaned inference nodes.

Why orchestrate this with Kestra

Machine learning endpoint governance spans infrastructure monitoring, model artifact tracking, and team alerting. Kestra connects directly to the Google Cloud AI Platform Python SDK, executes containerized diagnostic scripts, validates complex multi-model routing states, and coordinates team notifications. With Kestra's containerized Python runner and native secret management, MLOps teams automate endpoint reliability without maintaining fragile custom cron scripts.

Use cases

  • Canary Promotion Verification: Verify that newly deployed model revisions receive expected experimental traffic shares post-deployment.
  • Orphaned Inference Node Reclamation: Spot models left deployed with 0% traffic that continue incurring machine hourly charges.
  • Inference Routing Stability: Prevent routing drift where traffic allocations do not total 100%, causing transient prediction request drops.

Inputs

Name Type Default Description
gcp_project_id STRING company-prod-mlops Google Cloud project identifier containing the Vertex AI serving endpoints.
gcp_region STRING us-central1 Google Cloud location where Vertex AI endpoints are deployed.
endpoint_id STRING 1234567890123456789 Numeric resource ID of the target Vertex AI model serving endpoint.
expected_primary_split_min_percent INT 80 Minimum acceptable traffic split percentage allocated to the primary baseline model.
alert_on_discrepancy BOOL true Whether to dispatch automated Slack alerts when traffic split percentages deviate from safe deployment baselines.

Expected outputs

  • {{ outputs.scan_vertex_traffic_split.vars.endpoint_name }}: Display name of the evaluated Vertex AI endpoint.
  • {{ outputs.scan_vertex_traffic_split.vars.deployed_models_count }}: Count of active model revisions deployed to the endpoint.
  • {{ outputs.scan_vertex_traffic_split.vars.has_discrepancy }}: Boolean flag indicating whether routing discrepancies were detected.
  • {{ outputs.export_vertex_manifest.value }}: Structured dictionary containing the consolidated Vertex AI serving diagnostic manifest.

Prerequisites

  • Outbound HTTPS network access from Kestra execution workers to Vertex AI API endpoints (*-aiplatform.googleapis.com).
  • A GCP Service Account JSON key configured with roles/aiplatform.viewer permissions.
  • A Slack Incoming Webhook URL configured in Kestra secrets.

Secrets

  • GCP_SERVICE_ACCOUNT_KEY: Service account credentials JSON with permissions to inspect Vertex AI endpoints.
  • SLACK_WEBHOOK_URL: Slack Incoming Webhook URL used to dispatch MLOps serving alerts.

Quick start

  1. Register GCP_SERVICE_ACCOUNT_KEY and SLACK_WEBHOOK_URL in your Kestra secret storage.
  2. Import this blueprint into your Kestra instance under the company.ai namespace.
  3. Update gcp_project_id, gcp_region, and endpoint_id with your target Vertex AI endpoint parameters.
  4. Run a manual execution to test Vertex AI API connectivity and verify the output manifest format.

Common pitfalls and troubleshooting

  • Regional Endpoint Routing: Vertex AI requires specifying the exact region (e.g. us-central1, europe-west4); incorrect regions return 404 Not Found errors.
  • Service Account Permissions: Ensure the service account has aiplatform.endpoints.get and aiplatform.endpoints.list permissions.
  • Empty Traffic Split: When a model is first deployed without specifying traffic split, traffic defaults to an empty dictionary until explicitly configured.

How to extend

  • Automated Canary Traffic Promotion: Trigger an automated task to incrementally advance canary model traffic from 10% to 50% upon healthy inference validation.
  • Orphaned Model Undeploy: Automatically undeploy models that have received 0% traffic for more than 7 days to eliminate idle compute spend.
  • Multi-Endpoint Organization Audit: Wrap the evaluation in an io.kestra.plugin.core.flow.ForEach loop to scan all Vertex AI endpoints across the ML platform.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.