Hospede o Langfuse no seu VPS para rastrear agentes

Por que rastrear um agente de IA

Aloja o Langfuse no seu próprio servidor para ver o que o seu agente realmente fez durante uma execução. O Langfuse é uma ferramenta de observabilidade de LLM (modelo de linguagem de grande escala) de código aberto. Regista cada prompt, cada resposta do modelo, cada chamada a uma ferramenta e cada token. Depois, agrupa esses dados num único trace que pode abrir e consultar. Ao executá-lo no seu próprio VPS, esses prompts nunca saem de um servidor que controla.

A razão é simples. Não pode corrigir um problema de custos ou de qualidade que não consegue ver. Uma fatura do fornecedor informa que terça-feira custou quatro vezes mais do que segunda-feira. Um trace mostra qual execução do agente causou isso, qual prompt cresceu para 40,000 tokens e qual ciclo de retry foi executado nove vezes antes de desistir. A fatura fornece o número. O trace mostra o código que o produziu.

Este guia usa três termos. Um trace é uma execução completa do agente, do início ao fim. Uma observation é uma etapa dessa execução: um span para código normal ou uma generation para uma chamada a um modelo. Um score é um número associado a um trace, atribuído por uma revisão humana ou por um avaliador automatizado. O Langfuse usa OpenTelemetry (OTel), o padrão independente de fornecedor para tracing distribuído. Assim, a instrumentação que já possui pode enviar dados para ele.

O que o self-hosting do Langfuse realmente executa

O Langfuse v4 não é um único contentor. É composto por dois contentores de aplicações e quatro serviços de armazenamento. Num único VPS, os seis são executados no seu servidor.

• langfuse-web disponibiliza a interface web e a API de ingestão.
• langfuse-worker esvazia a fila em segundo plano. Analisa os lotes de ingestão, calcula os custos e executa o trabalho noturno de retenção.
• O Postgres armazena dados transacionais, como utilizadores, organizações, projetos, chaves de API e prompts.
• O ClickHouse armazena os próprios dados de traces, ou seja, observações e pontuações. É um armazenamento colunar concebido para consultas analíticas. Por isso, um dashboard sobre mais de cem milhões de linhas continua a responder rapidamente.
• O Redis é a fila e a cache entre a aplicação web e o worker.
• O MinIO fornece armazenamento de objetos compatível com S3 no servidor. Armazena todos os eventos recebidos em bruto e qualquer conteúdo multimédia anexado.

O Langfuse publica os recursos mínimos para os três componentes que executam o processamento.

[
  {
    "label": "ClickHouse",
    "cpu_cores": 2,
    "memory_gib": 8
  },
  {
    "label": "Langfuse web",
    "cpu_cores": 2,
    "memory_gib": 4
  },
  {
    "label": "Langfuse worker",
    "cpu_cores": 2,
    "memory_gib": 4
  }
]

O ClickHouse, sozinho, requer 8 GiB de memória. O contentor web e o worker requerem 4 GiB cada um. Esses são os valores mínimos publicados para os 3 componentes dimensionados pelo Langfuse. O Postgres, o Redis e o MinIO ainda precisam de memória adicional. O guia Docker Compose do próprio projeto recomenda uma máquina com 4 cores, 16 GiB de memória e cerca de 100 GiB de armazenamento. Isso corresponde a esse cálculo, sem margem adicional.

Não tente executar isto num plano de 2 GiB. O ClickHouse inicia e aceita escritas durante algum tempo, mas depois termina durante uma merge em segundo plano, porque uma merge carrega partes grandes de uma tabela para a memória. Verá docker compose ps a indicar o contentor clickhouse como restarting, dmesg com uma linha semelhante a Out of memory: Killed process 1234 (clickhouse-serv), e todos os dashboards do Langfuse a devolverem 500. Com uma carga mais baixa, o ClickHouse recusa a consulta e regista DB::Exception: Memory limit (total) exceeded. Oito GiB são suficientes para um único programador que envie alguns milhares de traces por dia. Dezasseis GiB é o valor que deve planear. Se o mesmo VPS também tiver de executar outros serviços, reserve recursos adicionais para eles. Até uma stack relativamente leve, como um workspace AFFiNE self-hosted, precisa dos seus próprios gigabytes, e o ClickHouse não disponibiliza memória adicional.

Implantar o Langfuse com Docker Compose

Clone o repositório. A stack, a ligação entre os serviços e o ambiente predefinido estão todos no seu docker-compose.yml.

