Skip to content

test(otel): add SGLang solution integration tests - #797

Open
Aakash-Dantre wants to merge 1 commit into
aws:mainfrom
Aakash-Dantre:feat/otel-llm-serving-sglang
Open

Aakash-Dantre wants to merge 1 commit into
aws:mainfrom
Aakash-Dantre:feat/otel-llm-serving-sglang

Conversation

@Aakash-Dantre

@Aakash-Dantre Aakash-Dantre commented Nov 3, 2026 •

Copy link
Copy Markdown
Contributor

Summary

End-to-end tests for the SGLang model-server solution and the shared KServe model-server discovery in aws-observability/helm-charts#418, with vLLM and SGLang running side by side under KServe and as plain Deployments.

Builds on the otel-llm-serving root and the vLLM, KServe and Knative suites from #779 (merged). The root requires the SGLang solution in the cloned chart, so CI passes once a helm-charts release branch includes aws-observability/helm-charts#418.

What the chart does that this tests

KServe labels a vLLM predictor and an SGLang predictor identically, so #418 scrapes every predictor's model container once with a shared kserve-model-server job and lets each engine pipeline keep its own series by metric name (vllm:*/http_*, sglang:*). Servers outside KServe are found by image (vllm, sglang). Both engines get aws.service.type = ai_inference and the same service.name order: the resource.opentelemetry.io/service.name annotation, then the InferenceService, then the workload, then the pod.

Changes to terraform/eks/daemon/otel-llm-serving

Workload Exercises
sglang-isvc: InferenceService, SGLang CPU image, --enable-metrics SGLang found through the shared KServe job and routed to the sglang pipeline; service.name = InferenceService; the Knative data plane
sglang-standalone: Deployment, SGLang CPU image, no declared port, annotation resource.opentelemetry.io/service.name: sglang-chat SGLang found by image; the 30000 default port; the annotation wins over the workload name
loadgen now also sends requests to both SGLang servers
  • SGLang uses its CPU build, lmsysorg/sglang:v0.5.23-xeon (sglang_cpu_image), with Qwen2.5-0.5B-Instruct like the vLLM servers. The build needs AVX-512, which m5 has; on AMD EPYC Zen 2 it exits with an illegal instruction. On CPU, --mem-fraction-static applies to host memory, so it is raised to 0.85.
  • SGLang's /health takes about a second, the default probe timeout, so the InferenceService's readiness probe sets timeoutSeconds: 5; otherwise the queue-proxy never becomes ready.
  • The chart guard also requires the sglang solution, and the validator runs ./test/otel/solutions/sglang after test_dir.

Suite: test/otel/solutions/sglang (9 tests)

  • 12 SGLang metrics from both servers, with scope github.com/sgl-project/sglang, pipeline sglang and datapoint labels
  • TestSGLangKServeAttribution: service.name = InferenceService, revision Deployment workload, KServe pod labels, kserve-container, ai_inference, cloud identity, no temporary attributes
  • TestSGLangImageDetected: service.name from the annotation, scraped on port 30000, no InferenceService label
  • one series per pod, never the queue-proxy
  • TestModelServerRouting: each of the four servers (vLLM and SGLang, predictor and plain) reaches only its own engine pipeline, with a positive control for each
  • the sglang pipeline publishes only sglang:*
  • request and prompt-token counters increase on both servers

Testing

  • Both suites run against an existing EKS cluster (KServe 0.20 Serverless, Knative 1.21) with a vLLM and an SGLang InferenceService on GPUs, CPU vLLM and CPU SGLang Deployments (SGLang on an Ice Lake node), the chart from feat(otel-ci): add SGLang model-server metrics and share KServe model-server discovery aws-observability/helm-charts#418, and load on all four. Workload names were pointed at that cluster.
    • SGLang suite: 9/9.
    • vLLM suite: 9/11; the transformer and generic-exporter tests need workloads that only this root deploys, and their positive controls reported them missing.
  • go vet -tags integration and gofmt are clean; terraform fmt and terraform validate pass.

PR Checklist

Adds the SGLang suite and SGLang workloads to the LLM serving root, so vLLM and SGLang are tested side by side under KServe and as plain Deployments.

- Deploy an SGLang InferenceService and a plain SGLang Deployment (no declared port, service.name annotation) from SGLang's CPU image, and send them load
- Add test/otel/solutions/sglang: metrics, scope and labels, InferenceService and annotation attribution, the 30000 default port, one series per pod, sglang:* only, counters increase
- Add TestModelServerRouting: each of the four servers reaches only its own engine pipeline, with positive controls
- Run the sglang suite after test_dir, and require the solution in the cloned chart
@Aakash-Dantre
Aakash-Dantre force-pushed the feat/otel-llm-serving-sglang branch from 4720f34 to 6046c74 Compare November 5, 2026 13:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant