Tự host Langfuse để trace AI agent trên VPS

Vì sao phải trace AI agent

Bạn self-host Langfuse để biết agent của mình thực sự đã làm gì trong một lần chạy. Langfuse là công cụ observability mã nguồn mở dành cho LLM (large language model). Nó ghi lại mọi prompt, mọi phản hồi từ model, mọi tool call và mọi token, rồi nhóm chúng vào một trace duy nhất mà bạn có thể mở và đọc. Chạy Langfuse trên VPS của mình nghĩa là các prompt đó không rời khỏi server do bạn kiểm soát.

Lý do cần làm việc này rất rõ ràng. Bạn không thể sửa vấn đề về chi phí hoặc chất lượng nếu không nhìn thấy chúng. Hóa đơn của nhà cung cấp cho biết chi phí vào thứ Ba cao gấp 4 lần thứ Hai. Trace cho biết lần chạy agent nào gây ra việc đó, prompt nào tăng lên 40,000 token và vòng retry nào đã chạy 9 lần trước khi bỏ cuộc. Hóa đơn cho bạn con số. Trace cho bạn đoạn code tạo ra con số đó.

Guide này dùng 3 thuật ngữ. Trace là một lần chạy end-to-end của agent. Observation là một bước bên trong lần chạy đó: span dành cho code thông thường, generation dành cho lần gọi model. Score là một con số gắn với trace, do người review hoặc evaluator tự động tạo ra. Langfuse sử dụng OpenTelemetry (OTel), tiêu chuẩn vendor-neutral cho distributed tracing, nên instrumentation bạn đã có có thể trỏ đến Langfuse.

Langfuse self-host thực sự chạy những gì

Langfuse v4 không chỉ là một container. Nó gồm 2 container ứng dụng và 4 service lưu trữ. Trên một VPS, cả 6 thành phần này đều chạy trên máy của bạn.

• langfuse-web cung cấp giao diện web và ingestion API.
• langfuse-worker xử lý queue ở background. Nó phân tích các batch ingestion, tính chi phí và chạy retention job hằng đêm.
• Postgres lưu dữ liệu giao dịch như user, tổ chức, project, API key và prompt.
• ClickHouse lưu dữ liệu trace, tức observation và score. Đây là column store được xây dựng cho các truy vấn phân tích. Vì vậy, dashboard trên hơn 100 triệu dòng vẫn trả kết quả nhanh.
• Redis là queue và cache nằm giữa web và worker.
• MinIO cung cấp object storage tương thích với S3 ngay trên máy. Nó lưu mọi event thô nhận được cùng với media bạn đính kèm.

Langfuse công bố resource tối thiểu cho 3 component trực tiếp xử lý dữ liệu.

[
  {
    "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
  }
]

Riêng ClickHouse cần 8 GiB memory. Web container và worker mỗi thành phần cần 4 GiB. Đây là mức tối thiểu được công bố cho 3 component mà Langfuse đưa ra sizing. Postgres, Redis và MinIO vẫn cần thêm memory. Hướng dẫn Docker Compose của chính project khuyến nghị máy có 4 core, 16 GiB memory và khoảng 100 GiB storage. Con số này phù hợp với phép tính trên, không phải mức dự phòng được cộng thêm.

Không nên chạy trên gói 2 GiB. ClickHouse khởi động và nhận write trong một thời gian, sau đó bị dừng trong lúc background merge vì merge phải nạp các part lớn của table vào memory. Bạn sẽ thấy docker compose ps báo clickhouse container ở trạng thái restarting, dmesg chứa một dòng như Out of memory: Killed process 1234 (clickhouse-serv), và mọi dashboard Langfuse đều trả về 500. Khi tải nhẹ hơn, ClickHouse có thể từ chối query thay vào đó và ghi log DB::Exception: Memory limit (total) exceeded. 8 GiB có thể chạy được cho một developer gửi vài nghìn trace mỗi ngày. Nên dự trù 16 GiB.

Triển khai Langfuse bằng Docker Compose

Clone repository. Stack, cách kết nối các thành phần và môi trường mặc định đều nằm trong docker-compose.yml.

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

Mọi giá trị cần thay đổi trong file đó đều được đánh dấu # CHANGEME. Trước tiên, hãy tạo 3 application secret.

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

ENCRYPTION_KEY phải có độ dài 256 bit và được viết thành 64 ký tự hex. Đây chính xác là định dạng mà openssl rand -hex 32 in ra. Nó mã hóa các giá trị nhạy cảm khi lưu trữ, bao gồm mọi LLM provider key bạn lưu trong instance. Nếu thay đổi sau khi đã có dữ liệu, các row đó sẽ không thể giải mã nữa. Vì vậy, hãy coi giá trị này là cố định ngay từ lần boot đầu tiên. SALT được dùng để băm Langfuse API key, nên thay đổi giá trị này sẽ vô hiệu hóa mọi key mà agent đang sử dụng.

Tiếp theo, đặt POSTGRES_PASSWORD, CLICKHOUSE_PASSWORD, REDIS_AUTH và MINIO_ROOT_PASSWORD. Mật khẩu MinIO xuất hiện ở 4 vị trí: một lần dưới dạng MINIO_ROOT_PASSWORD, sau đó là LANGFUSE_S3_EVENT_UPLOAD_SECRET_ACCESS_KEY, LANGFUSE_S3_MEDIA_UPLOAD_SECRET_ACCESS_KEY và LANGFUSE_S3_BATCH_EXPORT_SECRET_ACCESS_KEY. Nếu bỏ sót một vị trí, MinIO sẽ từ chối client đó với SignatureDoesNotMatch. Lỗi này xuất hiện trong worker log, trong khi web interface vẫn có vẻ hoạt động bình thường. Lưu các giá trị này trong env file thay vì tracked compose file là cách được trình bày trong env file và secret của Docker Compose.

Cố định image tag trước khi bắt đầu

File được cung cấp sử dụng langfuse/langfuse:4 và langfuse/langfuse-worker:4. Các tag này có thể thay đổi. Langfuse tự động chạy migration cho Postgres và ClickHouse khi khởi động. Vì vậy, một lần docker compose pull thông thường vài tháng sau có thể trở thành schema migration ngoài kế hoạch trên database mà sáng hôm đó bạn chưa backup. Cố định cả 2 image về cùng một release trong docker-compose.override.yml. Compose sẽ merge file này lên trên file được cung cấp, nên một lần git pull sau đó sẽ không ghi đè các chỉnh sửa của bạn.

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

Version 4.3.1 là bản 4.3 hiện tại vào tháng 8 năm 2026 (4.4.0 đã được phát hành sau đó). Hãy kiểm tra trang GitHub releases của project, cố định version hiện tại tại thời điểm triển khai, rồi chủ động thay đổi version đó khi cần. Các image lưu trữ trong file được cung cấp đã được cố định theo major version: postgres:17, clickhouse-server:25.12 và redis:7. Các image này cũng nên được xử lý tương tự.

Khởi động stack.

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

Lần boot đầu tiên sẽ chạy migration, nên hãy chờ 1 hoặc 2 phút trước khi kiểm tra phản hồi. docker compose ps phải liệt kê 6 service ở trạng thái running. Nếu worker restart liên tục, log của worker sẽ cho biết nguyên nhân: CLICKHOUSE_MIGRATION_URL sử dụng ClickHouse native protocol trên port 9000, không phải HTTP port 8123. Trỏ nó đến port 8123 sẽ gây lỗi, trong khi web container vẫn có vẻ hoạt động bình thường.

Kiểm tra health ngay trên máy chủ.

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

Một request /api/public/health đơn giản chỉ chứng minh API process đang hoạt động, vì endpoint này cố ý bỏ qua database để service vẫn tiếp tục phục vụ khi Postgres tạm thời gặp sự cố. Dạng failIfDatabaseUnavailable=true là endpoint phù hợp để monitor, và nó trả về 503 khi không thể truy cập database. /api/public/ready trả về 200 sau khi migration hoàn tất và container sẵn sàng nhận traffic. Cả 2 đều là HTTP check thông thường, nên trang trạng thái Uptime Kuma có thể monitor chúng và phát hiện stack down trước agent của bạn.