git clone https://github.com/langfuse/langfuse.git
cd langfuse

Todos os valores que precisa de alterar estão marcados com # CHANGEME nesse ficheiro. Gere primeiro os três segredos da aplicação.

openssl rand -base64 32   # NEXTAUTH_SECRET
openssl rand -base64 32   # SALT
openssl rand -hex 32      # ENCRYPTION_KEY

ENCRYPTION_KEY tem de ter 256 bits, escritos como 64 caracteres hexadecimais. É exatamente isso que openssl rand -hex 32 imprime. Este valor cifra dados sensíveis em repouso, incluindo quaisquer chaves de fornecedores de LLM que armazene na instância. Se o alterar depois de existirem dados, essas linhas deixam de poder ser decifradas. Por isso, trate-o como permanente desde o primeiro arranque. SALT é usado para calcular o hash das suas chaves de API do Langfuse. Alterá-lo invalida todas as chaves que os seus agentes já utilizam.

Defina depois POSTGRES_PASSWORD, CLICKHOUSE_PASSWORD, REDIS_AUTH e MINIO_ROOT_PASSWORD. A palavra-passe do MinIO aparece em quatro locais: primeiro como MINIO_ROOT_PASSWORD e depois como LANGFUSE_S3_EVENT_UPLOAD_SECRET_ACCESS_KEY, LANGFUSE_S3_MEDIA_UPLOAD_SECRET_ACCESS_KEY e LANGFUSE_S3_BATCH_EXPORT_SECRET_ACCESS_KEY. Se falhar um deles, o MinIO rejeita esse cliente com SignatureDoesNotMatch. Essa mensagem aparece no log do worker, enquanto a interface Web continua a parecer saudável. Manter estes valores num ficheiro env, em vez de os colocar no ficheiro compose versionado, é o padrão descrito em ficheiros env e segredos do Docker Compose.

Fixe as tags das imagens antes de começar

O ficheiro fornecido usa langfuse/langfuse:4 e langfuse/langfuse-worker:4. Essas tags mudam. O Langfuse executa automaticamente as migrações do Postgres e do ClickHouse no arranque. Por isso, um docker compose pull rotineiro meses depois pode tornar-se uma migração de esquema não planeada numa base de dados que não tinha uma cópia de segurança nessa manhã. Fixe ambas numa versão num docker-compose.override.yml. O Compose aplica esse ficheiro sobre o ficheiro fornecido, para que um git pull posterior não substitua as suas alterações.

services:
  langfuse-web:
    image: docker.io/langfuse/langfuse:4.3.1
  langfuse-worker:
    image: docker.io/langfuse/langfuse-worker:4.3.1

A versão 4.3.1 era a versão atual da série 4.3 em agosto de 2026 (a versão 4.4.0 foi lançada entretanto). Consulte a página de releases do projeto no GitHub, fixe a versão que estiver atual no dia da instalação e altere esse número de forma deliberada. As imagens de armazenamento no ficheiro fornecido já estão fixadas nas versões principais, postgres:17, clickhouse-server:25.12 e redis:7, e devem receber o mesmo tratamento. Esta regra não é específica do Langfuse: um tracker de treinos self-hosted openGym executa uma parte desta stack e ainda assim precisa de uma tag git identificada, porque qualquer aplicação que migre a própria base de dados no arranque pode transformar um pull rotineiro numa alteração de esquema.

Inicie a stack.

docker compose up -d
docker compose ps
docker compose logs -f langfuse-worker

O primeiro arranque executa as migrações. Aguarde um ou dois minutos antes de testar os serviços. docker compose ps deve listar seis serviços no estado running. Se o worker reiniciar continuamente, o respetivo log indica o motivo: CLICKHOUSE_MIGRATION_URL usa o protocolo nativo do ClickHouse na porta 9000, não a porta HTTP 8123. Apontá-lo para 8123 falha nesse ponto, enquanto o contentor Web continua a parecer saudável.

Verifique a integridade a partir do próprio servidor.

curl -s "http://localhost:3000/api/public/health?failIfDatabaseUnavailable=true"
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:3000/api/public/ready

