Pydantic Logfire: trace agent Python trên OpenTelemetry, phần nào mở và phần nào không

Ngày thứ ba ở khách hàng, agent trả lời sai và mất 40 giây mới trả lời. Chưa ai biết thời gian ấy nằm ở đâu: lời gọi LLM, query SQL hay một API nội bộ.

Logfire nhắm đúng vào kiểu tình huống này. Pydantic giới thiệu nó là nền tảng AI engineering trọn gói, xếp mọi lời gọi LLM, request và query của agent, service và host lên cùng một timeline.

Với một FDE, giá trị nằm ở tốc độ. Bạn không có hai tuần để dựng stack observability trước khi debug, và khách hàng cũng không chờ được. Có điều, công cụ này mở ở chỗ này và đóng ở chỗ khác, nên bạn cần biết rõ ranh giới trước khi đề xuất nó.

Cái gì thực sự chạy trong code của bạn?

Repo chính thức mô tả SDK Python là một wrapper “có chính kiến” bọc quanh OpenTelemetry, chuẩn mở cho traces, metrics và logs. SDK có cả bản TypeScript và Rust, tất cả theo giấy phép MIT. Logfire có hơn 40 tích hợp sẵn, trong đó có FastAPI, Django, SQLAlchemy và HTTPX.

Chi tiết đáng chú ý nhất là OpenTelemetry: dữ liệu bạn thu được đi theo chuẩn mở chứ không phải định dạng riêng của Pydantic. Trang so sánh của Pydantic gọi instrumentation của Logfire là “hoàn toàn portable”, nhưng vì SDK là wrapper riêng, các lệnh như logfire.configure() hay logfire.instrument_fastapi(app) vẫn là API của Logfire.

Dữ liệu được truy vấn bằng SQL chuẩn chứ không phải một ngôn ngữ truy vấn riêng. Ở site khách hàng, chuyện này lợi hơn bạn tưởng: data engineer bên họ đọc được ngay câu query của bạn, khỏi học cú pháp mới.

Bốn bước, một service FastAPI

Thử hình dung khách hàng có một service FastAPI bọc agent hỗ trợ khách hàng. Theo repo, quy trình bắt đầu gồm cài gói, xác thực, cấu hình rồi bật tích hợp framework:

pip install logfire
logfire auth

import logfire
from fastapi import FastAPI

app = FastAPI()
logfire.configure()
logfire.instrument_fastapi(app)

Từ đây mỗi request vào service thành một trace. Gắn thêm các tích hợp như SQLAlchemy hay HTTPX thì query database và lời gọi HTTP ra ngoài sẽ nằm chung timeline với request. Quay lại case 40 giây, bạn sẽ thấy ngay đoạn nào chiếm thời gian, thay vì đi rải print khắp codebase của người khác.

Việc nên làm đầu tiên ở khách hàng là gắn instrument cho đúng một service, đường đi quan trọng nhất của agent, rồi viết một câu SQL lọc ra các request chậm nhất. Có câu trả lời cụ thể trong buổi đầu tiên đáng giá hơn một dashboard đẹp mà không ai mở.

Gói miễn phí có đủ cho pilot không?

Gói Personal miễn phí, có credit tương đương 10 triệu logs, spans và metrics mỗi tháng, và bị chặn cứng ở mức đó. Dữ liệu được giữ 30 ngày ở Personal và Team, tối đa 90 ngày ở Growth. Team giá $49/tháng, Growth $249/tháng, phần vượt mức tính $2 cho mỗi triệu bản ghi, và gói trả phí nào cũng có price cap để đặt trần chi tiêu.

Thử làm một phép tính. Giả sử mỗi request của agent sinh ra 25 span: request HTTP, vài lời gọi LLM, vài query. Với 2.000 request mỗi ngày, bạn có 50.000 span một ngày, khoảng 1,5 triệu một tháng, vẫn nằm gọn trong gói miễn phí.

Lên 20.000 request mỗi ngày thì con số thành khoảng 15 triệu một tháng, vượt trần Personal. Ở gói Team, bạn trả phí cơ bản $49 mỗi tháng, cộng 5 triệu bản ghi dư ra nhân $2 mỗi triệu là $10, tức khoảng $59 mỗi tháng. Hãy làm phép tính này với số liệu thật của khách hàng trước khi hứa “cứ dùng bản free”.

Những giới hạn cần nói trước với khách hàng

Giới hạn lớn nhất không nằm ở giá. UI và backend của Logfire là mã đóng, muốn self-host phải mua giấy phép enterprise. Với khách hàng ngân hàng, y tế hay khu vực công, nơi trace có thể chứa prompt và dữ liệu khách hàng, không có giấy phép đó thì trace sẽ nằm trên nền tảng của Pydantic chứ không ở trong hạ tầng của họ.

Retention 30 ngày cũng là một giới hạn thật. Nếu khách hàng cần đối chiếu sự cố của quý trước, bạn phải tính đến gói Growth hoặc tự xuất dữ liệu ra chỗ khác.

Nếu khách hàng đã đổ nhiều công vào LangGraph, Pydantic tự thừa nhận rằng những đội này có thể chuộng UI trạng thái đồ thị chuyên biệt bên đối thủ. Phần đồ thị của Logfire là sơ đồ Mermaid sinh từ code cho Pydantic Graph.

Theo chính Pydantic, Logfire phủ toàn stack còn LangSmith thiên về LLM và agent; nhưng vì đây là trang so sánh của vendor, hãy tự kiểm chứng trên workload của khách hàng.

Nên học gì trước?

Hãy học OpenTelemetry trước khi học Logfire. Logfire xây trên chuẩn mở này, nên nắm vững trace, span và cách chúng nối với nhau sẽ giúp bạn đọc được dữ liệu ngay cả khi khách hàng chọn một backend khác. Logfire là chỗ dễ để thấy các khái niệm ấy chạy thật, vì chỉ vài dòng code là đã có trace.

Khi đọc JD, hãy để ý các cụm như “observability”, “OpenTelemetry” hay “production LLM systems”. Trên CV, một dòng kiểu “gắn tracing OTel cho agent FastAPI, tìm ra nút thắt làm chậm phản hồi” thuyết phục hơn nhiều so với một dòng liệt kê tên công cụ.

Ở site khách hàng, câu hỏi “dữ liệu này đi đâu?” sớm muộn cũng sẽ có người đặt ra. FDE giỏi là người đã có câu trả lời trước khi chạy logfire auth.