Thiết lập Monitoring Next.js trên VPS để Bắt Lỗi Sớm

// app/api/health/route.ts
export async function GET() {
  return Response.json({
    status: "ok",
    timestamp: new Date().toISOString(),
  });
}

export async function GET() {
  try {
    // await db.user.findFirst()
    return Response.json({ status: "ok" });
  } catch {
    return Response.json({ status: "error" }, { status: 500 });
  }
}

npm install -g pm2

Chạy app:

pm2 start npm --name "next-app" -- start
pm2 save
pm2 startup

Xem trạng thái:

pm2 status
pm2 logs next-app
pm2 monit

Cấu hình ecosystem:

// ecosystem.config.js
module.exports = {
  apps: [
    {
      name: "next-app",
      script: "npm",
      args: "start",
      instances: 1,
      exec_mode: "fork",
      max_memory_restart: "500M",
      env: {
        NODE_ENV: "production",
        PORT: 3000,
      },
    },
  ],
};

Chạy:

pm2 start ecosystem.config.js
pm2 save

Điểm quan trọng:

– max_memory_restart → tránh app ăn RAM đến chết VPS.
– pm2 startup → reboot xong app tự chạy.
– pm2 logs → debug lỗi runtime.
– pm2 monit → xem CPU/RAM per process.

Nếu app dùng nhiều CPU, cân nhắc instances: "max" + exec_mode: "cluster". Nhưng SSR có state nội bộ → kiểm tra kỹ trước.

Theo dõi tài nguyên VPS

App Next.js có thể lỗi vì server hết tài nguyên. Cần theo dõi:

– CPU usage
– RAM usage
– Disk usage
– Disk I/O
– Network
– Load average
– Swap
– Open files
– Nginx status
– Docker container nếu có

Lệnh nhanh:

