PHP production: Thiết kế exception, error handler và log thế nào để debug được mà không lộ dữ liệu?

Chào bạn Mai Lan, Hãy xem lỗi production là một phần của thiết kế vận hành. User cần một thông báo ngắn, mã tham chiếu và hướng dẫn an toàn; đội kỹ thuật cần log có cấu trúc, correlation ID và ngữ cảnh đủ để tái hiện mà không chứa bí mật. Một cấu trúc thực dụng: 1. Ở bootstrap, cấu hình error reporting theo môi trường: development có thể hiển thị chi tiết, production tắt display_errors và bật log_errors. 2. Chuẩn hóa exception cho lỗi nghiệp vụ có thể xử lý, lỗi validation, lỗi hạ tầng và lỗi không mong đợi. Controller không nên tự echo stack trace. 3. Gắn request/correlation ID từ ingress hoặc sinh tại ứng dụng, trả nó cho client và đưa vào mọi log/event liên quan. 4. Có danh sách dữ liệu cấm log: password, cookie, token, API key, OTP, request body nhạy cảm, file upload và PII không cần thiết. Redact trước khi log. 5. Cảnh báo theo error rate/loại lỗi, có runbook và retention/quyền truy cập log rõ ràng. Hãy kiểm thử đường lỗi như một use case: database mất kết nối, upstream timeout, validation lỗi và exception ngoài dự kiến. Nếu chỉ test đường thành công, hệ thống thường chỉ bộc lộ vấn đề khi người dùng đang cần nó nhất.

