Lesson 9.1: Structured Logging

Thời lượng: 20 phút
Level: Advanced
Yêu cầu: Kiến thức về File System và Linux cơ bản.

Mục tiêu bài học

Sau bài học này, bạn sẽ:

• Phân biệt được Unstructured Logging (Dạng văn bản) và Structured Logging (JSON).
• Biết cách thiết kế các bộ trường (Fields) cần thiết trong một dòng log.
• Hiểu quy trình đẩy log lên các hệ thống quản lý tập trung (ELK, Datadog, Loki).

Nội dung chính

1. Tại sao phải dùng Structured Logging?

Trong quá khứ, chúng ta thường log dưới dạng một câu văn: [2024-01-01] ERROR: User 123 failed to login from IP 1.2.3.4

Khi bạn có hàng tỷ dòng log, việc tìm xem "liệt kê tất cả các lỗi của User 123" bằng cách dùng Regex search là cực kỳ chậm và không chính xác.

Structured Logging (JSON): Mọi dòng log là một đối tượng JSON.

{
  "timestamp": "2024-01-01T10:00:00Z",
  "level": "ERROR",
  "event": "login_failed",
  "user_id": 123,
  "ip": "1.2.3.4",
  "service": "auth-service",
  "trace_id": "abc-123"
}

Giờ đây, máy tính (Elasticsearch) có thể index trường user_id và trả về kết quả ngay lập tức trong 1 giây.

2. Các trường cần có trong một dòng log chuẩn

Design System quy định mọi service phải log các trường sau:

• timestamp: Định dạng ISO 8601.
• level: INFO, WARN, ERROR, DEBUG.
• service_name: Tên service phát sinh log.
• trace_id: ID theo vết yêu cầu (vô cùng quan trọng).
• message: Mô tả ngắn gọn về sự kiện.
• context: Chứa các metadata liên quan (user_id, order_id...).

3. Centralized Logging (Quản lý tập trung)

Đừng bao giờ để log nằm rải rác ở từng file trên từng server.

1. Collector: Một chương trình nhỏ (Fluentbit/Logstash) đọc log từ app.
2. Buffer: Chuyển log vào một hàng đợi (Kafka) để tránh mất dữ liệu khi tải cao.
3. Storage: Lưu vào Database chuyên dụng (Elasticsearch).
4. Visualization: Xem và tìm kiếm qua giao diện (Kibana/Grafana).

Nguyên tắc then chốt

"Log as if you will need to debug a production issue at 3 AM."

Log quá ít sẽ khiến bạn mù mờ khi có sự cố. Log quá nhiều sẽ làm tốn tiền lưu trữ và làm chậm hệ thống (I/O). Hãy cân nhắc kỹ: cái gì thực sự giúp bạn tìm ra lỗi?

Thực hành

Bài tập 1: Thiết kế Log cho hành động "Hủy đơn hàng"

Bối cảnh: Admin hủy đơn hàng của User vì lý do "Hết hàng".

Yêu cầu:

• Hãy viết một dòng JSON log chứa đầy đủ các thông tin cần thiết để sau này user thắc mắc, bạn có thể giải trình được.

{
  "timestamp": "2024-01-15T14:30:00Z",
  "level": "INFO",
  "service": "order-service",
  "event": "order_cancelled",
  "trace_id": "req-999",
  "context": {
    "order_id": "ORD-555",
    "cancelled_by": "admin-01",
    "reason": "out_of_stock",
    "user_id": "client-88"
  }
}

Tình huống thực tế

Scenario 1: Log chứa mật khẩu

Bối cảnh: Developer vô tình log toàn bộ request_body khi user đăng ký, dẫn đến mật khẩu dưới dạng bản rõ (plain text) bị lưu vào hệ thống Logging (Kibana) mà mọi nhân viên IT đều có thể xem được.

Giải quyết: Đây là rò rỉ bảo mật nghiêm trọng.

1. Redaction: Sử dụng Middleware logging có khả năng tự động ẩn (masking) các trường nhạy cảm như password, token, credit_card.
2. Policy: Quy định không bao giờ log raw objects từ Client. Chỉ log các field đã được chọn lọc.

Câu hỏi phỏng vấn

Senior Level

1. Q: Phân biệt "Logging" và "Auditing"? A:
   • Logging: Dành cho lập trình viên để vận hành và debug kỹ thuật. Có thể xóa sau 30 ngày để tiết kiệm chỗ.
   • Auditing: Dành cho nghiệp vụ và pháp lý (VD: AI là người sửa giá sản phẩm?). Phải được lưu trữ an toàn, không thể sửa xóa (Immutable) và lưu trong thời gian dài (nhiều năm).

Tóm tắt

Những điều cần nhớ

• Dùng JSON format cho log.
• Luôn kèm theo Trace ID.
• Quản lý log tập trung (Centralized).
• Bảo mật: Không bao giờ log dữ liệu nhạy cảm.

Bước tiếp theo

Trong bài tiếp theo, bạn sẽ học về Lesson 9.2: Distributed Tracing - Phép màu giúp bạn theo vết một request đi qua 10 service khác nhau chỉ trong chớp mắt.

Tiếp tục bài 9.2 →