fix(litellm): normalize the remaining LiteLLM provider prefixes to OTel gen_ai.provider.name values - #4407
Conversation
…el values The provider alias table normalized six LiteLLM prefixes, but several other prefixes that LiteLLM reports as custom_llm_provider also differ from the published gen_ai.provider.name values and were passing through unchanged: - watsonx / watsonx_text -> ibm.watsonx.ai - xai -> x_ai - cohere_chat -> cohere - vertex_ai_beta -> gcp.vertex_ai - azure_text -> azure.ai.openai - bedrock_mantle -> aws.bedrock This split the same provider across two keys depending on the route taken: a watsonx call made through LiteLLM was recorded as watsonx while the same call through the watsonx instrumentation was recorded as ibm.watsonx.ai, so spans and metrics for one provider no longer aggregate together. All seven prefixes are real custom_llm_provider values in LiteLLM (verified with litellm.get_llm_provider on 1.94.0), and each maps onto an existing GenAiProviderNameValues member. Unknown prefixes still pass through unchanged.
|
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe LiteLLM instrumentation now normalizes additional provider aliases. Parameterized tests verify the expected OpenTelemetry provider values. ChangesLiteLLM provider aliases
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What
_PROVIDER_ALIASESin the LiteLLM instrumentation normalizes LiteLLM's provider prefixes onto the OTelgen_ai.provider.namewell-known values. It covered six prefixes; several other prefixes that LiteLLM reports ascustom_llm_provideralso differ from the published values and were passing through unchanged:custom_llm_providerwatsonxwatsonxibm.watsonx.aiwatsonx_textwatsonx_textibm.watsonx.aixaixaix_aicohere_chatcohere_chatcoherevertex_ai_betavertex_ai_betagcp.vertex_aiazure_textazure_textazure.ai.openaibedrock_mantlebedrock_mantleaws.bedrockWhy
This split one provider across two keys depending on the route taken. A watsonx call made through LiteLLM was recorded as
watsonx, while the same call through this repo's watsonx instrumentation is recorded asibm.watsonx.ai(GenAiSystemValues.IBM_WATSONX_AI) — so spans and metrics for the same provider don't aggregate together, which is exactly what the comment above the table says the normalization is there to prevent. The same applies tocohere_chatvs the cohere instrumentation'scohere, and to thevertex_ai_beta/azure_text/bedrock_mantlevariants of prefixes that were already normalized.All seven are real, distinct
custom_llm_providervalues, verified against LiteLLM 1.94.0:Each maps onto an existing
GenAiProviderNameValuesmember, so no new values are invented. Unknown prefixes still pass through unchanged, as before.Testing
tests/test_provider_resolution.pyis parametrized over the new prefixes. Verified old-vs-new against the same test file:main(fix reverted, new tests in place): 7 failed, 10 passed — each failure is the raw prefix leaking through, e.g.assert 'xai' == 'x_ai'.Full package suite:
37 passed, 1 skipped(the skip is the pre-existingtest_both_openai_and_litellm_instrumented, which needsopentelemetry-instrumentation-openaiinstalled).ruff checkclean under the package's config.🤖 Generated with Claude Code
Summary by CodeRabbit