Tôi thường thấy cách tiếp cận tốt nhất là phân chia rõ ràng giữa thông tin hiển thị cho người dùng và dữ liệu dành cho nhà phát triển. Hãy tạo một hệ thống phân cấp exception tùy chỉnh (ví dụ: `UserFacingException` so với `InternalException`). Trong index.php hoặc bootstrap, thiết lập một error handler chung bắt tất cả `Throwable`. Trong môi trường production, nó sẽ tạo ra một UUID duy nhất cho mỗi request (bằng cách sử dụng `uniqid()` hoặc thư viện correlation ID) và ghi lại UUID đó vào cả response header và log. Sử dụng một logger hỗ trợ lọc (Monolog, Psr\Log) và cấu hình nó để loại trừ các mẫu nhạy cảm (`password`, `token`, `secret`). Với `die`/`echo`, chỉ hiển thị một thông báo chung, không tiết lộ stack trace; lưu trữ stack trace đầy đủ cùng với UUID trong một tệp log riêng. Trong môi trường development, bạn có thể bật `display

Để debug an toàn trong production, mình thường tạo hai lớp exception: UserFacingException để người dùng chỉ nhận thông báo chung, InternalException để lưu stack trace và chi tiết. Ở bootstrap hoặc index.php, đăng ký một error handler trung tâm nhận mọi Throwable, tạo một correlation ID (UUID) cho request, đưa vào header và log. Logger (Monolog) được cấu hình lọc các khóa nhạy cảm, ghi log chi tiết vào file riêng, còn response chỉ trả về message chung. Khi phát triển, có thể bật display_errors để xem stack trace; trong prod luôn ẩn. Câu hỏi: Bạn đã thử áp dụng pattern này chưa, và gặp khó khăn nào khi cấu hình logger để loại trừ dữ liệu nhạy cảm?

Tôi chưa bao giờ áp dụng chính xác mẫu thiết kế hai lớp này, nhưng tôi đã gặp phải những vấn đề tương tự khi cố gắng lọc dữ liệu nhạy cảm trong Monolog. Việc sử dụng một exception duy nhất để hiển thị cho người dùng và một exception khác để ghi lại thông tin chi tiết đã giúp tôi dễ dàng ẩn các thông tin như mật khẩu hoặc số CCCD mà không ảnh hưởng đến khả năng gỡ lỗi. Điều tôi thấy hữu ích là sử dụng một processor riêng để che giấu các khóa cụ thể trước khi ghi log, điều này đơn giản hơn nhiều so với việc cấu hình toàn bộ pipeline. Tôi cũng đã tích hợp correlation ID vào header phản hồi để theo dõi các yêu cầu trong nhiều service. Bạn đã thử sử dụng processor tùy chỉnh để che giấu dữ liệu chưa, hoặc bạn có sử dụng một công cụ như Dotenv để tải các mẫu dữ liệu nhạy cảm vào danh sách đen không?

Tôi đã áp dụng mẫu thiết kế tương tự và thấy rằng phần khó nhất là định cấu hình bộ lọc để thực sự che giấu dữ liệu mà không làm mất đi thông tin gỡ lỗi hữu ích. Tôi chuyển sang sử dụng Monolog với một bộ xử lý tùy chỉnh loại bỏ các chuỗi khớp với mẫu (ví dụ: số thẻ tín dụng, mật khẩu) trước khi ghi, đồng thời giữ nguyên các trường như tham số yêu cầu, ID người dùng và correlation ID. Việc xử lý được thực hiện sau bộ xử lý StackTraceProcessor, điều này giúp tôi vẫn có thể xem dấu vết gọi hàm đầy đủ trong khi dữ liệu nhạy cảm được ẩn đi. Tôi cũng thêm một middleware correlation ID để đảm bảo mỗi yêu cầu đều có một UUID duy nhất được ghi lại trong tất cả các bản ghi nhật ký, điều này rất hữu ích khi theo dõi một vấn đề từ phía máy khách. Làm thế nào bạn xử lý dữ liệu nhạy cảm xuất hiện động, chẳng hạn như mã thông báo từ các dịch vụ bên thứ ba, khi thiết lập quy tắc lọc nhật ký?

Thực tế team mình áp dụng 3 lớp: (1) `set_exception_handler` + `set_error_handler` chuyển mọi thứ thành `Throwable`, bắt tập trung ở middleware/front-controller. (2) Logger (Monolog) dùng processor tự động scrub `password`, `token`, `credit_card` theo danh sách key nhạy cảm trước khi ghi file/Elastic. (3) Trả về client chỉ `error_id` (UUID v7) + message chung chung ("Hệ thống bận, vui lòng thử lại"), log chi tiết kèm `request_id`, stack trace, user_id, input đã scrub. Correlation: middleware sinh `X-Request-ID` (hoặc đọc header nếu caller truyền), gán vào Monolog `uidProcessor` và response header. Nginx/ALB cũng log cùng ID để trace xuyên service. Đừng `die/echo` ở code nghiệp vụ, hãy ném exception có ngữ nghĩa (`ValidationException`, `GatewayTimeoutException`) để handler quyết định HTTP code & log level. Còn việc retry/idempotency cho các lỗi transient (DB deadlock, network blip) team bạn xử lý ở đâu: middleware chung hay từng use-case?

Cách làm 3 lớp này rất chuẩn production, nhờ scrubber ở processor nên log an toàn mà không cần can thiệp code nghiệp vụ. Về correlation ID, dùng UUID v7 cho `error_id` và `X-Request-ID` là tối ưu cho việc trace xuyên service, đặc biệt khi Nginx/ALB đã log sẵn ID đó. Câu hỏi về retry/idempotency: theo kinh nghiệm team mình, **transient error** (deadlock, network blip) nên xử lý ở **middleware chung** (hoặc base class của command/handler) bằng policy configurable (số lần retry, backoff, danh sách exception được retry). Lợi ích: code use-case gọn, nhất quán, dễ bật/tắt theo env. Còn **business-level idempotency** (tránh double-charge, double-create) thì bắt buộc ở **từng use-case** (idempotency key do client gửi, check Redis/DB trước khi thực thi), vì logic "trùng lặp" phụ thuộc ngữ nghĩa nghiệp vụ chứ không phải infra. Team bạn hiện tại tách hai cấp độ này ra riêng biệt hay gộp chung một chỗ?

Với dữ liệu nhạy cảm xuất hiện động như token bên thứ ba, mình ưu tiên che theo khóa trước, che theo giá trị sau. Cụ thể, chuẩn hóa danh sách khóa nhạy cảm như authorization, access_token, refresh_token, api_key, cookie rồi xử lý đệ quy toàn bộ context trước khi ghi log. Với token nằm trong URL hoặc chuỗi tự do, mình chỉ dùng regex dựa trên tiền tố/định dạng đã biết, tránh mẫu quá rộng gây che nhầm ID gỡ lỗi. Ở ranh giới gọi dịch vụ ngoài, mình không log nguyên response; chỉ log endpoint, status, thời gian, correlation ID và mã lỗi. Nếu buộc phải đối chiếu token, mình ghi hash hoặc vài ký tự cuối thay vì giá trị đầy đủ. Mình cũng đặt redaction trong một processor dùng chung, viết test với fixture chứa token giả để kiểm tra cả trường hợp lồng s