Przegląd
Langfuse to open source’owa platforma do inżynierii LLM: trace’y, analityka tokenów i kosztów, zarządzanie promptami i ewaluacje. Współpracuje z GoModel na dwa uzupełniające się sposoby:- Trace’y gatewaya. Eksporter OpenTelemetry w GoModel wysyła trace dla każdego requestu do endpointu OTLP Langfuse. Obejmuje to wszystkich klientów gatewaya bez zmian w kodzie aplikacji, a każdy trace pokazuje model, providera, który go obsłużył, opóźnienie, użycie tokenów i koszt, status oraz każdy retry lub failover. Prompty i odpowiedzi są dodawane tylko wtedy, gdy włączysz przechwytywanie treści.
- Trace’y aplikacji. Wrapper Langfuse SDK zastępujący klienta OpenAI, skierowany na GoModel jako base URL. Langfuse zapisuje pełne prompty, odpowiedzi i użycie tokenów; GoModel zapewnia pod spodem routing, failover, cache oraz własny log audytowy i śledzenie kosztów.
App (Langfuse SDK) -> GoModel -> OpenAI/Anthropic/Gemini/..., a trace’y z obu
etapów trafiają do Langfuse.
1. Wysyłaj trace’y gatewaya do Langfuse
Langfuse przyjmuje trace’y OTLP pod/api/public/otel, uwierzytelniając je parą
kluczy API projektu. Zakoduj klucze w Base64:
.env dla Dockera usuń je – tam stałyby się częścią wartości.
Zachowaj domyślny protokół
http/protobuf: endpoint OTLP Langfuse nie obsługuje
gRPC. Klucze API znajdziesz w Langfuse w Project Settings -> API Keys;
wdrożenia self-hosted mogą je też utworzyć z góry przez
zmienne LANGFUSE_INIT_*.
Aby uruchomić samo Langfuse, zobacz jego
szybki start z docker compose –
git clone https://github.com/langfuse/langfuse.git && cd langfuse && docker compose up,
UI na porcie 3000.
Co pojawia się w Langfuse
Każdy request do gatewaya staje się jednym trace’em: spanemPOST /v1/chat/completions
z zagnieżdżoną generacją dla każdego wywołania providera, nazwaną według operacji
i modelu (chat gpt-5-mini). Generacja zawiera model, którym odpowiedział
provider, liczbę tokenów wejściowych i wyjściowych oraz finish reason, więc
Langfuse wycenia ją na podstawie swojego katalogu modeli i zasila swoje dashboardy
kosztów i tokenów. Jej metadane zawierają też gen_ai.provider.name i
gomodel.provider.name (dokładny provider z Twojej konfiguracji), więc request,
który przeszedł failover, pokazuje jedną generację na
każdą próbę – który provider zawiódł, z jaką klasą błędu i który odpowiedział,
z użyciem przypisanym do próby, która się powiodła.
Streamowane chat completions, Responses API i tłumaczone wywołania /v1/messages
dostają generację trwającą do końca streamu, z takim samym użyciem. Requesty
/v1/messages, które GoModel przekazuje natywnie do providera Anthropic, pojawiają
się bez użycia.
Langfuse oblicza koszt na podstawie własnego cennika. Śledzenie
kosztów w GoModel uwzględnia Twoje nadpisania cen i
stawki cache, więc obie sumy mogą się różnić.
Przechwytywanie promptów i odpowiedzi
Prompty i odpowiedzi nie trafiają do telemetrii, dopóki nie włączysz przechwytywania treści:2. Tracing z poziomu aplikacji przez Langfuse SDK
Aby zamiast tego zbierać trace’y z aplikacji – na przykład grupować wywołania we własne spany albo dołączać wersje promptów z Langfuse – zinstrumentuj ją wrapperem OpenAI od Langfuse i skieruj go na GoModel. W istniejącej aplikacji korzystającej z OpenAI SDK wymaga to zmiany dwóch linii:openai/gpt-5-mini, gemini/gemini-2.5-flash,
modele wirtualne), a każde wywołanie nadal korzysta z
failoveru, cache’u, budżetów i ścieżki audytu GoModel.
Wrapper JS/TS
działa tak samo.
3. Jeden trace end-to-end
Przy obu ścieżkach włączonych jedno wywołanie LLM tworzy dwa osobne trace’y w Langfuse – z SDK i z gatewaya. Aby je połączyć, propaguj kontekst W3C trace: wyślij z requestem nagłówektraceparent, a GoModel podepnie swoje spany pod
trace wywołującego.
Zweryfikowano z Langfuse v4.27.0 (self-hosted przez docker compose) i
Langfuse Python SDK 4.15.1: trace’y OTLP gatewaya dla buforowanego i
streamowanego chatu z OpenAI, Anthropic i Gemini, spany failoveru,
przechwytywanie promptów przez SDK przez GoModel oraz propagację kontekstu
trace łączącą oba źródła.
Rozwiązywanie problemów
Uwagi
- Gatewaye o dużym ruchu mogą próbkować trace’y gatewaya
(
OTEL_TRACES_SAMPLER=parentbased_traceidratio,OTEL_TRACES_SAMPLER_ARG=0.1) – przyparentbased_*requesty, których wywołujący próbkował swój trace, zachowują spany gatewaya, więc propagowane trace’y pozostają kompletne. - Pełna dokumentacja referencyjna eksportera – konfiguracja YAML, endpointy dla poszczególnych sygnałów, samplery, zachowanie przy przeładowaniu – znajduje się w przewodniku po OpenTelemetry. Wszystko tam opisane ma zastosowanie; Langfuse to po prostu backend OTLP.
- Do dashboardów z metrykami liczby requestów i opóźnień połącz to z metrykami Prometheus – Langfuse przechowuje trace’y, a Prometheus metryki.