openllmetry VS langtrace

I’m also aware of other OSS initiatives doing similar initiatives, so I wouldn’t say no one has ever done what your doing.

[1] https://github.com/traceloop/openllmetry

So why should it be different when the app you're building happened to be using LLMs?

So today we're open-sourcing OpenLLMetry-JS. It's an open protocol and SDK, based on OpenTelemetry, that provides traces and metrics for LLM JS/TS applications and can be connected to any of the 15+ tools that already support OpenTelemetry. Here's the repo: https://github.com/traceloop/openllmetry-js

A few months ago we launched the python flavor here (https://news.ycombinator.com/item?id=37843907) and we've now built a compatible one for Node.js.

Would love to hear your thoughts and opinions!

Check it out -

Docs: https://www.traceloop.com/docs/openllmetry/getting-started-t...

Github:

+1 to this. Langtrace core maintainer here. We are building a SDK and a client for automatic instrumentation of LLM based applications using OTEL standards. The OpenLLMetry team along with the CNCF OpenTelemetry working group has been doing some great work standardizing semantic naming conventions and we are starting to adopt the same set of standards.

[1] https://github.com/Scale3-Labs/langtrace

Ola and Karthik here. We are working on Langtrace(https://github.com/Scale3-Labs/langtrace), an open source, open telemetry based SDK and monitoring/evaluations client for LLM based applications. The SDK generates OTEL standard spans and traces for popular LLMs like OpenAI, Anthropic and Cohere, popular frameworks like Langchain and LlamaIndex and vectorDBs like ChromaDB and Pinecone.

The LLM monitoring/evaluations space has seen a number of products off late, both open source and closed source ones. But, a couple of things we have observed are: lack of standard spans and traces that creates vendor lock in, different tools are optimized for solving different pain points - Evaluations, Prompt management, Datasets etc.

We believe that adopting open telemetry(OTEL) standard tracing not only lets teams use our SDK without having to switch their observability client, but will also enable developers to develop tooling for any custom needs such as capturing datasets, prompts, evaluations etc.

A quick note on what we have built so far:

[1] We have a Python and a TypeScript SDK and we have broken down the support for the LLM layer into 3 groups, LLMs, Frameworks and VectorDBs. Our SDKs are open telemetry compatible, can be installed and used independently and we also provide an option to pass custom exporters to export the traces and spans to any observability tool of your choice.

[2] An observability client that is hyper optimized for solving the unique pain points and challenges that come with LLM based apps like Evaluations, prompt iteration, datasets etc. We are SOC2 compliant and the client can also be self hosted if you have strict data privacy and protection requirements.

[3] Both the SDK and the client are fully open source. We are leaning on the community to try it out and provide feedback.

A note about Open Telemetry semantic conventions for LLMs - We would like to converge on standard names for trace attributes that follow the OTEL rules and are looking for feedback from experts here - https://github.com/Scale3-Labs/langtrace/discussions/71

We recognize that this project is early and there is a lot of room for improvement. Would love to hear your thoughts and feedback. Thanks!

Links:

[1] https://langtrace.ai/

[2] https://github.com/Scale3-Labs/langtrace

[3] https://docs.langtrace.ai/introduction

[1] We have a Python and a TypeScript SDK and we have broken down the support for the LLM layer into 3 groups, LLMs, Frameworks and VectorDBs. Our SDKs are open telemetry compatible, can be installed and used independently and we also provide an option to pass custom exporters to export the traces and spans to any observability tool of your choice.

[2] An observability client that is hyper optimized for solving the unique pain points and challenges that come with LLM based apps like Evaluations, prompt iteration, datasets etc. We are SOC2 compliant and the client can also be self hosted if you have strict data privacy and protection requirements.

[3] Both the SDK and the client are fully open source. We are leaning on the community to try and provide us with feedback.

A note about Open Telemetry semantic conventions for LLMs. We would like to converge on standard names for trace attributes that follow the OTEL rules and are looking for feedback from experts here - https://github.com/Scale3-Labs/langtrace/discussions/71

We recognize that this project is early and there is a lot of room for improvement. Would love to hear your thoughts and feedback. Thanks!

Links:

[1] https://langtrace.ai/