Đặt TLS phía trước và đóng các cổng thừa

File compose đi kèm publish 3000:3000 cho web container và 9090:9000 cho MinIO. Cả hai đều bind trên mọi interface. Với IP public, điều đó có nghĩa là bất kỳ ai scan cổng 3000 đều truy cập được trang đăng ký, còn bất kỳ ai scan cổng 9090 đều đang truy cập bucket chứa các prompt thô của bạn.

Chỉ thêm rule firewall thì không đóng được các cổng này. Docker tự ghi các rule DNAT vào bảng nat, và các rule đó được xử lý trước khi packet đến các filter rule của ufw. Vì vậy, ufw deny 3000 vẫn để cổng đã publish mở. Vấn đề này phổ biến đến mức có hẳn một hướng dẫn riêng: vì sao các cổng được Docker publish bypass ufw. Thay vào đó, hãy bind trên loopback trong file override.

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 phải là địa chỉ public chính xác, bao gồm cả scheme, vì login flow tạo callback URL từ giá trị đó. Nếu để là http://localhost:3000 phía sau HTTPS proxy, round trip đăng nhập sẽ đưa browser đến một địa chỉ mà nó không thể truy cập.

Bây giờ trỏ reverse proxy vào 127.0.0.1:3000 và để proxy quản lý certificate. Traefik trong cùng Compose project là lựa chọn thường dùng; các routing label được trình bày trong chạy nhiều app phía sau một Traefik reverse proxy. Nếu Langfuse là ứng dụng duy nhất trên máy, Caddy cũng làm được việc này chỉ với 2 dòng. Xác minh bằng curl -sI https://langfuse.example.com/api/public/ready, sau đó dùng máy thứ hai để xác nhận rằng curl http://YOUR_IP:3000 hiện đã timeout.

Có một điểm cần lưu ý về MinIO. Langfuse cung cấp media đính kèm cho browser thông qua presigned URL trỏ đến S3 endpoint đó. Vì vậy, nếu bạn dùng trace đa phương thức có image hoặc audio, MinIO chỉ bind trên loopback sẽ khiến các file đính kèm không tải được. Hãy đọc trang cấu hình blob storage trước khi proxy MinIO, vì endpoint được ghi vào presigned URL phải khớp với endpoint bạn publish. Trace chỉ có văn bản không bị ảnh hưởng.

Tạo account trong lần truy cập đầu tiên, sau đó đảm bảo instance thuộc quyền quản lý của bạn. Đặt LANGFUSE_ALLOWED_ORGANIZATION_CREATORS thành địa chỉ email của bạn, để người lạ truy cập được trang không thể tạo organisation trên server của bạn.

Gửi trace đầu tiên

Tạo một project trong giao diện web, rồi sao chép public key và secret key từ phần cài đặt của project. Python SDK đọc 3 biến môi trường.

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

LANGFUSE_BASE_URL là tên biến trong SDK v4, được phát hành vào tháng 3 năm 2026. Code và hướng dẫn cũ dùng LANGFUSE_HOST. Nếu trace được gửi đến Langfuse Cloud thay vì server của bạn, nguyên nhân là base URL chưa được đặt, vì giá trị mặc định trỏ đến instance được host.

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()

Decorator @observe mở một observation quanh function, ghi lại các argument và giá trị trả về, rồi lồng observation đó dưới observation đang active. AnthropicInstrumentor là instrumentation của OpenTelemetry cho Anthropic client. Nó biến mỗi lần gọi messages.create thành một generation có tên model, mức sử dụng token và latency, mà không cần thay đổi tại vị trí gọi.

