AdvancedIncident Response & SRE⏱️ 14 min

Production Server Troubleshooting & Incident Runbook

ဆာဗာ ကျသွားပါက စစ်ဆေးပြင်ဆင်ရမည့် Incident Response Runbook

The definitive production guide for diagnosing 502 Bad Gateway, 504 Gateway Timeout, Linux Kernel OOM Killer crashes, 100% full disks, and automated logrotate.

ဝဘ်ဆိုက် ရပ်တန့်သွားပါက အဆင့် ၆ ဆင့်ဖြင့် အမြန်ဆုံး အမှားရှာဖွေနည်း၊ 502/504/521 အမှားများ ပြင်ဆင်နည်း၊ Linux Swap Memory ထည့်သွင်းခြင်းနှင့် Disk မပြည့်စေရန် Logrotate သုံးနည်း။

📑Table of Contents (မာတိကာ)

1.1. The 6-Step "Site Down" Incident Hierarchy (အဆင့် ၆ ဆင့် စစ်ဆေးနည်းစနစ်)
2.2. Decoding 502, 504 & Cloudflare 521 (HTTP Status Codes ခွဲခြားခြင်း)
3.3. Linux OOM Killer & Virtual Swap Memory (RAM ပြည့်၍ Crash ဖြစ်ခြင်း ကာကွယ်နည်း)
4.4. Preventing Disk 100% Full with Logrotate & Docker Caps
★Knowledge Check (မိမိကိုယ်ကို စစ်ဆေးခြင်း Quiz)

1. The 6-Step "Site Down" Incident Hierarchy (အဆင့် ၆ ဆင့် စစ်ဆေးနည်းစနစ်)

အချိန်ကုန် သက်သာစွာ အမှား၏ မူလဇစ်မြစ်ကို ချက်ချင်း ရှာဖွေခြင်း

ဝဘ်ဆိုက် ရုတ်တရက် ဖွင့်မရတော့ပါက developer အများစုသည် မည်သည့်နေရာမှ စတင်စစ်ဆေးရမှန်း မသိဘဲ Nginx သို့မဟုတ် Server ကို အလောတကြီး restart ချတတ်ကြပါသည်။ ထိုသို့ ပြုလုပ်ခြင်းသည် log ဖိုင်များကို ပျောက်ဆုံးစေပြီး ပြဿနာကို မဖြေရှင်းနိုင်ပါ။

အတွေ့အကြုံရှိ DevOps အင်ဂျင်နီယာများသည် အောက်ပါ အဆင့် ၆ ဆင့်အတိုင်း အစဉ်လိုက် စစ်ဆေးကြပါသည်: ၁။ Server Reachability: ဆာဗာ စက်ကိုယ်တိုင် အင်တာနက်မိမမိ (ping & ssh) ၂။ Storage Fullness: Hard disk 100% ပြည့်နေမနေ (df -h) ၃။ Memory Exhaustion: RAM ပြည့်ပြီး Linux OOM Killer က app ကို သတ်ပစ်ထားခြင်း ရှိမရှိ (free -h & dmesg) ၄။ Web Server Syntax & Health: Nginx အလုပ်လုပ်နေမနေ (sudo nginx -t && systemctl status nginx) ၅။ Backend App State: Node.js (PM2), Python (Systemd), Docker container အလုပ်လုပ်နေမနေ (pm2 status / docker ps) ၆။ Port Listening: သက်ဆိုင်ရာ Port 3000/8000 ကို app က နားထောင်နေဆဲ ဟုတ်မဟုတ် (sudo ss -tulpn)


        
          1
          $
        
        # 1. Check Disk
      

        
          2
          $
        
        df -h | grep -E '^/dev/'
      

        
          3
          $
        
        
      

        
          4
          $
        
        # 2. Check RAM & Swap
      

        
          5
          $
        
        free -h
      

        
          6
          $
        
        
      

        
          7
          $
        
        # 3. Check Kernel OOM Killer events
      

        
          8
          $
        
        sudo dmesg -T | grep -E -i "killed process|out of memory" | tail -n 5
      

        
          9
          $
        
        
      

        
          10
          $
        
        # 4. Check Nginx syntax & status
      

        
          11
          $
        
        sudo nginx -t && sudo systemctl status nginx --no-pager
      

        
          12
          $
        
        
      

        
          13
          $
        
        # 5. Check backend app ports
      

        
          14
          $
        
        sudo ss -tulpn | grep -E ':(80|443|3000|8000|5432|3306)'

