Why do I see HTTP requests or database queries in my Langfuse traces?

When your application uses other OpenTelemetry-instrumented libraries, you might see observations showing up in Langfuse that aren’t relevant for monitoring or improving the AI side of your app. They still count toward your billable units, so you’ll want to remove these from your Langfuse setup.

You can often recognize these spans by their names: GET /api/..., sql, put_with_retries, /ping, or similar.

Why this happens

The Langfuse SDKs (Python v3+, JS/TS v4+) are built on OpenTelemetry (OTEL). By default, the SDK attaches to the global TracerProvider, which is a single hub that all OTEL-instrumented libraries in your app share. Every span from every library flows through every processor attached to that provider. There’s no automatic filtering, so Langfuse can’t tell the difference between an LLM call and a database query.

┌────────────────────────────────────────────────┐
│            Global TracerProvider                │
│                                                 │
│  All spans from all libraries:                  │
│  ├── LLM calls (OpenAI, Anthropic, ...)    ✅  │
│  ├── HTTP requests (axios, fetch, ...)     ❌  │
│  ├── Database queries (SQL, Redis, ...)    ❌  │
│  └── Framework spans (FastAPI, Express)    ❌  │
│                                                 │
│  → ALL of these get sent to Langfuse            │
└────────────────────────────────────────────────┘

This typically happens when:

• You’re using OTEL auto-instrumentation (e.g. getNodeAutoInstrumentations() in JS or Python auto-instrumentation), which automatically instruments every library it can find, including HTTP clients, databases, and web frameworks. See unwanted spans in Langfuse.
• Another observability tool (Sentry, Datadog, Logfire) already set up the global TracerProvider, and Langfuse is attached to it too. See using Langfuse with an existing OTEL setup or with Sentry.
• Your deployment environment injects OTEL automatically (e.g. AWS Bedrock AgentCore with ADOT). See AWS Bedrock AgentCore.

For a deeper explanation of how the global TracerProvider works and how multiple tools interact, see Using Langfuse with an existing OpenTelemetry setup.

How to fix it

You need to tell Langfuse which spans to keep and which to ignore. Each span carries an instrumentation scope, a label identifying which library created it. You can filter on these.

To find the scope name of a span, click on any observation in the Langfuse UI and look for metadata.scope.name.

from langfuse import Langfuse
 
langfuse = Langfuse(
    blocked_instrumentation_scopes=[
        # HTTP clients
        "opentelemetry.instrumentation.requests",
        "opentelemetry.instrumentation.httpx",
 
        # Web frameworks
        "opentelemetry.instrumentation.fastapi",
        "opentelemetry.instrumentation.starlette",
        "flask",
        "django",
 
        # Databases
        "sqlalchemy",
        "psycopg",
        "psycopg2",
    ]
)

import { NodeSDK } from "@opentelemetry/sdk-node";
import { LangfuseSpanProcessor } from "@langfuse/otel";
 
const allowedScopes = ["langfuse-sdk", "ai", "openai", "@ai-sdk/openai"];
 
const sdk = new NodeSDK({
  spanProcessors: [
    new LangfuseSpanProcessor({
      shouldExportSpan: ({ otelSpan }) =>
        allowedScopes.includes(otelSpan.instrumentationScope.name),
    }),
  ],
});
 
sdk.start();

const blockedScopes = ["express", "http", "pg", "redis", "fastify"];
 
new LangfuseSpanProcessor({
  shouldExportSpan: ({ otelSpan }) =>
    !blockedScopes.includes(otelSpan.instrumentationScope.name),
});

For the full list of filtering options, see the SDK advanced features docs. The exact scope names depend on the libraries you use, so always check metadata.scope.name in the Langfuse UI to confirm which scopes to filter.

Still seeing unexpected spans? Reach out to support.