从日志分析定位台湾服务器异常根因的常用工具与方法

1.

常用日誌收集與可視化工具概覽

- Elastic Stack (Filebeat → Logstash → Elasticsearch → Kibana)：適合集中化分析、多租戶索引與豐富查詢。
- Grafana + Prometheus / Metricbeat：用於指標 (metrics) 監控與告警，搭配 Grafana 面板展示趨勢。
- goaccess：快速命令列/HTML 解析 nginx/apache access.log，適合即時 RPS、4xx/5xx 統計。
- rsyslog / fluentd / graylog：不同規模的日誌路由與轉發解決方案，會依網路與儲存容量調整。
- tcpdump / tshark：封包層級分析，當日誌無法揭示 SYN/ACK、重傳或低階 TCP 問題時使用。
- 其他輔助：htop、atop、iostat、ss/netstat、conntrack、fail2ban 等系統與安全工具。

2.

從監控告警到日誌取樣的流程

- 先看監控指標：CPU、記憶體、IO、網路吞吐、連線數（例如 SS_ESTAB 數）。
- 定位時間窗：使用 Grafana 選定顯著異常時間段（例如 2025-03-12 14:02–14:18）。
- 抓取日誌快照：Filebeat / scp 把 /var/log/nginx/access.log /error.log 與 /var/log/syslog 匯出。
- 使用 goaccess 分析 RPS 與 4xx/5xx 比例快速聚合。指令示例：goaccess access.log -o report.html。
- 若懷疑網路攻擊，使用 tcpdump 過濾來源 IP 與端口：tcpdump -nn -s0 -w dump.pcap 'tcp and (port 80 or port 443) and host x.x.x.x'。

3.

實務案例：台北機房 Web 伺服器響應變慢的完整還原

- 背景：2025-03-12 促銷期間，台北某IDC 2c/8GB Ubuntu 20.04（Kernel 5.4）Web 主機出現 504 與高延遲。
- 監控發現：14:02 起 1 分內 RPS 從 200 提升到 5,000；平均 CPU 使用率從 18% 到 94%；load 由 0.8 飆到 48。
- 日誌觀察：nginx access.log 顯示大量相似 URI 與短時間內重複來源 IP，4xx 率小幅上升但 5xx 明顯增加。
- 內核檢查：cat /proc/sys/net/netfilter/nf_conntrack_count 顯示 120,384，limit 為 131,072；netstat -an | grep TIME_WAIT | wc -l = 80,412。
- 封包層級：tcpdump -nn 顯示大量 SYN 換回 SYN（大量半開連線），且來源分散 (Geo:多國)，具備小型 DDoS 特徵。

4.

故障分析與根因確認步驟（含具體命令與日誌片段）

- 步驟一：統計短時間內 IP 與 URI 熱點：awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -20。
- 日誌片段示例（access.log）：192.0.2.45 - - [12/Mar/2025:14:03:02 +0800] "GET /product?id=123 HTTP/1.1" 200 1024 "-" "Mozilla/5.0"。重複頻度高。
- 步驟二：檢查系統連線表與錯誤：ss -s 與 dmesg | tail -n50，觀察 conntrack 滿、nf_conntrack: table full 類錯誤。
- 步驟三：封包抓取快速摘要：tcpdump -n -c 1000 'tcp[tcpflags] & (tcp-syn) != 0'，並用 tshark 做統計看是否為 SYN 洪水。
- 步驟四：cross-check CDN 日誌（若使用）：檢查 CDN origin fetch 次數激增，若大量 bypass cache 調整 cache-control 可能為落後的後端回源壓力。

5.

可量化的緩解措施與系統調優示例

- 調整 conntrack：echo 524288 > /proc/sys/net/netfilter/nf_conntrack_max 與 sysctl -w net.netfilter.nf_conntrack_max=524288。
- 啟用 SYN cookies 與縮短 TIME_WAIT：sysctl -w net.ipv4.tcp_syncookies=1；sysctl -w net.ipv4.tcp_tw_reuse=1。
- iptables 限流：iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 200 -j DROP。示例用於限制單 IP 連線數。
- CDN 與 WAF：在 CDN（如 Cloudflare）啟用 Rate Limiting、WAF 規則與挑戰頁面以攔截可疑流量。
- 自動化封鎖範例：使用 fail2ban 依 nginx 日誌對 IP 進行 ban（檢測過多 404/429 或短時間高連線）。

6.

配置示例表：台北故障主機基本規格與關鍵指標（快照）

項目	數值 / 說明
主機位置	台北機房 (IDC-A)
CPU / RAM	2 vCPU / 8 GB
磁碟	200 GB NVMe
網路頻寬	1 Gbps 共用
異常期間 RPS	從 200 → 5,000
conntrack 使用量	120,384 / limit 131,072
TIME_WAIT 數量	約 80,412
主要解決方案	擴大 conntrack、啟用 SYN cookie、CDN 限流、fail2ban

7.

結語與實務建議清單

- 建議一：日誌與指標需同時存在，日誌揭示來源與行為，指標提示趨勢與迫切度。定義 1、5、15 分鐘的告警門檻。
- 建議二：在台灣節點務必測試 CDN origin cache-policy，避免促銷時大量未快取回源；設置適當的 Cache-Control 與 TTL。
- 建議三：配置自動化緊急緩解：啟用 Cloudflare/自家 LB 的 rate-limit 以快速降載；同時預備臨時封鎖 IP 段的 playbook。
- 建議四：定期演練（壓力測試）與容量規劃，模擬 conntrack、TIME_WAIT 到飽和的情況以檢視系統行為。
- 建議五：記錄每次事件的 timeline、命令與處理結果，將分析流程納入 SOP 以便未來快速復原。

来源：从日志分析定位台湾服务器异常根因的常用工具与方法