💡Command ရှင်းလင်းချက် (ဖတ်ရှုရန် နှိပ်ပါ)

ဤ command ၅ ခုကို terminal တွင် run လိုက်ရုံဖြင့် ဆာဗာ၏ Disk, RAM, Nginx နှင့် Backend အခြေအနေကို စက္ကန့် ၆၀ အတွင်း အတိအကျ သိရှိနိုင်ပါသည်။

2. Decoding 502, 504 & Cloudflare 521 (HTTP Status Codes ခွဲခြားခြင်း)

အသုံးအများဆုံး Server Error ၃ မျိုးနှင့် ဖြေရှင်းပုံ

• 502 Bad Gateway: Nginx (Reverse Proxy) က ရှင်သန်နေသော်လည်း ၎င်းချိတ်ဆက်ထားသော နောက်ကွယ်ရှိ Node/Python app (Port 3000) ပိတ်နေခြင်း သို့မဟုတ် uncaught exception ကြောင့် crash ဖြစ်သွားခြင်း ဖြစ်ပါသည်။ Nginx config ရှိ `proxy_pass http://127.0.0.1:<port>;` မှန်မမှန်နှင့် app process live ဖြစ်မဖြစ် အရင် စစ်ရပါမည်။ • 504 Gateway Timeout: Backend app သည် Nginx သတ်မှတ်ထားသော timeout (default 60s) အတွင်း request ကို ပြန်မဖြေကြားနိုင်ခြင်း ဖြစ်ပါသည်။ အဓိက အကြောင်းရင်းမှာ Database Slow Query ကြီးမားခြင်း၊ Deadlock ဖြစ်ခြင်း သို့မဟုတ် Third-party API ချိတ်ဆက်မှု နှေးကွေးခြင်း ဖြစ်ပါသည်။ • 521 Web Server Is Down: Cloudflare မှ ပြသသော error ဖြစ်ပြီး သင်၏ VPS Origin Server က TCP Connection ကို ငြင်းပယ် (refuse) လိုက်ခြင်း ဖြစ်ပါသည်။ Nginx လုံးဝ ရပ်တန့်နေခြင်း သို့မဟုတ် UFW Firewall က Cloudflare IPs များကို block လုပ်ထားခြင်းကြောင့် ဖြစ်ပါသည်။


        
          1
          $
        
        # Check real-time backend crash logs
      

        
          2
          $
        
        pm2 logs --lines 100 --err
      

        
          3
          $
        
        # OR for Systemd
      

        
          4
          $
        
        sudo journalctl -u myapp -f -n 100
      

        
          5
          $
        
        
      

        
          6
          $
        
        # Test backend directly bypassing Nginx
      

        
          7
          $
        
        curl -Iv http://127.0.0.1:3000

💡Command ရှင်းလင်းချက် (ဖတ်ရှုရန် နှိပ်ပါ)

curl -Iv http://127.0.0.1:3000 ဖြင့် Nginx မပါဘဲ မိမိ၏ application ကို တိုက်ရိုက်ခေါ်ယူစစ်ဆေးနိုင်ပြီး 502 ဖြစ်ရခြင်း အကြောင်းရင်းကို အလွယ်တကူ ရှာဖွေနိုင်ပါသည်။

3. Linux OOM Killer & Virtual Swap Memory (RAM ပြည့်၍ Crash ဖြစ်ခြင်း ကာကွယ်နည်း)

Budget VPS များတွင် Swap Space မဖြစ်မနေ ထည့်သွင်းရခြင်း အကြောင်းရင်း

