Extend GenAI System to include OpenAI compatible platforms

[codefromthecrypt]

This extends GenAI System to include OpenAI compatible platforms. These are usable by OpenAI client libraries:

• Azure OpenAI
• Gemini
• Perplexity
• xAI (note they also say they are compatible with anthropic!)
• DeepSeek
• Groq

At the moment, there is no way to attribute signals to Azure OpenAI, so people use "openai". At Elastic, we have different
dashboards for OpenAI (the platform) vs Azure OpenAI, as these are independent services. Lacking a GenAI system name, we have to resort to "openai" which is ambiguous between these two.

Using "server.address" isn't a great option due to subdomains used in the Azure OpenAI service depending on the application name in Azure. While we could use cloud semantics, they aren't guaranteed to be present, and aren't integrated in current code. Even if it were, this it is less ideal to navigate or aggregate on two attributes vs one.

This also adds a value for Google Gemini which has exactly the same concern as it can be accessed either via its native API or via OpenAI libraries.

Changes

Added the following, clarifying only when needed:

• "az.ai.openai" to follow conventions of "az.ai.inference"
• "gemini"", not "google.gemini" as "vertexai" is not prefixed either.
• "perplexity"
• "xai"
• "deepseek"
• "groq"

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[codefromthecrypt]

PS I used the Azure AI Inference client client per instructions to access Azure OpenAI service, and I guess what's happening here more generally, is that gen_ai.system might be conflated with the client itself.

Specifically, the Azure AI Inference client can access three different products:

• GitHub models
• Azure AI Studio models
• Azure OpenAI Studio models

In each case the services are different (different subdomains, for example). However, status quo, all would set gen_ai.system=az.ai.inference

So, status quo gen_ai.system might be treated more like the SDK name than the actual system name. Should I update the text like that, as this applies even beyond openai compat?

[karthikscale3]

This is definitely an issue that we have faced as well. Right now auto instrumentation default sets genai.system to openai even if the base_url used is different from the openai one. More broadly it's only looking at the client library being used as opposed to the inference server being used, which is the correct representation. In Langtrace's SDK, we capture the underlying server being used from the base url using regex and set a langtrace attribute called service-name. I think we can move this behavior up to the spec with genai.system. We also need to capture this for all the other LLM providers that support openai client library

1. xai
2. deepseek
3. groq
4. perplexity

[lmolkova]

Base URL regex is not reliable either - you can run smthing behind the proxy, self-host model in vllm, your provider can host different models behind one API. Instrumentation can do the best effort, but cannot guarantee anything beyond "a system this library was designed for" on the gen_ai.system.

[codefromthecrypt]

@lmolkova want me to fix the "dead link" on https://blogs.oracle.com/linux/post/understanding-linux-kernel-memory-statistics? it is result code zero which I've seen elsewhere when a link takes too long to load or otherwise

[codefromthecrypt]

The broken links might not be a new problem. We can work around this by retrying externally, in the make file, but I imagine for now, folks can just manually merge when MLC is flakey on a good link. #332 (comment)

[xrmx]

The broken links might not be a new problem. We can work around this by retrying externally, in the make file, but I imagine for now, folks can just manually merge when MLC is flakey on a good link. #332 (comment)

It has been here since a few and has not been a problem to have things merged :)

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[codefromthecrypt]

This has been approved for a while now, anything missing needed for merge?

[lmolkova]

@codefromthecrypt we require at least 2 approving reviews.

[codefromthecrypt]

Thanks for merging this.

Last night, I noticed I missed a spot as mistral (system/platform/llm provider) is also compatible with openai (chat completions api). I was testing our chatbot-rag-app, used by solutions architects for client demonstrations. It supports mistral as an llm implementation for LangChain. While LangChain uses raw HTTP to access mistral, it does so with the openai completions endpoint. I also noticed spring-ai squarely classifies mistral as openai (api) compatible. Basically as a cloud platform, mistral is accessed similar to the others out there. cc @ThomasVitale from spring-ai and I'll raise a follow-up PR with these notes.

cc @jack-berg on a sidebar as this PR puts modeling nuance in a very specific and concrete context. Others can ignore

---

mistral is a system/platform/llm provider e.g. https://docs.spring.io/spring-ai/reference/api/chat/mistralai-chat.html#_openai_api_compatibility shows its cloud endpoint
it is also a family of models, e.g. you can use mistral-nemo with ollama on your laptop, or on other cloud platforms.

depending on context, what we say is a "system" is a platform, api, model family or multiple of these. What's identifiable from the client is limited, but from the server you also get the fun of whether you report "ollama" or "vllm" as a "system" or not, regardless of it traffic came in on the "openai" compatible endpoint vs another inference one.

[codefromthecrypt]

#1719 on the follow-up for Mistral AI