Uma chamada simples a /api/public/health apenas confirma que o processo da API está ativo. Esse endpoint ignora deliberadamente a base de dados, para que o serviço continue a responder durante uma interrupção do Postgres. A forma failIfDatabaseUnavailable=true é a adequada para um monitorizar, pois devolve 503 quando a base de dados está inacessível. /api/public/ready devolve 200 quando as migrações terminam e o contentor aceita tráfego. Ambos são testes HTTP normais, pelo que uma página de estado do Uptime Kuma pode monitorizá-los e indicar que a stack está indisponível antes dos seus agentes.

Coloque o TLS à frente e feche as portas extra

O ficheiro Compose fornecido publica 3000:3000 para o contentor web e 9090:9000 para o MinIO. Ambos escutam em todas as interfaces. Num IP público, isto significa que qualquer pessoa que faça uma verificação à porta 3000 chega à página de registo, e qualquer pessoa que faça uma verificação à porta 9090 está a aceder ao bucket que contém os seus prompts brutos.

Uma regra de firewall, por si só, não as fecha. O Docker escreve as suas próprias regras DNAT na tabela nat, e essas regras são avaliadas antes de os pacotes chegarem às regras de filtragem do ufw. Por isso, ufw deny 3000 deixa a porta publicada aberta. Este problema é suficientemente comum para ter um guia próprio: porque as portas publicadas pelo Docker contornam o ufw. Em vez disso, faça o bind no loopback no seu ficheiro de substituição.

services:
  langfuse-web:
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      NEXTAUTH_URL: https://langfuse.example.com
  minio:
    ports:
      - "127.0.0.1:9090:9000"
      - "127.0.0.1:9091:9001"

NEXTAUTH_URL tem de ser o endereço público exato, incluindo o esquema, porque o fluxo de início de sessão constrói o URL de callback a partir desse valor. Se o deixar como http://localhost:3000 atrás de um proxy HTTPS, o percurso de início de sessão envia o browser para um endereço a que não consegue aceder.

Agora aponte um reverse proxy para 127.0.0.1:3000 e deixe-o gerir o certificado. O Traefik no mesmo projeto Compose é a escolha habitual, e os labels de encaminhamento são os descritos em executar várias aplicações atrás de um reverse proxy Traefik. O Caddy faz o mesmo em duas linhas se o Langfuse for a única aplicação nesse servidor. Verifique com curl -sI https://langfuse.example.com/api/public/ready e confirme, a partir de uma segunda máquina, que curl http://YOUR_IP:3000 agora expira por timeout.

Há uma ressalva relativa ao MinIO. O Langfuse serve os ficheiros multimédia associados ao browser através de URLs pré-assinados que apontam para esse endpoint S3. Por isso, se utilizar traces multimodais com imagens ou áudio, um MinIO acessível apenas pelo loopback fará com que esses anexos não sejam carregados. Consulte a página de configuração do armazenamento de blobs antes de colocar o MinIO atrás de um proxy, porque o endpoint escrito no URL pré-assinado tem de corresponder ao endereço que publica. Os traces de texto simples não são afetados.

Crie a sua conta na primeira visita e mantenha a instância sob o seu controlo. Defina LANGFUSE_ALLOWED_ORGANIZATION_CREATORS para o seu próprio endereço de email, para que um estranho que aceda à página não possa criar uma organização no seu servidor. Se já estiver a executar o Authentik como o seu próprio fornecedor de identidade, o Langfuse aceita uma ligação OIDC padrão. Assim, as contas acompanham as restantes aplicações, em vez de ficarem numa lista de palavras-passe que apenas este servidor conhece.

Envie o seu primeiro trace

Crie um projeto na interface web e copie as chaves pública e secreta nas definições do projeto. O SDK Python lê três variáveis de ambiente.

export LANGFUSE_PUBLIC_KEY="pk-lf-..."
export LANGFUSE_SECRET_KEY="sk-lf-..."
export LANGFUSE_BASE_URL="https://langfuse.example.com"

LANGFUSE_BASE_URL é o nome da variável no SDK v4, lançado em março de 2026. Código antigo e guias antigos usam LANGFUSE_HOST. Se os seus traces estiverem a chegar ao Langfuse Cloud em vez do seu servidor, a causa é o URL base não definido, porque o valor predefinido aponta para a instância alojada.

pip install langfuse opentelemetry-instrumentation-anthropic anthropic

import os
from anthropic import Anthropic
from langfuse import get_client, observe
from opentelemetry.instrumentation.anthropic import AnthropicInstrumentor

AnthropicInstrumentor().instrument()
langfuse = get_client()
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

@observe(as_type="tool")
def lookup_order(order_id: str) -> str:
    return f"order {order_id}: shipped"