Hai lệnh gọi sẽ tự kiểm tra cho bạn. langfuse.auth_check() trả về False nếu key không hợp lệ hoặc base URL sai. Cách này nhanh hơn việc phải đoán tại sao dashboard trống. langfuse.flush() chặn cho đến khi các span đang xếp hàng được gửi đi. Các process chạy trong thời gian ngắn cần lệnh này, vì SDK batch span ở background và một script thoát ngay sẽ kết thúc cùng batch chưa được gửi.

Vì sao ClickHouse cứ tăng dung lượng?

Trace là loại dữ liệu tăng nhanh nhất mà phần lớn người dùng tự host từng gặp. Mỗi lần agent chạy sẽ ghi một dòng cho từng bước. Input và output được lưu đầy đủ, nên một agent thường xuyên trao đổi với prompt dài có thể tạo ra nhiều byte mỗi ngày hơn cả ứng dụng mà nó theo dõi. Nếu không xử lý, ClickHouse sẽ làm đầy disk. Khi disk đầy, hệ thống sẽ dừng ingestion thay vì chỉ chạy chậm hơn.

Có 2 loại dữ liệu tăng ở đây và mỗi loại cần một cách xử lý riêng.

Loại thứ nhất là trace data của chính bạn. Cách xử lý là cấu hình retention. Mở phần cài đặt project trong web interface và đặt thời gian lưu dữ liệu theo ngày. Langfuse chấp nhận tối thiểu 3 ngày. Sau đó, một job chạy hằng đêm sẽ chọn các trace, observation, score và media asset cũ hơn khoảng thời gian này rồi xóa chúng khỏi ClickHouse và blob storage. Job cần quyền DeleteObject trên bucket; thông tin xác thực MinIO root trong file compose mặc định đã có quyền này. Việc xóa là vĩnh viễn, nên hãy cấu hình export sang blob storage trước nếu bạn cần lưu lịch sử dài hạn. Không tự viết các mệnh đề TTL trên bảng riêng của Langfuse. Chính retention job giữ cho ClickHouse và bucket đồng bộ với nhau, còn TTL thủ công chỉ xóa một phía.

Chọn khoảng thời gian dựa trên cách bạn thực sự sử dụng dữ liệu. Việc xem xét chi phí và chất lượng thường dùng dữ liệu từ vài ngày trước, không phải dữ liệu từ vài tháng trước. 30 ngày là điểm bắt đầu hợp lý cho team nhỏ. 14 ngày là đủ nếu bạn chỉ mở trace khi có sự cố.

Loại thứ hai là các bảng system log của ClickHouse. Đây là phần thường gây bất ngờ, vì disk vẫn tiếp tục đầy sau khi đã cấu hình retention. ClickHouse ghi trace_log, text_log, opentelemetry_span_log, metric_log và asynchronous_metric_log cho hoạt động chẩn đoán của chính nó. Các bảng này không có TTL mặc định và Langfuse không bao giờ đọc chúng. Trước tiên, hãy xác định chính xác dữ liệu đã chiếm disk ở đâu.

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
)

Chạy bằng docker compose exec clickhouse clickhouse-client --password "$CLICKHOUSE_PASSWORD". Nếu các system table nằm gần đầu danh sách, hãy tắt chúng bằng config overlay, vì ClickHouse sẽ merge mọi file trong /etc/clickhouse-server/config.d/ lên config chính khi khởi động.

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

Mount file đó rồi restart ClickHouse.

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

Cách này ngăn các bản ghi mới được ghi vào. Các row đã có trên disk vẫn còn, nên hãy thu hồi dung lượng bằng DROP TABLE IF EXISTS system.trace_log và thực hiện tương tự cho từng bảng đã xóa. Nếu muốn giữ dữ liệu chẩn đoán, cách khác là đặt TTL ngắn trên từng bảng thay vì dùng remove="1". Langfuse scaling docs có mô tả cụ thể cách này.

Có thêm một bảng bạn nên biết. blob_storage_file_log theo dõi các event file được upload lên bucket. Nếu bạn cũng đặt lifecycle policy trên bucket, hãy đặt TTL tương ứng cho bảng để hai bên không bị lệch.

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

