blocked_instrumentation_scopes are not blocking fastAPI or Logfire

[qrosseel]

Hey @hassiebp, the SDK v3 documentation mentions everywhere that you should get the active Langfuse client using the get_client function. There's however no way to pass the blocked_instrumentation_scopes in that singleton.

So, you're left writing your own wrapper, something like the code below. However, this wrapper does not block my FastAPI and Logfire otel scopes, still polluting my Langfuse trace with all kinds of operational logging that I don't want there.

Any guidance would be welcome, because documentation is lacking and the attribute does not seem to be doing anything at all.

Code

import os
from typing import Optional

from dotenv import load_dotenv
from langfuse import Langfuse
from langfuse._client.resource_manager import LangfuseResourceManager

load_dotenv()
_public_key: Optional[str] = os.getenv("LANGFUSE_PUBLIC_KEY", None)


class LangfuseClient:
    """
    Wrapper class for managing a singleton Langfuse client instance.
    This implementation is based on the get_client() implementation of Langfuse.
    """

    _instance: Optional[Langfuse] = None
    blocked_scopes = ["logfire", "opentelemetry.instrumentation.fastapi"]

    @classmethod
    def get_client(cls) -> Langfuse:
        """Get or create a Langfuse client instance.

        Returns:
            Langfuse: Langfuse client for tracing
        """
        with LangfuseResourceManager._lock:
            active_instances = LangfuseResourceManager._instances

            if not _public_key:
                if len(active_instances) == 0:
                    # No clients initialized yet, create default instance
                    return Langfuse()

                if len(active_instances) == 1:
                    # Only one client exists, safe to use without specifying key
                    instance = list(active_instances.values())[0]

                    # Initialize with the credentials bound to the instance
                    # This is important if the original instance was instantiated
                    # via constructor arguments
                    return Langfuse(
                        public_key=instance.public_key,
                        secret_key=instance.secret_key,
                        host=instance.host,
                        tracing_enabled=instance.tracing_enabled,
                        blocked_instrumentation_scopes=cls.blocked_scopes,
                    )

                else:
                    # Multiple clients exist but no key specified - disable tracing
                    # to prevent cross-project data leakage
                    return Langfuse(
                        tracing_enabled=False,
                        public_key="fake",
                        secret_key="fake",
                        blocked_instrumentation_scopes=cls.blocked_scopes,
                    )

            else:
                # Specific key provided, look up existing instance
                target_instance: Optional[LangfuseResourceManager] = (
                    active_instances.get(_public_key, None)
                )

                if target_instance is None:
                    # No instance found with this key - client not initialized properly
                    return Langfuse(
                        tracing_enabled=False,
                        public_key="fake",
                        secret_key="fake",
                        blocked_instrumentation_scopes=cls.blocked_scopes,
                    )

                # target_instance is guaranteed to be not None at this point
                return Langfuse(
                    public_key=_public_key,
                    secret_key=target_instance.secret_key,
                    host=target_instance.host,
                    tracing_enabled=target_instance.tracing_enabled,
                    blocked_instrumentation_scopes=cls.blocked_scopes,
                )

Otel Scope

Originally posted by @qrosseel in #7283

[dosubot[bot]]

You're right—blocked_instrumentation_scopes in Langfuse SDK v3 is supposed to filter out spans from specific OpenTelemetry instrumentation libraries (like FastAPI and Logfire), but in practice, it often doesn't work as expected, especially when using get_client or custom wrappers. This is a known limitation: the singleton pattern in get_client doesn't let you pass blocked_instrumentation_scopes, and even custom wrappers may not block unwanted scopes if the client isn't initialized early enough in your application's lifecycle. Filtering must be set globally at client initialization, not at the CallbackHandler level, and regex is not supported—you have to enumerate each scope explicitly discussion.

The most reliable workaround is to initialize the Langfuse client with blocked_instrumentation_scopes at the very top of your main entrypoint (e.g., main.py, right after imports), before any other OpenTelemetry instrumentation or Langfuse integrations are set up. This ensures the block list is respected globally discussion. Initializing inside FastAPI lifecycle hooks or wrappers is too late and won't work.

If you still see unwanted traces, consider using the OpenTelemetry Collector's filterprocessor to filter spans before they reach Langfuse. This lets you filter by attributes or span names, but be careful—complex filters can break trace relationships and cause incomplete traces docs.

Currently, there's no backend filtering for instrumentation scopes in Langfuse; all filtering must happen in the SDK or collector before data is sent issue. Regex blocking isn't supported, so you need to keep your block list up to date issue.