@observe()
def handle_request(question: str) -> str:
    context = lookup_order("A-1042")
    message = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=512,
        messages=[{"role": "user", "content": f"{context}\n\n{question}"}],
    )
    return message.content[0].text

if __name__ == "__main__":
    assert langfuse.auth_check()
    print(handle_request("Where is my order?"))
    langfuse.flush()

O decorador @observe abre uma observação em torno da função, captura os seus argumentos e o valor devolvido e aninha essa observação na observação que já estiver ativa. AnthropicInstrumentor é a instrumentação OpenTelemetry para o cliente Anthropic e transforma cada chamada messages.create numa geração que inclui o nome do modelo, o consumo de tokens e a latência, sem alterar o ponto da chamada.

Duas chamadas fazem a verificação por si. langfuse.auth_check() retorna False quando as chaves são inválidas ou a URL base está incorreta. Isso é mais rápido do que tentar descobrir por que o dashboard está vazio. langfuse.flush() bloqueia até que os spans enfileirados sejam enviados. Processos de curta duração precisam disso, porque o SDK agrupa os spans em segundo plano e um script que termina imediatamente encerra também o lote ainda não enviado. Se uma equipa inteira estiver a enviar traces, em vez de apenas um script, defina essas três variáveis uma vez no gateway pelo qual os agentes de todos já passam, em vez de as definir na shell de cada pessoa. É assim que um harness OneCLI autoalojado mantém as execuções de todos instrumentadas, enquanto as chaves permanecem num único local.

Por que o ClickHouse continua a crescer?

Os traces são os dados que crescem mais depressa na maioria dos ambientes self-hosted. Cada execução de um agente grava uma linha por etapa, e as entradas e saídas são armazenadas na íntegra. Por isso, um agente conversador com prompts longos produz muito mais bytes por dia do que a aplicação que monitoriza. Se for deixado sem controlo, o ClickHouse enche o disco, e um disco cheio interrompe a ingestão em vez de a tornar mais lenta.

Aqui crescem duas coisas diferentes, e cada uma precisa de uma correção própria.

A primeira são os seus próprios dados de traces. A correção é a definição de retenção. Abra as definições do projeto na interface web e defina um período de retenção de dados em dias. O Langfuse aceita um mínimo de 3 dias. Um job noturno seleciona depois traces, observations, scores e media assets mais antigos do que esse período e elimina-os do ClickHouse e do armazenamento de blobs. O job precisa da permissão DeleteObject no bucket, que as credenciais root do MinIO no ficheiro compose predefinido já têm. A eliminação é permanente. Configure primeiro uma exportação para armazenamento de blobs se precisar de manter o histórico a longo prazo. Não escreva manualmente cláusulas TTL nas próprias tabelas do Langfuse: é o job de retenção que mantém o ClickHouse e o bucket sincronizados, e um TTL manual elimina dados apenas de um dos lados.

Escolha o período com base na utilização real. A análise de custos e qualidade é feita com dados de há alguns dias, não de há vários meses. Trinta dias é um ponto de partida razoável para uma equipa pequena, e 14 dias são suficientes se só abrir um trace quando algo falha.

A segunda são as próprias tabelas de logs do sistema do ClickHouse. Isto surpreende muitas pessoas, porque o disco continua a crescer depois de configurar a retenção. O ClickHouse grava trace_log, text_log, opentelemetry_span_log, metric_log e asynchronous_metric_log para os seus próprios diagnósticos. Essas tabelas são criadas sem TTL, e o Langfuse nunca as lê. Primeiro, descubra para onde foi realmente o espaço em disco.

SELECT table, formatReadableSize(size) AS size, rows FROM (
    SELECT table, database, sum(bytes) AS size, sum(rows) AS rows
    FROM system.parts
    WHERE active
    GROUP BY table, database
    ORDER BY size DESC
)

Execute-o com docker compose exec clickhouse clickhouse-client --password "$CLICKHOUSE_PASSWORD". Se as tabelas do sistema estiverem perto do topo, desative-as com uma sobreposição de configuração, porque o ClickHouse aplica todos os ficheiros de /etc/clickhouse-server/config.d/ sobre a configuração principal durante o arranque.

<clickhouse>
    <trace_log remove="1"/>
    <text_log remove="1"/>
    <opentelemetry_span_log remove="1"/>
    <asynchronous_metric_log remove="1"/>
    <metric_log remove="1"/>
