Langfuse integration

[elijahbenizzy]

Is your feature request related to a problem? Please describe.
We should be able to automatically track every Burr app using Langfuse automatically.

With hooks (https://burr.dagworks.io/concepts/hooks/) one should be able to do this nicely.

Describe the solution you'd like

A trace-based langfuse integration. The following features at a minimum:

• One trace per application run (this is dependent on this: Pre/Post application interface calls #203)
• One span per step
• One span per tracer span call
• Observations at will (perhaps state elements)
• Perhaps access to the langfuse client.

You'll want to follow the same classes as this does: https://github.com/DAGWorks-Inc/burr/blob/main/burr/tracking/client.py#L60,
except for the BaseStateLoader, that's not relevant. Then you can store state in it.

See this for an inspiration (this is specific to datadog): https://github.com/DAGWorks-Inc/hamilton/blob/96da3107666dcccdd80da39d7d4d118b4de82571/hamilton/plugins/h_ddog.py#L19.

There are two ways to do this:

1. Expose the langfuse client in the functions/classes
2. Bury it behind the logger

We should enable both, but strive towards (2).

For (1), we can do it if you pass the langfuse object in for application calls as runtime inputs. This will make it easier: #205.

For (2) we'll need to reconcile our model with theirs. Specifically, this will help: #46.

Let's do (1) then open up another issue for (2)

Describe alternatives you've considered

Additional context

[fer-git]

+1 built-in langfuse integration please.

[andreahlert]

Labels migrated to new taxonomy (#692).

[elijahbenizzy]

If anyone is excited about taking this on you are welcome! OTel should be good but we can probably go a bit further.

[hannguyen0712]

Hi @elijahbenizzy, I'd like to take this on! I'm looking to work on contributing to LLM-observability integration.
One scoping question first, since the issue has aged a bit. You noted on Mar 29 that "OTel should be good but we can probably go a bit further," and I see #205 (global inputs, which the original approach (1) depended on) was since closed as not planned. Given Langfuse now ingests OpenTelemetry natively, would you prefer I build this on top of Burr's OTel tracing support, with emitting spans Langfuse can consume, rather than a dedicated Langfuse client following the burr/tracking/client.py pattern? That seems like the cleaner path and avoids the dead #205 dependency, but I want to confirm before starting.
Assuming OTel is the direction, I'd scope a focused first PR via Burr's hooks: one trace per application run, one span per step, with state observations attached, plus a short example and docs. I can open follow-ups for anything beyond that (e.g. exposing the Langfuse client directly, or per-tracer-span observations). Does that work as a starting point?