Schedule icon
Webhook icon
Request icon
Get icon
Script icon
Docker icon
Set icon
If icon
SlackIncomingWebhook icon
Log icon

Triton Inference Server Model Repository Drift & GPU Queue Sentinel

Detect NVIDIA Triton model repository drift and GPU queue saturation from Prometheus metrics with Kestra KV tracking and Slack alerts.

Categories
AIInfrastructure

Continuously monitors NVIDIA Triton Inference Server deployments for model repository version drift and GPU queue saturation. The workflow polls Triton's KServe v2 health endpoints (/v2/health/ready, /v2/models/{model_name}/ready) and scrapes Prometheus telemetry (/metrics), calculating rolling p95 queue wait times, inference latency, throughput, and GPU VRAM utilization. Historical baselines and drift state are persisted in Kestra's built-in KV store, with rich operational alerts dispatched to Slack upon SLA violations.

How it works

  1. Dual Scheduling & CI/CD Triggering: Triggers automatically on a 10-minute cadence (ten_minute_sentinel), or via an authenticated webhook (on_model_rollout) triggered by model registry promotion pipelines or Kubernetes rollout webhooks.
  2. Health and Model Readiness Probing: Issues low-latency HTTP GET requests to Triton's KServe v2 endpoints: /v2/health/ready to verify daemon liveness and /v2/models/{model_name}/ready to check model serving state.
  3. Repository Metadata Inspection: Queries /v2/models/{model_name} to retrieve active loaded versions and compare them against the desired expected_model_version, detecting silent version rollbacks or missed updates.
  4. Prometheus Telemetry Scrape: Queries /metrics to collect hardware and execution counters: cumulative request duration (nv_inference_request_duration_us), queue duration (nv_inference_queue_duration_us), inference counts (nv_inference_count), pending request queues (nv_inference_pending_request_count), and GPU memory counters (nv_gpu_memory_used_bytes, nv_gpu_memory_total_bytes).
  5. Stateful Telemetry Computation: Retrieves prior metric baselines from Kestra's KV store (triton_model_metrics_{model_name}). A Dockerized Python task calculates delta rates, request throughput (RPS), average and p95 queue wait durations, and p95 inference latency.
  6. GPU Saturation & Drift Evaluation: Detects queue buildup (queue wait > threshold ms or pending request surge) and GPU memory exhaustion (> threshold %). Classifies operational status into NOMINAL_HEALTHY, MODEL_REPOSITORY_DRIFT, GPU_QUEUE_SATURATED, or SERVER_UNHEALTHY.
  7. KV Store Update & Tiered Alerting: Writes updated telemetry back into Kestra KV store. If an anomaly or saturation is discovered, dispatches a formatted Slack notification with key performance indicators and remediation context. Nominal runs log verification metrics.

What you get

  • Early Detection of Model Drift: Instantly catches configuration discrepancies when a model repository fails to load the intended weights or version.
  • GPU Queue Saturation Warning: Detects batch scheduling bottlenecks and queue pileups before requests time out or user-facing latency degrades.
  • Accurate Rate-Based Percentiles: Derives true interval throughput and p95 latencies by tracking cumulative Prometheus counters across successive evaluations.
  • Zero External Database Overhead: Uses Kestra's internal Key-Value (KV) store to maintain historical telemetry baselines without requiring external Redis or Prometheus servers.
  • Actionable Incident Notifications: Delivers rich Slack alert attachments highlighting affected models, version mismatches, queue wait times, and GPU memory saturation.

Who it's for

  • MLOps & AI Platform Engineers operating NVIDIA Triton Inference Server clusters on Kubernetes, Slurm, or bare-metal GPU nodes.
  • Site Reliability Engineers (SREs) maintaining inference latency SLAs and autoscaling policies for mission-critical deep learning APIs.
  • Computer Vision & NLP Teams serving dynamic batching models (e.g., TensorRT, ONNX Runtime, PyTorch) seeking continuous visibility into queue depth.

Why orchestrate this with Kestra

Monitoring high-throughput inference runtimes requires coordinating standard KServe v2 HTTP calls, Prometheus exposition text parsing, persistent delta calculation, and multi-channel alerting. Scripting this in external crons creates brittle dependencies, unmanaged credentials, and loss of execution audit trails. Kestra combines HTTP probing, containerized Python analysis, native KV state management, and declarative Slack alerting into a repeatable, auditable workflow.

Prerequisites

  • NVIDIA Triton Inference Server (23.x+ or 24.x+) exposing HTTP API (default port 8000) and Prometheus metrics (default port 8002).
  • A Kestra 2.0+ deployment with Docker task runner enabled.
  • A Slack Incoming Webhook URL for operational incident dispatch.

Secrets

  • SLACK_WEBHOOK_URL: Slack Incoming Webhook URL for alerting on model drift, GPU queue saturation, or server downtime.
  • TRITON_WEBHOOK_KEY: Secret authentication key guarding the on-demand webhook trigger for CI/CD rollouts.

Quick start

  1. Create the SLACK_WEBHOOK_URL and TRITON_WEBHOOK_KEY secrets in your target Kestra namespace.
  2. Import this blueprint under your preferred namespace (e.g., company.ai).
  3. Adjust triton_http_endpoint and triton_metrics_endpoint to point to your Triton server hostname or Kubernetes service DNS (e.g., http://triton-inference.ml.svc.cluster.local:8000).
  4. Execute the flow manually to record initial KV telemetry and verify endpoint connectivity.
  5. Enable the ten_minute_sentinel schedule trigger for continuous automated surveillance.

How to extend

  • Automated Pod Autoscaling: Trigger a Kubernetes HPA or KEDA scaling event via io.kestra.plugin.kubernetes.job.Create when GPU queue saturation is detected.
  • Dynamic Model Reload: Send a Triton repository reload command (POST /v2/repository/models/{model_name}/load) via io.kestra.plugin.core.http.Request upon discovering version drift.
  • PagerDuty Incident Escalation: Add io.kestra.plugin.pagerduty.notifications.PagerDutyAlert to the notification branch to page on-call SREs for sustained queue saturation.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.