Đồng thời, hãy đặt alert df -h trên data disk. Trace không tăng đều. Chúng có thể tăng đột biến vào ngày bạn deploy một agent mới. Dấu hiệu đầu tiên của việc đó không nên là ingestion bị lỗi.

Sao lưu Postgres và ClickHouse

Một bản sao lưu Langfuse có 3 phần. Postgres lưu người dùng, tổ chức, project và API key. ClickHouse lưu trace. MinIO lưu event thô. Chỉ khôi phục Postgres thì bạn có thể đăng nhập nhưng không có lịch sử. Chỉ khôi phục ClickHouse thì bạn có lịch sử nhưng không ai đăng nhập để xem được.

Postgres là một pg_dump thông thường. Đây là cách mà tài liệu sao lưu Langfuse khuyến nghị.

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

ClickHouse cần cẩn thận hơn, vì sao chép một data directory đang hoạt động trong lúc merge chạy sẽ không tạo ra bản sao lưu nhất quán. Cách đơn giản trên một máy là dừng container rồi archive 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

Dùng tên volume mà docker volume ls in ra, không dùng tên ghi trong YAML. File khai báo langfuse_clickhouse_data, còn Compose thêm tiền tố là tên project, nên bản clone trong thư mục tên langfuse sẽ tạo ra langfuse_langfuse_clickhouse_data. Nếu dùng sai tên, docker run sẽ tạo một volume mới rỗng mà không báo lỗi, và archive của bạn sẽ không chứa gì.

Web container ghi mọi event đến vào bucket trước khi worker xử lý, nên việc dừng ClickHouse trong thời gian ngắn chủ yếu khiến worker retry sau đó. Hãy thực hiện vào giờ ít tải và giữ thời gian dừng càng ngắn càng tốt. Với instance bận hơn, câu lệnh BACKUP DATABASE default TO S3(...) của ClickHouse sẽ ghi một bản sao lưu nhất quán mà không cần dừng server. MinIO là phần thứ ba; mc mirror hoặc replication của MinIO sang bucket bên ngoài server sẽ xử lý phần này. Dù tạo bản sao lưu theo cách nào, hãy đưa nó ra khỏi server. Đó là mục đích của bản sao lưu restic được mã hóa trên VPS.

Redis không cần sao lưu. Nó lưu queue và cache, nên mất Redis chỉ làm mất các event đang được xử lý, không làm mất dữ liệu cũ hơn.

Điểm hạn chế về tính nhất quán là có thật và cần nói rõ. Postgres và ClickHouse được dump ở các thời điểm khác nhau, nên quá trình khôi phục có thể để lại một project row không có trace, hoặc trace thuộc về một project không còn tồn tại. Langfuse vẫn xử lý được tình huống này, nhưng hãy tạo cả 2 bản dump gần nhau và trong thời gian ít traffic. Event bucket mới là lớp an toàn thực sự, vì Langfuse lưu mọi event đến vào đó trước khi xử lý.

Hãy khôi phục vào một scratch stack ít nhất 1 lần. Đây là cách phát hiện tên volume sai ngay bây giờ, thay vì đến lúc hệ thống gặp sự cố mới phát hiện.

Điều cần xem đầu tiên

Bốn mục sau nên được ưu tiên trong tuần đầu tiên.

• Chi phí trên mỗi trace. Langfuse tính chi phí dựa trên tên model và lượng token đã sử dụng, vì vậy hãy sắp xếp các trace theo chi phí rồi đọc toàn bộ trace đắt nhất. Nguyên nhân thường là prompt đã phình to: toàn bộ tài liệu được dán vào context hoặc lịch sử hội thoại không được cắt bớt. Khi đã nhìn thấy nguyên nhân, kiểm soát chi phí của AI agent sẽ trở thành một công việc kỹ thuật thay vì phỏng đoán.
• Lượng token được tách theo input và output. Input token thường nhiều và rẻ, output token ít hơn nhưng đắt hơn, còn input được cache thì rẻ hơn nữa. Cách tính này được giải thích trong cách tính lượng token của Claude Code và áp dụng cho mọi agent bạn tự viết.
• Các percentile của latency. Median thường che khuất vấn đề. p95 và p99 là nơi các timeout xuất hiện, và trong vòng lặp của agent, một tool call chậm ở p95 sẽ bị nhân lên theo số lần lặp.
• Tool call thất bại. Lọc các observation theo level ERROR. Một tool thất bại 5% số lần sẽ khó nhận ra trong tỷ lệ thành công tổng hợp, nhưng rất rõ trong trace, nơi bạn có thể theo dõi model retry rồi tiêu tốn thêm token để xử lý tình huống đó.

