OpenLLMetry

Why it's ranked here

OpenLLMetry is a strong choice for Python teams already invested in observability standards. Its unusually broad provider, framework, vector database, and destination coverage reduces integration work. Direct instrumentation packages also let experienced teams avoid adopting the higher-level SDK.

What's good

The SDK supports custom exporters, span processors, propagation, sampling, resource attributes, and post-processing callbacks. Teams can independently control tracing, content capture, metrics, and logging. The documented destination list includes major commercial platforms, cloud services, and the OpenTelemetry Collector.

Tradeoffs

Content tracing defaults to enabled, so teams handling sensitive prompts should change configuration deliberately. The telemetry documentation is internally inconsistent: it says collection has stopped, then explains collected anonymous exception data. JavaScript and TypeScript support lives in a separate repository, adding operational separation for mixed-language systems.

How to use it well

Use it in Python LLM services where model calls must join existing application traces and observability pipelines. Start with the SDK for quick coverage, then select individual instrumentations when tighter control matters. Configure content capture and exporters explicitly. It does not replace the backend used to store, query, and inspect telemetry.

Observed

License

README.md states Apache 2.0; root package metadata declares MIT.

Primary language

Python

Installation

Published SDK installed with pip as traceloop-sdk.

Interface

Python SDK plus directly usable instrumentation packages.

Workspace structure

Private Nx workspace containing packages under packages/*.

Language scope

JavaScript and TypeScript support is maintained in a separate repository.

Protocol coverage

The documented instrumentation coverage includes MCP.