Make a Langfuse trace worth opening: question, answer, session, no probe noise
This commit is contained in:
@@ -52,6 +52,22 @@ aiService:
|
||||
answerProvider: bedrock-converse
|
||||
answerModelId: qwen.qwen3-next-80b-a3b
|
||||
rerankEnabled: true
|
||||
# Second trace destination alongside Tempo, for the LLM-shaped view
|
||||
# (per-trace answers + eval scores). Self-hosted on this same cluster by
|
||||
# the separate `langfuse` ArgoCD Application. The keys it needs are
|
||||
# secrets and stay inline on the Application, like jwtSecret does —
|
||||
# setting this URL alone changes nothing until they exist.
|
||||
#
|
||||
# The in-cluster Service, NOT https://langfuse.realvuxbaro.me. That public
|
||||
# name resolves to the Elastic IP of the very node these Pods run on, so a
|
||||
# Pod reaching it has to hairpin out and back through the node's own
|
||||
# public address — which silently never completes here. Spans were created
|
||||
# and dropped with no error in ai-service's log and nothing arriving on
|
||||
# Langfuse's otel-ingestion-queue; an identical span sent from a laptop
|
||||
# over the public URL ingested fine, which is what isolated it to the
|
||||
# cluster-internal hop. Cross-namespace is fine: Services resolve
|
||||
# cluster-wide, unlike Secrets.
|
||||
langfuseBaseUrl: http://langfuse-web.medical-chatbot-data.svc.cluster.local:3000
|
||||
|
||||
# Auth is live in production (2026-08-19). These stayed false here for a day
|
||||
# while the live Application carried `enabled: true` inline, so Git and the
|
||||
|
||||
Reference in New Issue
Block a user