Khi không có thông báo lỗi để đọc, nhật ký là đôi mắt của bạn bên trong chương trình: nó cho biết luồng chạy đã đi qua đâu, giá trị nào đi vào và đi ra. Ghi nhật ký đúng chỗ thì một lần chạy là đủ thấy nguyên nhân. Ghi bừa thì màn hình ngập chữ mà vẫn không biết gì thêm.
Trợ lý AI giúp được nhiều ở việc này: đề xuất nên ghi ở đâu, ghi giá trị nào, viết sẵn dòng ghi theo đúng thư viện dự án đang dùng, và đọc giúp những đoạn nhật ký dài. Bài này đi qua cách giao những việc đó cho AI, các nguyên tắc để nhật ký không thành rác, và chuyện che dữ liệu trước khi dán nhật ký ra ngoài.
Lệnh in tạm và nhật ký thật: dùng cái nào lúc nào
Lệnh in đơn giản như print trong Python, console.log trong JavaScript hay var_dump trong PHP là công cụ gỡ lỗi nhanh nhất. Bạn thêm vào, chạy, đọc, xoá. Nó hợp với lỗi tái hiện được ngay trên máy mình, trong vài phút. Nhược điểm là dễ quên xoá, và dòng in tạm lọt lên máy chủ thật có thể làm vỡ định dạng đầu ra hoặc lộ dữ liệu.
Nhật ký thật dùng thư viện ghi nhật ký của ngôn ngữ, có mức độ, có thời gian, có nơi lưu. Python có sẵn mô-đun logging, Node.js có nhiều thư viện phổ biến, PHP có hàm error_log và các thư viện theo chuẩn PSR-3. Nhật ký thật hợp với lỗi chỉ xảy ra trên máy chủ, lỗi thỉnh thoảng mới có, lỗi cần theo dõi qua nhiều ngày. Nó ở lại trong mã, bật tắt bằng mức độ chứ không phải bằng cách xoá dòng.
Nguyên tắc dễ nhớ: lỗi tái hiện được ngay thì dùng in tạm hoặc điểm dừng trong trình gỡ lỗi; lỗi không tái hiện được trên máy mình thì phải có nhật ký thật. Khi nhờ AI thêm nhật ký, nói rõ bạn cần loại nào. Nếu không nói, nhiều trợ lý sẽ rải lệnh in khắp hàm, rất tiện lúc gỡ nhưng lại thêm việc dọn dẹp sau đó.
Bốn mức nhật ký và nên ghi gì ở mỗi mức
Hầu hết thư viện nhật ký có các mức tương tự nhau. Chọn đúng mức giúp bạn bật chi tiết khi gỡ lỗi và tắt bớt khi chạy bình thường mà không phải sửa mã.
| Mức | Dùng khi | Ví dụ giả định |
|---|---|---|
| DEBUG | Chi tiết phục vụ gỡ lỗi, thường tắt trên máy chủ thật | Giá trị từng tham số khi vào hàm tính phí vận chuyển |
| INFO | Sự kiện bình thường đáng ghi lại | Đã nhận đơn mới, đã gửi thư xác nhận |
| WARNING | Có điều bất thường nhưng chương trình vẫn chạy tiếp | Dịch vụ tính phí trả chậm hơn năm giây, đã dùng phí mặc định |
| ERROR | Một việc đã hỏng, cần người xem | Không ghi được đơn vào cơ sở dữ liệu sau ba lần thử |
Khi gỡ lỗi, bạn bật mức DEBUG cho đúng mô-đun nghi ngờ thay vì cả ứng dụng. Mô-đun logging của Python cho phép đặt mức riêng cho từng logger theo tên, nên chỉ phần đang điều tra nói nhiều, phần khác vẫn yên.
Một thói quen tốt khi viết dòng ghi ở Python là truyền giá trị làm tham số thay vì ghép sẵn chuỗi, ví dụ logger.debug('phi=%s don=%s', phi, ma_don). Khi mức DEBUG đang tắt, chuỗi sẽ không phải dựng, đỡ tốn công ở những hàm chạy nhiều lần.
Ghi ở đâu: năm điểm đáng đặt nhật ký
Ranh giới với bên ngoài. Ngay trước và sau khi gọi dịch vụ ngoài, đọc cơ sở dữ liệu, đọc tệp. Phần lớn lỗi khó nằm ở chỗ dữ liệu đi vào hoặc đi ra khỏi chương trình của bạn.
Nhánh rẽ quan trọng. Chỗ mã chọn đi đường này hay đường kia: khách mới hay khách cũ, có mã giảm giá hay không. Ghi lại nhánh đã chọn và lý do, bạn sẽ biết ngay vì sao kết quả khác mong đợi.
Chỗ bắt lỗi. Mọi khối bắt ngoại lệ nên ghi lại ngoại lệ kèm ngăn xếp lời gọi. Khối bắt lỗi rỗng, nuốt lỗi im lặng, là nguyên nhân hàng đầu của những màn hình trắng không ai giải thích được.
Đầu và cuối một tác vụ dài. Tác vụ chạy nền, tác vụ hẹn giờ, nhập tệp lớn. Ghi lúc bắt đầu, lúc kết thúc, số bản ghi đã xử lý, thời gian chạy. Tác vụ chết giữa chừng sẽ để lại dòng bắt đầu mà thiếu dòng kết thúc.
Giá trị trước khi tính toán quan trọng. Trước khi tính tiền, chia tỉ lệ, chuyển đổi ngày giờ. Lỗi tính sai thường do đầu vào sai, mà đầu vào chỉ nhìn thấy được nếu bạn ghi nó lại.
Câu lệnh mẫu để AI đề xuất và viết dòng ghi nhật ký
Dán hàm hoặc đoạn mã nghi ngờ, mô tả triệu chứng, rồi dùng một trong các câu dưới. Nhớ nói rõ thư viện nhật ký dự án đang dùng để AI không tự chế ra một cách khác.
- “Dự án dùng mô-đun logging chuẩn của Python với logger đặt theo tên mô-đun. Đề xuất tối đa năm điểm ghi nhật ký mức DEBUG trong hàm dưới để tìm vì sao tổng tiền bị lệch. Mỗi điểm nói ghi giá trị nào và để kiểm giả thuyết gì.”
- “Thêm nhật ký vào hàm này nhưng không đổi logic. Trả về phần thay đổi dạng diff để dễ xem lại.”
- “Rà các khối bắt lỗi trong tệp này, chỉ ra khối nào đang nuốt lỗi mà không ghi lại, đề xuất dòng ghi phù hợp.”
- “Trong các dòng ghi dưới đây, dòng nào có thể làm lộ mật khẩu, khoá, số thẻ hoặc thông tin cá nhân. Đề xuất cách ghi an toàn hơn.”
- “Đề xuất cách gắn một mã định danh cho mỗi yêu cầu web để mọi dòng nhật ký của cùng yêu cầu nối được với nhau, phù hợp với khung làm việc dự án đang dùng.”
Câu thứ hai đáng dùng thường xuyên: yêu cầu AI không đổi logic và trả về diff giúp bạn chắc rằng nó chỉ thêm dòng ghi, không lén sửa thêm chỗ khác. Với tác tử có quyền sửa tệp, đây là ràng buộc nên ghi ngay đầu yêu cầu.
Mã định danh yêu cầu: sợi chỉ nối nhật ký rời rạc
Trên máy chủ có nhiều người dùng cùng lúc, nhật ký của mười yêu cầu đan xen nhau. Dòng thứ nhất của khách A, dòng thứ hai của khách B, dòng thứ ba lại của khách A. Đọc như vậy không thể lần ra đường đi của một yêu cầu bị lỗi. Cách giải quen thuộc là sinh một mã ngẫu nhiên ngắn cho mỗi yêu cầu ngay khi nó vào, và gắn mã đó vào mọi dòng nhật ký của yêu cầu ấy.
Nhiều khung làm việc và máy chủ web đã có sẵn cơ chế này, hoặc có thư viện phụ trợ. Khi hỏi AI, nói rõ khung làm việc và phiên bản bạn dùng, rồi đối chiếu đề xuất với tài liệu chính thức vì đây là chỗ AI dễ nhớ nhầm tên cấu hình giữa các bản. Nếu khách báo lỗi qua giao diện, hiển thị mã này trên trang lỗi để khách gửi lại, bạn tìm được đúng chuỗi nhật ký trong vài giây.
Với hệ thống gồm nhiều dịch vụ gọi nhau, mã định danh nên được truyền theo trong tiêu đề của các lời gọi nội bộ. Đây là nền tảng của việc theo dõi phân tán. Với nhóm nhỏ chưa cần công cụ chuyên dụng, chỉ riêng việc truyền một mã chung qua các dịch vụ đã giúp gỡ lỗi nhẹ đi rõ rệt.
Đọc nhật ký dài cùng AI mà không lộ dữ liệu
Nhật ký trên máy chủ có thể dài hàng chục nghìn dòng, vượt quá sức đọc của cả người lẫn khung chat. Quy trình dưới giúp bạn lọc trước, che dữ liệu, rồi mới nhờ AI tìm quy luật.
- Khoanh thời gian: chỉ lấy nhật ký trong khoảng vài phút quanh lúc lỗi xảy ra.
- Khoanh theo mã định danh yêu cầu nếu có, hoặc lọc bằng grep theo tên mô-đun và mức ERROR, WARNING.
- Che dữ liệu: thay địa chỉ thư, số điện thoại, mã khách, khoá, chuỗi kết nối bằng ký hiệu. Nhờ AI viết một đoạn mã nhỏ chạy trên máy bạn để che tự động theo mẫu là cách an toàn hơn dán nguyên nhật ký cho nó che.
- Đếm trước khi đọc: đếm số lần mỗi loại lỗi xuất hiện, lỗi nào bắt đầu từ lúc nào. Một bảng đếm nhỏ thường nói nhiều hơn nghìn dòng thô.
- Đưa cho AI đoạn đã lọc và đã che, kèm câu hỏi cụ thể: những yêu cầu lỗi có điểm gì chung mà yêu cầu thành công không có.
- Kiểm lại kết luận của AI trên nhật ký gốc, vì đoạn lọc có thể đã bỏ sót ngữ cảnh.
Đừng dán nhật ký thật chưa che lên công cụ AI dùng tài khoản cá nhân, kể cả khi đang gấp. Nhật ký máy chủ thường chứa nhiều dữ liệu khách hơn bạn tưởng, vì các dòng ghi do nhiều người viết qua nhiều năm.
Dọn nhật ký sau khi gỡ xong
Gỡ xong lỗi là lúc dễ quên nhất. Các lệnh in tạm phải xoá trước khi commit; một cách chắc ăn là đánh dấu chúng bằng một chú thích cố định như GO_LOI_TAM, rồi tìm toàn dự án theo chú thích đó trước khi gộp mã. Nhiều nhóm còn cấu hình công cụ kiểm tra mã để báo lỗi khi thấy lệnh in tạm trong mã nguồn chính.
Với nhật ký thật vừa thêm, cân nhắc giữ lại những dòng có giá trị lâu dài, hạ mức những dòng chỉ cần khi gỡ lỗi xuống DEBUG. Lần sau lỗi tương tự quay lại, bạn chỉ cần bật mức chi tiết là có ngay dữ liệu. Nhờ AI rà lại phần thay đổi với câu hỏi: dòng nào nên giữ, dòng nào nên hạ mức, dòng nào nên xoá, là một bước dọn dẹp mất vài phút.
Cuối cùng, kiểm kích thước và thời hạn lưu nhật ký. Nhật ký mức DEBUG để quên bật trên máy chủ có thể làm đầy ổ đĩa trong vài ngày, gây ra chính một lỗi mới. Đặt chế độ xoay vòng tệp nhật ký và thời hạn lưu là việc của người vận hành, nhưng người viết mã nên biết để không vô tình tạo thêm việc cho họ.
Câu hỏi thường gặp
Nên dùng print hay logging khi gỡ lỗi Python?
Dùng print cho thử nhanh trên máy mình rồi xoá ngay. Dùng mô-đun logging cho mọi thứ sẽ ở lại trong mã hoặc chạy trên máy chủ, vì nó có mức độ, thời gian, nơi lưu và bật tắt được mà không cần sửa mã.
Nhờ AI thêm nhật ký có làm thay đổi logic chương trình không?
Có thể, nếu không dặn trước. Yêu cầu rõ là chỉ thêm dòng ghi, không đổi logic, và trả về phần thay đổi dạng diff. Đọc lại diff trước khi chấp nhận, đặc biệt ở những chỗ AI chèn dòng ghi vào giữa biểu thức.
Ghi quá nhiều nhật ký có làm chậm ứng dụng không?
Có, nhất là khi ghi ở vòng lặp chạy hàng nghìn lần, ghi đồng bộ ra đĩa hoặc dựng chuỗi lớn dù mức đang tắt. Ghi có chọn lọc, dùng mức độ đúng và truyền tham số thay vì ghép chuỗi sẵn là đủ cho phần lớn ứng dụng nhỏ.
Không được ghi những gì vào nhật ký?
Không ghi mật khẩu, khoá, mã phiên đăng nhập, số thẻ, số căn cước và thông tin sức khoẻ. Với thông tin cá nhân khác như địa chỉ thư, chỉ ghi khi thật cần và nên che một phần. Nhật ký thường được lưu lâu và nhiều người đọc được hơn cơ sở dữ liệu.
Có nên dán nhật ký máy chủ vào chatbot để tìm lỗi không?
Chỉ sau khi đã lọc và che dữ liệu, và chỉ trên công cụ mà quy định của công ty cho phép. Lọc theo thời gian, theo mã yêu cầu, đếm loại lỗi trước, rồi mới đưa cho AI một đoạn ngắn kèm câu hỏi cụ thể.
Mã định danh yêu cầu có cần thiết cho dự án nhỏ không?
Rất đáng làm ngay cả với dự án nhỏ có nhiều người dùng cùng lúc. Chi phí thêm vào thấp, còn lợi ích là lần ra được đường đi của một yêu cầu lỗi giữa hàng nghìn dòng đan xen chỉ trong vài giây.