</clickhouse>

Monte-a e reinicie o ClickHouse.

services:
  clickhouse:
    volumes:
      - ./clickhouse-config.d/system-logs.xml:/etc/clickhouse-server/config.d/system-logs.xml:ro

Isto impede novas escritas. As linhas que já estão no disco permanecem lá. Por isso, recupere explicitamente o espaço com DROP TABLE IF EXISTS system.trace_log e faça o mesmo para cada tabela removida. Se preferir manter os diagnósticos, a alternativa é configurar um TTL agressivo em cada tabela em vez de remove="1", conforme descrito na documentação de scaling do Langfuse.

Há mais uma tabela que vale a pena conhecer. blob_storage_file_log regista os ficheiros de eventos enviados para o seu bucket. Se também definir uma política de ciclo de vida no bucket, configure um TTL correspondente na tabela para evitar que os dois mecanismos fiquem dessincronizados.

ALTER TABLE blob_storage_file_log MODIFY TTL created_at + INTERVAL 30 DAY DELETE;

Configure também um alerta simples de df -h no disco de dados. Os traces não crescem de forma regular. Crescem no dia em que publica um agente novo, e o primeiro sinal disso não deve ser uma falha na ingestão.

Faça backup do Postgres e do ClickHouse

Um backup do Langfuse tem três partes. O Postgres armazena os seus utilizadores, organizações, projetos e chaves de API. O ClickHouse armazena os traces. O MinIO armazena os eventos brutos. Se restaurar apenas o Postgres, terá um login funcional, mas sem histórico. Se restaurar apenas o ClickHouse, terá histórico que ninguém consegue consultar porque não consegue fazer login. Essa separação não é exclusiva do Langfuse. Um service desk Chatwoot autoalojado tem a mesma estrutura: um dump do Postgres feito sem o diretório de uploads restaura as conversas, mas todos os anexos desaparecem.

O Postgres é um pg_dump simples, que é o método recomendado na documentação de backup do Langfuse.

docker compose exec -T postgres pg_dump -U postgres postgres \
  | gzip > langfuse-pg-$(date +%F).sql.gz

O ClickHouse exige mais cuidado, porque copiar um diretório de dados ativo enquanto estão a decorrer merges não produz um backup consistente. A abordagem simples num único servidor consiste em parar o container e arquivar o volume.

docker compose stop clickhouse
docker volume ls | grep clickhouse
docker run --rm -v langfuse_langfuse_clickhouse_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/langfuse-ch-$(date +%F).tar.gz -C /data .
docker compose start clickhouse

Use o nome do volume apresentado por docker volume ls, não o nome escrito no YAML. O ficheiro declara langfuse_clickhouse_data, e o Compose acrescenta o nome do projeto como prefixo. Assim, um clone num diretório chamado langfuse produz langfuse_langfuse_clickhouse_data. Se usar o nome errado, docker run cria um volume novo e vazio sem apresentar qualquer erro, e o seu arquivo não contém nada.

O container web grava cada evento recebido no bucket antes de o worker o processar. Por isso, uma paragem curta do ClickHouse normalmente apenas faz com que o worker tente processar os eventos novamente depois. Faça isto num período de pouca utilização e mantenha a paragem curta. Numa instância com mais tráfego, a própria instrução BACKUP DATABASE default TO S3(...) do ClickHouse grava um backup consistente sem parar o servidor. O MinIO é a terceira peça. mc mirror ou a replicação do MinIO para um bucket externo cobre essa parte. Independentemente do método usado, retire o backup do servidor. É esse o objetivo de backups restic encriptados num VPS.

O Redis não precisa de backup. Armazena a fila e a cache. Se o perder, perde os eventos que estão a ser processados naquele momento, mas nada mais antigo.

A limitação de consistência é real e deve ser indicada claramente. O Postgres e o ClickHouse são exportados em momentos diferentes. Por isso, uma restauração pode deixar uma linha de projeto sem traces ou traces pertencentes a um projeto que já não existe. O Langfuse tolera essa situação, mas faça os dois dumps com pouca diferença de tempo e durante um período de pouco tráfego. O bucket de eventos é a verdadeira rede de segurança, porque o Langfuse persiste nele cada evento recebido antes de o processar.

Restaure os dados numa stack de teste pelo menos uma vez. Assim, pode descobrir agora que o nome do volume está errado, em vez de o descobrir durante uma indisponibilidade.

