Cách Giám Sát Log Và Tài Nguyên NodeJS Docker Trên VPS Hiệu Quả

docker ps
docker logs -f <container_name>

docker logs --tail 100 <container_name>

docker logs -t <container_name>

Đây là cách đủ tốt cho debug nhanh sau deploy.

Log gì nên có trong app NodeJS?

Một app production tối thiểu nên log các nhóm sau:

– App startup → app chạy cổng nào, env nào.
– HTTP access log → method, URL, status, thời gian xử lý.
– Error log → stack trace, context.
– System event → DB connect/disconnect, job fail, external API timeout.

Ví dụ các log hữu ích:

– Server started on port 3000
– GET /api/orders 200 32ms
– Mongo connection failed
– Unhandled error: ...

Điểm quan trọng: log phải có cấu trúc, không nên console.log bừa bãi. Thực tế nên dùng:
– pino
– winston
– hoặc ít nhất format JSON/log rõ ràng

Log cấu trúc → dễ grep, dễ đẩy sang hệ thống tập trung sau này.

Quản lý kích thước log Docker

Một lỗi phổ biến: container chạy lâu ngày, log file Docker tăng liên tục → đầy ổ đĩa VPS.

Kiểm tra dung lượng:

docker system df
du -sh /var/lib/docker/containers/*

Giải pháp: cấu hình log rotation cho Docker.

Ví dụ trong docker-compose.yml:

services:
  app:
    image: my-node-app
    container_name: node_app
    restart: always
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Kết quả:
– mỗi file log tối đa 10m
– giữ 3 file
– vượt ngưỡng → Docker tự xoay vòng

Rất nên bật ngay từ đầu.

Giám sát CPU, RAM, network của container

Dùng docker stats

Lệnh đơn giản nhất:

docker stats

Bạn sẽ thấy:
– CPU %
– Memory usage
– Network I/O
– Block I/O
– PIDs

Ý nghĩa thực tế:

– CPU cao liên tục → loop nặng, query chậm, traffic tăng, job nền lỗi.
– RAM tăng dần không giảm → nghi memory leak, cache không kiểm soát, giữ object quá lâu.
– Network tăng đột biến → traffic thật, bot scan, hoặc app gọi external service quá nhiều.
– PIDs tăng bất thường → tiến trình con bị sinh quá mức.

Nếu chỉ xem một container:

docker stats <container_name>

Dấu hiệu NodeJS có vấn đề tài nguyên

Các pattern hay gặp:

– RAM tăng từ từ theo thời gian → memory leak.
– CPU spike mỗi vài phút → cron/job xử lý nặng.
– CPU cao + response chậm → code sync/blocking event loop.
– RAM chạm ngưỡng VPS → hệ điều hành dùng swap → app chậm toàn hệ thống.

NodeJS rất nhạy với RAM trên VPS nhỏ. Nếu container không giới hạn, nó có thể ăn hết tài nguyên máy.

Giới hạn tài nguyên container

Trong docker-compose.yml, nên đặt ngưỡng hợp lý:

services:
  app:
    image: my-node-app
    container_name: node_app
    restart: always
    mem_limit: 512m
    cpus: "0.50"

Kết quả:
– app không chiếm toàn bộ RAM VPS
– tránh 1 container kéo sập cả máy

Lưu ý: giới hạn quá chặt → app bị kill hoặc chậm. Cần đo thật bằng docker stats rồi chỉnh dần.

Theo dõi tài nguyên VPS: đừng chỉ nhìn container

Container ổn chưa chắc VPS ổn. Bạn cần xem cả máy chủ.

Các lệnh cơ bản nên dùng

htop
free -h
df -h
uptime

Ý nghĩa:

– htop → xem process nào ăn CPU/RAM
– free -h → RAM/swap còn bao nhiêu
– df -h → ổ đĩa còn trống không
– uptime → load average toàn hệ thống

Cần chú ý gì?

– Disk gần đầy → log Docker, file upload, backup cũ.
– Swap bị dùng nhiều → RAM thiếu, app sẽ chậm rõ rệt.
– Load average cao kéo dài → CPU quá tải hoặc I/O nghẽn.
– Nhiều process lạ → cần kiểm tra bảo mật hoặc job ngoài dự kiến.

Một kịch bản rất hay gặp:
– app chạy tốt,
– log không rotate,
– vài ngày sau disk 100%,
– Docker lỗi ghi log,
– app bắt đầu restart.

Giám sát disk → tránh lỗi kiểu này.

Cảnh báo cơ bản: không cần quá phức tạp

Nếu hệ thống nhỏ, chưa cần Prometheus/Grafana ngay. Bạn vẫn nên có cảnh báo tối thiểu.

Mức tối thiểu nên có

– RAM vượt 80%
– Disk vượt 80%
– container restart
– app trả nhiều lỗi 5xx
– VPS không phản hồi

Công cụ đơn giản

– Uptime Kuma → theo dõi uptime, HTTP status, ping.
– Netdata → giám sát realtime CPU/RAM/disk/network rất dễ triển khai.
– pm2 monit → hữu ích nếu không chạy hoàn toàn qua Docker, nhưng với Docker thì ưu tiên giám sát container/VPS.

Ví dụ chạy Netdata bằng Docker:

docker run -d --name=netdata 
  -p 19999:19999 
  --cap-add SYS_PTRACE 
  --security-opt apparmor=unconfined 
  netdata/netdata

Truy cập:

http://<VPS-IP>:19999

Netdata → cho bạn dashboard gần như tức thì, rất hợp để phát hiện spike tài nguyên.

Quy trình kiểm tra nhanh sau mỗi lần deploy

Một checklist ngắn nhưng cực hữu ích:

1. Kiểm tra container có lên không

docker ps

2. Xem log startup

docker logs --tail 100 <container_name>

3. Test endpoint chính

curl http://localhost:3000/health

4. Theo dõi tài nguyên 5–10 phút đầu

docker stats

5. Kiểm tra RAM, disk VPS

free -h
   df -h

6. Xác nhận log rotation đã bật
→ tránh đầy disk sau vài ngày.

Quy trình này chỉ mất vài phút nhưng giúp phát hiện đa số lỗi sớm.

Khi phát hiện bất thường, xử lý theo thứ tự nào?

Đừng sửa ngẫu hứng. Hãy đi theo thứ tự:

1. App có đang sống không?

– container running?
– health endpoint còn trả về?
– log có lỗi mới không?

2. Lỗi thuộc app hay VPS?

– app crash → xem exception
– VPS đầy RAM/disk → xử lý hạ tầng trước

3. Tài nguyên nào đang là nút thắt?

– CPU?
– RAM?
– disk?
– network?

4. Lỗi có lặp lại không?

– sau mỗi deploy?
– theo khung giờ?
– khi traffic tăng?

Cách tiếp cận này giúp bạn tránh “restart cho đỡ” nhưng không giải quyết gốc rễ.

Kết luận

Deploy NodeJS bằng Docker lên VPS là bước đầu. Muốn hệ thống chạy ổn định lâu dài, bạn cần coi giám sát log và tài nguyên là một phần bắt buộc của vận hành.

Tối thiểu, hãy làm 4 việc:
– xem log container thường xuyên
– bật log rotation
– theo dõi CPU/RAM/disk bằng docker stats, htop, df -h
– thiết lập cảnh báo uptime/tài nguyên cơ bản

Khi có thói quen này, bạn sẽ phát hiện lỗi trước khi người dùng báo, tối ưu VPS tốt hơn, và biết chính xác lúc nào cần nâng cấu hình, sửa code, hoặc scale hệ thống.

Nếu hệ thống của bạn đang nhỏ, đừng chờ đến khi có Prometheus/Grafana mới bắt đầu. Chỉ cần docker logs, docker stats, htop, và một dashboard như Netdata/Uptime Kuma, bạn đã có nền tảng giám sát đủ thực tế để vận hành NodeJS trên VPS an toàn hơn rất nhiều.