RAM 1GB သို့မဟုတ် 2GB သာပါသော Budget VPS များတွင် MySQL, Node.js နှင့် OS background daemons များ ပေါင်းလိုက်ပါက RAM ပြည့်သွားလေ့ရှိပါသည်။

Linux Kernel သည် Memory ပြည့်ပါက ဆာဗာ freeze မဖြစ်စေရန် အရေးကြီးသော process (ဥပမာ mysqld သို့မဟုတ် node) ကို OOM Killer ဖြင့် အတင်းအကျပ် သတ်ပစ်လေ့ရှိပါသည်။

SSD Storage ပေါ်တွင် Virtual Swap File (2GB မှ 4GB) ဖန်တီးပေးထားခြင်းဖြင့် RAM ပြည့်သွားသည့်တိုင် ယာယီ buffer အဖြစ် အသုံးပြုစေကာ crash ဖြစ်ခြင်းကို ကာကွယ်ပေးနိုင်ပါသည်။

💡

Pro-Tips & အကြံပြုချက်:

Swappiness ကို default 60 အစား 10 သို့ လျှော့ချထားပါက Linux သည် RAM ကိုသာ ဦးစားပေးသုံးပြီး SSD ပေါ်သို့ မလိုအပ်ဘဲ swap ရေးသားမှု မပြုလုပ်သဖြင့် disk lifespan ကို ကာကွယ်ပေးပါသည်။
Interactive Tools ကဏ္ဍရှိ Linux Swap Generator ဖြင့် သင့်တော်သော swap script ကို 1-click ထုတ်ယူနိုင်ပါသည်။

4. Preventing Disk 100% Full with Logrotate & Docker Caps

Log ဖိုင်များကြောင့် Disk ပြည့်ပြီး ဆာဗာရပ်တန့်မှုကို ကာကွယ်ခြင်း

ဆာဗာ စတင် run ပြီး လအနည်းငယ်အကြာတွင် ရုတ်တရက် database ပျက်ကျခြင်း၏ ၈၀% သည် Disk 100% ပြည့်သွားခြင်းကြောင့် ဖြစ်ပါသည်။

Linux ၏ `logrotate` utility ကို အသုံးပြုပြီး Nginx log ဖိုင်များကို နေ့စဉ် rotate လုပ်ကာ gzip compress ပြုလုပ်ပေးပြီး ၇ ရက်ထက် ကျော်လွန်သော log အဟောင်းများကို အလိုအလျောက် ဖျက်ပစ်ရပါမည်။

Docker အသုံးပြုပါက `/etc/docker/daemon.json` တွင် container log max-size ကို ကန့်သတ်ပေးထားရပါမည်။


        
          1
          $
        
        /var/log/nginx/*.log {
      

        
          2
          $
        
            daily
      

        
          3
          $
        
            missingok
      

        
          4
          $
        
            rotate 7
      

        
          5
          $
        
            compress
      

        
          6
          $
        
            delaycompress
      

        
          7
          $
        
            notifempty
      

        
          8
          $
        
            create 0640 www-data adm
      

        
          9
          $
        
            sharedscripts
      

        
          10
          $
        
            postrotate
      

        
          11
          $
        
                [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
      

        
          12
          $
        
            endscript
      

        
          13
          $
        
        }

💡Command ရှင်းလင်းချက် (ဖတ်ရှုရန် နှိပ်ပါ)

ဤ configuration သည် Nginx logs များကို နေ့စဉ် ညသန်းခေါင်တွင် rotate လုပ်ပြီး ၇ ရက်စာသာ သိမ်းဆည်းပေးကာ အဟောင်းများကို အလိုအလျောက် ဖျက်ပစ်သဖြင့် Disk ဘယ်တော့မှ မပြည့်စေပါ။

Knowledge Check

When Nginx returns a 502 Bad Gateway error, what is the most likely root cause?

Nginx က 502 Bad Gateway error ပြသနေပါက ဖြစ်နိုင်ခြေ အရှိဆုံး အကြောင်းရင်းမှာ အဘယ်နည်း?