OpenLIT

OpenTelemetry-native trace pipeline SDKs send OTLP to a built-in receiver on ports 4317 and 4318, traces land in ClickHouse, and the UI reads from there. No separate OpenTelemetry Collector is required.[1][2]

Python, JavaScript, and Go SDKs Install with pip, npm, or go get, then call openlit.init with an OTLP endpoint to instrument an application. Auto-instrumentation covers LLMs, vector databases, MCP, and frameworks by default.[1][2]

Zero-code paths for agents and clusters A CLI installed through Homebrew observes coding agents such as Claude Code, Codex, Cursor, and Windsurf without SDK changes, tracking sessions, cost, tokens, and repository activity. An eBPF controller and a GPU collector cover Kubernetes, Docker, and Linux hosts.[1][2]

Fifty-six plus integrations Documented coverage spans LLM providers, agent frameworks including LangGraph, CrewAI, the OpenAI Agents SDK, and deepagents, plus vector databases and GPUs. Any OTel source, including OpenLLMetry, can also point OTLP exporters at OpenLIT.[1]

Evals on traces or in CI LLM-as-a-judge and programmatic evals score quality, safety, and cost online against production traces or offline through the SDK as CI gates. Regression evals verify fixes to prompts, tools, rules, or guardrails.[1][2]

Guardrails and content controls Built-in guards detect prompt injection, jailbreaks, and sensitive topics, and the SDK can redact PII before prompts are sent and recorded. Prompt and completion capture is on by default and can be disabled or truncated per configuration. One documented boundary: the guard rewrite currently reaches single-message prompts only, so multi-turn conversations need additional handling.[1][2]

Prompt Hub, Vault, and OpenGround Prompt Hub versions prompts with dynamic variables, API retrieval with unlimited fetching, and AI-assisted improvement. Vault stores LLM API keys encrypted with AES-256-GCM behind key and tag based retrieval. OpenGround compares models side by side on latency, tokens, and cost with your own keys. Custom ClickHouse-backed dashboards with import and export round out the operations tooling.[1]

Self-hosted operations Deploy with Docker Compose or Kubernetes Helm, reuse an existing ClickHouse instead of deploying a new one, and sign in with Google, Azure AD, or GitHub. OSS usage is unlimited because you run the infrastructure yourself, with community support on GitHub.[1][2]

Platform teams standardizing on OpenTelemetry: if agents, services, and infrastructure already export OTLP, OpenLIT slots into that pipeline and keeps agent telemetry next to the rest of the stack, which matters because a second proprietary agent would split debugging across two systems.[1][2]

Organizations with data-residency requirements: self-hosting under Apache 2.0 keeps traces, prompts, and eval data inside operator infrastructure with no per-trace fee, which matters for teams that cannot send prompts and completions to a vendor Cloud.[1][2]

Engineers iterating on agent quality: teams that tune prompts, tools, and guardrails get tracing, evals, and prompt versioning in one loop instead of three separate tools, which matters because the eval scores read directly off the same traces used for debugging.[1][2]

Teams without operator capacity: if nobody can run Docker or Kubernetes plus ClickHouse, the self-hosted requirement is a real burden while the managed Cloud remains waitlisted, so these teams should wait for Cloud pricing or pick a hosted platform.[1][2]

Non-technical users seeking no-code tooling: instrumentation needs code or CLI setup, and value comes from reading traces and configuring evals, not from a point-and-click analytics product, so business users without engineers will stall at setup.[1][2]

Buyers needing committed support terms: the documented support path is the community on GitHub, with no enterprise SLA stated in the reviewed sources, so regulated procurements that require a named engineer and response times cannot close on the OSS plan alone.[1]