Hãy đặt retention window và chọn dashboard mà bạn sẽ kiểm tra hằng tuần vào cùng ngày triển khai. Một công cụ observability không ai mở sẽ trở thành database làm đầy disk.

FAQ

Một phiên bản Langfuse tự host cần bao nhiêu bộ nhớ?

Hãy chuẩn bị 4 lõi CPU và 16 GiB bộ nhớ. Đây là cấu hình mà hướng dẫn Langfuse Docker Compose khuyến nghị cho một máy ảo, cùng khoảng 100 GiB dung lượng lưu trữ. Mức tối thiểu được công bố cho từng thành phần là 8 GiB cho ClickHouse và 4 GiB cho mỗi container web và worker. Postgres, Redis và MinIO vẫn cần thêm bộ nhớ ngoài các mức này. 8 GiB đủ chạy instance của một developer. 2 GiB thì không đủ: kernel sẽ kill ClickHouse trong lúc thực hiện background merge, và dmesg hiển thị Out of memory: Killed process.

Tại sao disk ClickHouse vẫn đầy sau khi tôi đặt thời gian lưu dữ liệu?

Thiết lập retention chỉ áp dụng cho dữ liệu riêng của Langfuse. ClickHouse vẫn ghi riêng các bảng chẩn đoán trace_log, text_log, opentelemetry_span_log, metric_log và asynchronous_metric_log, nhưng các bảng này không có TTL. Query system.parts theo từng bảng để xem bảng nào lớn nhất, sau đó tắt các bảng không dùng bằng một mục remove="1" trong file nằm dưới /etc/clickhouse-server/config.d/. Khởi động lại ClickHouse, rồi drop các bảng hiện có để thu hồi dung lượng đã sử dụng.

Thời gian lưu dữ liệu tối thiểu trong Langfuse là bao lâu?

3 ngày. Retention được đặt theo từng project trong phần cài đặt project hoặc thông qua projects API. Một nightly job sẽ xóa trace, observation, score và media asset cũ hơn khoảng thời gian này khỏi cả ClickHouse và blob storage. Không thể hoàn tác việc xóa. Vì vậy, hãy cấu hình blob storage export trước nếu bạn cần giữ lịch sử lâu hơn khoảng thời gian này.

Tôi có phải backup cả Postgres và ClickHouse không?

Có, vì mỗi hệ thống lưu các loại dữ liệu khác nhau. Postgres lưu user, organisation, project và API key. ClickHouse lưu chính dữ liệu trace. Khôi phục chỉ từ Postgres sẽ tạo ra một instance mà bạn có thể đăng nhập nhưng không có dữ liệu. Hãy backup cả bucket MinIO, vì bucket này chứa raw event mà Langfuse lưu khi nhận được. Đây là dữ liệu gần với source of truth nhất trong stack.

Tôi có thể trỏ setup OpenTelemetry hiện có vào Langfuse tự host không?

Có. Langfuse v4 và các SDK v4 của Langfuse được xây dựng trên OpenTelemetry. Các instrumentation OTel cho Anthropic và OpenAI có thể export trực tiếp vào đó. Với Python, chạy pip install langfuse opentelemetry-instrumentation-anthropic, gọi AnthropicInstrumentor().instrument() một lần khi startup, rồi đặt LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY và LANGFUSE_BASE_URL thành host của bạn. Xác nhận bằng langfuse.auth_check() trước khi tìm nguyên nhân dashboard bị thiếu.