htop
free -m
df -h
du -sh /var/log/*
journalctl -xe

Cài Netdata → nhanh, trực quan:

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Sau đó truy cập:

http://your-server-ip:19999

Netdata mạnh vì có alert sẵn: CPU cao, RAM thấp, disk gần đầy, load bất thường. Với VPS public, nên chặn port bằng firewall hoặc reverse proxy + auth.

Ví dụ UFW:

ufw allow OpenSSH
ufw allow 80
ufw allow 443
ufw deny 19999
ufw enable

Log: nguồn dữ liệu quan trọng nhất

Không có log → chỉ đoán. Với Next.js production, cần log:

– Request lỗi
– API exception
– Auth failure
– Payment/webhook failure
– DB timeout
– SSR/render error
– Background job error
– Deploy event

Log nên có cấu trúc JSON:

console.error(JSON.stringify({
  level: "error",
  message: "Checkout failed",
  userId,
  orderId,
  error: err instanceof Error ? err.message : String(err),
  stack: err instanceof Error ? err.stack : undefined,
  timestamp: new Date().toISOString(),
}));

Tránh log:

– Password
– Token
– Cookie
– API key
– Full credit card
– Private user data

PM2 log nằm thường tại:

~/.pm2/logs/

Kiểm tra dung lượng log. Log phình to → đầy disk → app chết.

Cài logrotate cho PM2:

pm2 install pm2-logrotate
pm2 set pm2-logrotate:max_size 10M
pm2 set pm2-logrotate:retain 14
pm2 set pm2-logrotate:compress true

Nếu dùng Nginx, theo dõi:

/var/log/nginx/access.log
/var/log/nginx/error.log

Lỗi 502/504 thường do:

– Next.js process chết
– Upstream port sai
– App timeout
– RAM hết
– Deploy làm app ngắt
– Nginx timeout thấp

Error tracking với Sentry

Uptime biết app chết. Log biết server ghi gì. Sentry biết user gặp lỗi nào, ở route nào, browser nào, stack trace nào.

Cài Sentry cho Next.js:

npm install @sentry/nextjs
npx @sentry/wizard@latest -i nextjs

Sentry giúp bắt:

– Client-side exception
– Server-side exception
– API route error
– Performance issue
– Release/version lỗi
– Source map stack trace

Nên cấu hình environment:

SENTRY_DSN=...
SENTRY_ENVIRONMENT=production

Khi capture thủ công:

import * as Sentry from "@sentry/nextjs";

try {
  // logic
} catch (err) {
  Sentry.captureException(err);
  throw err;
}

Best practice:

– Gắn release theo commit SHA.
– Tách production, staging.
– Bật alert khi error rate tăng.
– Ignore lỗi noise như bot, extension browser.
– Không gửi PII nếu không cần.

Sentry đặc biệt hữu ích với Next.js vì lỗi hydration, lỗi client JS, lỗi SSR đôi khi không hiện rõ trong log server.

Uptime monitoring bằng Uptime Kuma

Uptime Kuma phù hợp VPS nhỏ: self-host, UI đẹp, alert Telegram/Slack/Email.

Chạy bằng Docker:

docker run -d 
  --restart=always 
  -p 3001:3001 
  -v uptime-kuma:/app/data 
  --name uptime-kuma 
  louislam/uptime-kuma:1

Truy cập:

http://your-server-ip:3001

Nên monitor:

– https://domain.com
– https://domain.com/api/health
– https://domain.com/login
– SSL certificate
– Internal service nếu có: Redis, DB proxy, queue dashboard

Alert nên gửi Telegram. Nhanh, rẻ, thực tế.

Cấu hình interval:

– Trang chủ: 1 phút
– API health: 1 phút
– SSL: 12 giờ
– Job phụ: 5 phút

Không nên check quá dày vào endpoint nặng. Monitoring cũng là traffic.

Reverse proxy Nginx: thêm log và timeout hợp lý

Cấu hình cơ bản:

server {
    server_name domain.com;

location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

proxy_connect_timeout 10s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

Nếu thấy nhiều 504 → API/SSR chậm. Đừng chỉ tăng timeout. Cần tìm route chậm.

Xem lỗi Nginx:

tail -f /var/log/nginx/error.log

Top status code:

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Top IP:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Nếu bot spam → CPU tăng, log phình, app chậm. Cần rate limit, cache, WAF nhẹ.

Metrics ứng dụng: đừng chỉ nhìn server

Server CPU thấp không có nghĩa app ổn. Cần app metrics:

– Request duration
– Error rate
– Route latency
– DB query duration
– Cache hit rate
– Queue length
– Job failure count
– Active users
– Login failure spike

Có thể dùng Prometheus + Grafana, nhưng setup nặng hơn. Với team nhỏ, bắt đầu bằng:

– Sentry Performance
– Nginx access log analysis
– Uptime Kuma response time
– DB slow query log
– PM2 metrics

Nếu cần Prometheus, expose /api/metrics, dùng prom-client. Nhưng bảo vệ endpoint bằng IP allowlist hoặc auth. Metrics lộ ra public → rủi ro bảo mật.

Alert: ít nhưng đúng

Alert quá nhiều → bị bỏ qua. Alert quá ít → phát hiện muộn.

Nên có alert:

– Website down > 1 phút
– Health check 500
– SSL hết hạn 80%
– RAM usage > 90%
– CPU > 90% trong 5 phút
– PM2 restart liên tục
– Error rate tăng đột biến
– Response time > 2s liên tục
– DB connection fail

Kênh alert:

– Telegram: sự cố khẩn
– Email: báo cáo
– Slack/Discord: team
– Phone/SMS: hệ thống quan trọng

Mỗi alert nên có runbook ngắn:

– Lỗi gì?
– Xem log ở đâu?
– Restart thế nào?
– Rollback thế nào?
– Ai phụ trách?

Ví dụ runbook:

Alert: Next.js health check 500
1. ssh user@server
2. pm2 status
3. pm2 logs next-app --lines 100
4. tail -f /var/log/nginx/error.log
5. df -h
6. free -m
7. rollback nếu lỗi sau deploy

Deploy cũng cần monitoring

Nhiều lỗi xuất hiện ngay sau deploy. Cần ghi nhận deploy event.

Sau deploy:

pm2 restart next-app
pm2 status
curl -I https://domain.com
curl https://domain.com/api/health

Checklist:

– Build thành công
– App restart thành công
– Health check OK
– Không tăng 500
– Không tăng memory bất thường
– Sentry không báo lỗi mới
– Nginx không 502

Nếu dùng Sentry, gắn release theo commit. Khi lỗi tăng, biết ngay version nào gây lỗi.

Backup và monitoring liên quan trực tiếp

Monitoring phát hiện lỗi. Backup giúp phục hồi. Nếu DB hỏng mà không backup → alert chỉ báo tin xấu.

Cần monitor backup:

– Backup có chạy không?
– File backup có tạo không?
– Dung lượng hợp lý không?
– Restore test định kỳ chưa?
– Backup có copy ra ngoài VPS không?

VPS chết kéo theo backup local chết. Nên lưu thêm S3, Backblaze, R2, server khác.

Kết luận thực tế

Monitoring cho Next.js trên VPS không cần bắt đầu bằng hệ thống phức tạp. Bắt đầu đúng thứ tự:

1. PM2 → giữ process sống, xem log.
2. Health check → biết app thật sự ổn không.
3. Uptime Kuma → cảnh báo khi web down.
4. Netdata → thấy CPU/RAM/disk/network.
5. Sentry → biết lỗi user gặp.
6. Logrotate → tránh log làm đầy disk.
7. Runbook → xử lý nhanh khi alert đến.

Mục tiêu không phải dashboard đẹp. Mục tiêu: lỗi xảy ra → biết sớm, biết nguyên nhân, biết cách xử lý. Với Next.js chạy trên VPS, chỉ cần vài lớp monitoring đúng chỗ, bạn đã giảm mạnh thời gian downtime, giảm phụ thuộc vào báo lỗi từ user, tăng độ tin cậy cho sản phẩm.