O que analisar primeiro

Quatro itens justificam o seu lugar na primeira semana.

• Custo por trace. O Langfuse calcula o custo com base no nome do modelo e no uso de tokens. Ordene os traces por custo e leia o mais caro do início ao fim. Normalmente, a causa é um prompt que cresceu: um documento inteiro colado no contexto ou um histórico de conversa que ninguém reduz. Quando conseguir ver isso, controlar o custo de um agente de IA deixa de ser uma estimativa e passa a ser uma tarefa de engenharia.
• Divisão do uso de tokens entre entrada e saída. Os tokens de entrada são numerosos e baratos. Os tokens de saída são poucos e caros. Os tokens de entrada em cache são ainda mais baratos. A mesma contabilidade é explicada em como é contabilizado o uso de tokens do Claude Code e aplica-se a qualquer agente que escreva.
• Percentis de latência. A mediana oculta o problema. É nos p95 e p99 que ocorrem os timeouts. Dentro de um loop de agente, uma chamada de ferramenta lenta no p95 é multiplicada pelo número de iterações.
• Chamadas de ferramentas que falharam. Filtre as observações pelo nível ERROR. Uma ferramenta que falha 5% das vezes pode não aparecer numa taxa agregada de sucesso, mas fica evidente nos traces, onde é possível monitorizar o modelo a tentar novamente e depois a consumir tokens para contornar o problema.

Defina a janela de retenção e escolha o dashboard que vai consultar semanalmente, no mesmo dia em que fizer o deploy. Uma ferramenta de observabilidade que ninguém abre é uma base de dados que acaba por encher um disco.

FAQ

De quanta memória precisa o Langfuse autoalojado?

Planeie 4 núcleos de CPU e 16 GiB de memória, que é o recomendado no guia do Langfuse Docker Compose para uma única máquina virtual, além de cerca de 100 GiB de armazenamento. Os mínimos publicados para os componentes são 8 GiB para o ClickHouse e 4 GiB para cada contentor web e worker. O Postgres, o Redis e o MinIO também precisam de memória adicional. Oito GiB são suficientes para a instância de um programador. Dois GiB não são: o kernel termina o ClickHouse durante as compactações em segundo plano, e dmesg mostra Out of memory: Killed process.

Porque é que o disco do ClickHouse continua a encher depois de definir a retenção de dados?

A definição de retenção abrange apenas os dados próprios do Langfuse. O ClickHouse também escreve separadamente as tabelas de diagnóstico trace_log, text_log, opentelemetry_span_log, metric_log e asynchronous_metric_log, que não têm TTL definido. Consulte system.parts agrupado por tabela para ver qual é a maior. Em seguida, desative as tabelas não utilizadas com uma entrada remove="1" num ficheiro sob /etc/clickhouse-server/config.d/, reinicie o ClickHouse e elimine as tabelas existentes para recuperar o espaço já utilizado.

Qual é o período mínimo de retenção de dados no Langfuse?

Três dias. A retenção é definida por projeto nas definições do projeto ou através da API de projetos. Um trabalho noturno elimina do ClickHouse e do armazenamento de blobs os traces, as observações, as pontuações e os recursos multimédia mais antigos do que esse período. A eliminação não pode ser anulada. Configure primeiro uma exportação para armazenamento de blobs se precisar de manter histórico para além desse período.

Tenho de fazer backup do Postgres e do ClickHouse?

Sim, porque armazenam dados diferentes. O Postgres armazena utilizadores, organizações, projetos e chaves de API. O ClickHouse armazena os próprios dados dos traces. Uma reposição apenas do Postgres deixa uma instância na qual é possível iniciar sessão, mas sem dados. Faça também backup do bucket do MinIO, porque contém os eventos brutos que o Langfuse persiste quando chegam. É o elemento mais próximo de uma fonte de verdade na stack.

Posso apontar uma configuração OpenTelemetry existente para um Langfuse autoalojado?

Sim. O Langfuse v4 e os respetivos SDKs v4 são baseados em OpenTelemetry, e as instrumentações OTel do Anthropic e do OpenAI exportam diretamente para ele. Em Python, execute pip install langfuse opentelemetry-instrumentation-anthropic, chame AnthropicInstrumentor().instrument() uma vez no arranque e defina LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY e LANGFUSE_BASE_URL para o seu próprio host. Confirme com langfuse.auth_check() antes de procurar um dashboard em falta.