If you want to suppress all traces, you can set LANGFUSE_TRACING_ENABLED=False and OTEL_SDK_DISABLED=true, but this disables OpenTelemetry processing for the whole process and may affect other integrations issue.

References:

• Filtering by instrumentation scope in Langfuse Python SDK
• OpenTelemetry Collector filterprocessor example
• Known issues and workarounds
• Singleton/global client initialization advice
• Regex not supported for blocking scopes

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[qrosseel]

Okay, initializing langfuse at the top-level app.py seems to do the trick, so the get_client wrapper isn't necessary.
Closing this issue!

discussion

[qrosseel]

But the same issue persists as highlighted in the discussion:
The top-level trace name is now empty.

Any tips on how to approach this?

[dosubot[bot]]

This happens because blocking instrumentation scopes like FastAPI or Logfire prevents those libraries from creating the root span, so Langfuse doesn’t have a meaningful top-level trace name to display. To fix this, you need to manually create and name the root span at the start of your request or workflow. You can do this with the Langfuse Python SDK using a context manager or the @observe decorator. For example:

from langfuse import get_client

langfuse = get_client()

with langfuse.start_as_current_span(name="my-custom-trace", input={"request": "details"}) as root_span:
    # ... your logic here ...
    root_span.update_trace(
        name="my-custom-trace",  # sets the trace name
        input={"request": "details"},
        output={"result": "something"}
    )

If you use custom trace IDs or pass a trace_context, you may need to explicitly update the trace name and metadata using get_client().update_current_trace(name=...) or span.update_trace(name=...) inside the trace context docs, issue.

Best practice: always set the trace name and input/output on the root span, especially when blocking auto-instrumentation. The @observe decorator also handles trace grouping and naming automatically if you prefer that style docs.

Recent Langfuse releases improved trace name handling, so upgrading may help if you’re still seeing issues issue.

Let me know if you want a more specific code example for your setup!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[hassiebp]

@qrosseel You can simply instantiate Langfuse at the top of your application with the blocked_instrumentation_scopes and use get_client throughout your app to access that instance.

from langfuse import Langfuse

Langfuse(*)

You will also have to manually set the trace name, input and output as the root span is being filtered out. [See here])(https://langfuse.com/docs/observability/sdk/python/instrumentation#override-default-behavior)

[inkeep-ai-assistant[bot]]

The blocked_instrumentation_scopes parameter in the Langfuse Python SDK is designed to filter out spans from specific OpenTelemetry instrumentation libraries, such as "sqlalchemy" or "psycopg". The documentation example shows usage like this:

from langfuse import Langfuse

langfuse = Langfuse(
    blocked_instrumentation_scopes=["sqlalchemy", "psycopg"]
)

This is intended to exclude spans whose scope.name matches any of the listed values. You can see the actual instrumentation scope for each span in the Langfuse UI under metadata.scope.name(1).

However, filtering only works as intended if the instrumentation scope names in your block list exactly match the scope.name attribute of the spans you want to filter. If FastAPI or Logfire spans are still appearing, double-check the exact value under metadata.scope.name for those spans in the Langfuse UI and make sure your block list matches them precisely (case-sensitive, no regex support)(1)(2).

Also, filtering with blocked_instrumentation_scopes must be applied at client initialization—it cannot be set or changed via get_client() after the client is created, since get_client() returns a singleton instance initialized with whatever parameters were first set(1)(2).

Key points:

• Filtering by scope only works if the scope names are exact matches.
• The block list does not support regex, only literal string matches(2).
• blocked_instrumentation_scopes must be set at the time the Langfuse client is first initialized, not after.
• If clients are being cached or reused (as with get_client()), changing the block list later has no effect on the existing instance(1)(2).

If spans are still showing up, ensure you:

1. Re-initialize the Langfuse client with the correct block list before any traces are created.
2. Use the exact scope names as seen in the UI.
3. Avoid re-using a singleton client initialized without your intended filters.

For more details, see the Filtering by Instrumentation Scope section(1) and this related discussion(2).

📚 Sources:

1. Advanced Usage
2. bug: non langfuse related traces going to langfuse UI

---

Have another question? Just tag @inkeep.

[Liubey]

@hassiebp
"Although using blocked_instrumentation_scopes effectively prevents spans from being uploaded to Langfuse, due to the design of the OpenTelemetry context, a parent span will still be visible within the Langfuse span. However, because no information from this parent can be retrieved, it results in an empty span being displayed in the Langfuse UI."

https://langfuse.com/docs/observability/sdk/python/advanced-usage#isolated-tracerprovider