[Feat]: Adopt OTel Semantic Conventions for Resource Attributes

[ThomasVitale]

🚀 What's the Problem?

The application name and instrumentation library are currently included in each span and metric as attributes (gen_ai.application_name, telemetry.sdk.name), which is a non-standard strategy to name and deliver such information.

💡 Your Dream Solution

OpenTelemetry provides a service.name standard attribute to hold the application name. It's included in the resource attributes instead of span attributes. See: https://opentelemetry.io/docs/specs/semconv/resource/#service. It's actually present in the spans produced by OpenLit, but it's set to default rather than to the application name. About the metrics, having the service.name as a resource attribute instead of metric attribute is also the standard strategy. See: https://opentelemetry.io/docs/specs/otel/compatibility/prometheus_and_openmetrics/#resource-attributes

About the instrumentation library name (telemetry.sdk.name), it's currently included as a span attribute, as a resource attribute, and as a metric attribute. Is it required to have it as a span attribute and metric attribute? Would it work having it just as a resource attribute, as defined in the semantic conventions? See: https://opentelemetry.io/docs/specs/semconv/resource/#telemetry-sdk. It's also required to provide telemetry.sdk.language and telemetry.sdk.version to fullfill the conventions.

📖 Additional Context

I really like OpenLit, congratulations on such a great library and thanks for following the OpenTelemetry path. It makes it possible to integrate even more systems with OpenLit. I'm currently working on integrating Java applications with OpenLit, and thanks to the OpenTelemetry adoption is more approachable. The challenge I'm experiencing is about the application name and telemetry SDK, which is why I raised this issue.

[patcher9]

Hey @ThomasVitale

Thanks for opening up the issue

So if you initialize OpenLIT like

openlit.init(application_name="some_name", environment="some_env")

then you should have the applied value available in resource attributes aswell. Same for telemetry SDK, It should be available in the resource attributes aswell. Checkout this code line

Why do we include these then in Span attributes aswell?

As you can see in the arguments that can be pass to openlit.init(), you can see that you can manually create a OTel Tracer and pass that aswell to openlit.init. And now as sometimes the tracer can be created by the user, in which case we cant always be sure that they would include service_name, deployment_env and telemetry_sdk_name in the resource attributes, To make sure such scenrios dont cause issues in visualization dashboards (prebuilt), We add them to the span attributes that powers the dashboard.

Lemme know what you think about it, Happy to discuss on this further too to solve your issue. (Also you can join our community slack if that is easier)

[ThomasVitale]

Thanks a lot for the reply, @patcher9, it helped clarifying things. I understand now why both pieces of information are included as span and metrics attributes. Also, I hadn't realised I could pass the application name via the openlit.init() method, I should have read the documentation more carefully :)

If I instrument an application via OpenTelemetry directly, would the OpenLit UI work if the application name was only included as a service.name resource attribute and the telemetry.sdk.name was only included as a resource attribute and set to opentelemetry?

I have joined the OpenLit Slack, so if you prefer we can continue the conversation there. I'm looking into the observability instrumentation for the two main LLM Java frameworks (Spring AI and LangChain4j), and I'm trying to understand to what extent I can support OpenLit on top of the standard observability foundation Java applications usually have.

[patcher9]

If I instrument an application via OpenTelemetry directly, would the OpenLit UI work if the application name was only included as a service.name resource attribute and the telemetry.sdk.name was only included as a resource attribute and set to opentelemetry?

Yes, The UI should work (except the cost per application and environment panel I think

I have joined the OpenLit Slack, so if you prefer we can continue the conversation there. I'm looking into the observability instrumentation for the two main LLM Java frameworks (Spring AI and LangChain4j), and I'm trying to understand to what extent I can support OpenLit on top of the standard observability foundation Java applications usually have.

Nice, Yeah we dont have a Java based SDK right now (how we have for python, though would love to see if you have something in mind and we can work on it together if you like). Ill start a thread in our slack for this

[ThomasVitale]

Thanks for the additional info, much appreciated. I'll join the conversation on Slack.

[patcher9]

Started a thread on Slack to discuss, See you there 👋 !