線上故障排查指南：讓你的服務器起死回生的必殺技
作者：everystep
作為一名服務端工程師，你是否遇到過線上服務響應特別慢、系統越用越卡這些讓人頭疼的場景？這些都是我們必須面對和解決的挑戰。
你是否遇到過這些讓人頭疼的場景？
- 凌晨3點被運維電話驚醒：「線上服務響應特別慢！」
- 大促活動突然宕機：「CPU 100%，服務器快撐不住了！」
- 收到用戶投訴：「為什么系統越用越卡？」
作為一名服務端工程師，這些都是我們必須面對和解決的挑戰。但別擔心！
通過這篇實戰指南，你將學會：
- 快速定位性能瓶頸的實用技巧
- 應對高并發場景的實戰經驗
- 系統調優和故障排查的必備工具
- 內存泄漏等常見問題的解決方案
讓我們開始動手實踐，把每個技能都變成你的"必殺技"！
日志分析小貼士：安全第一哦！
大家好！今天我要教你一個超級重要的小技巧 - 在碰日志前要先"量體溫"！
先來看看日志文件有多重：
$ ls -lh /var/log/nginx/access.log
│ │ │
│ │ └── 要查看的文件路徑 ??
│ └──── h表示human readable，讓文件大小更易讀 ??
└────── l表示long format，顯示詳細信息 ??
-rw-r--r-- 1 nginx nginx 6.5M Mar 20 15:00 access.log # 哇！這個日志有點重量級！???♂?輸出解釋：
- -rw-r--r-- ：文件權限（讀寫權限）
- nginx nginx：文件所屬用戶和用戶組
- 6.5M：文件大小（以人類易讀的方式顯示）
- Mar 20 15:00：最后修改時間
為什么要這樣做呢？因為...
- 直接用 cat 看大文件就像一口氣吃一頭大象
- 服務器會累得直喘氣
- 可能會讓其他小伙伴訪問不了網站
如果發現日志文件太大，我們有個小妙招：
# 把大象搬到別的地方慢慢吃 ??
$ scp /var/log/nginx/access.log test-server:/tmp/
│ │ │ │
│ │ │ └── 目標路徑：文件將被復制到這里 ??
│ │ └── 目標服務器：可以是主機名或IP地址 ???
│ └── 源文件：要復制的日志文件路徑 ??
└──── scp命令：secure copy，安全復制協議 ??scp 命令參數詳解：
- -r：復制整個目錄及其內容
- -P：指定SSH端口號（大寫P）
- -i：使用指定的私鑰文件
- -v：顯示詳細的傳輸過程
- -p：保留原文件的修改時間和權限
使用示例：
# 使用指定端口復制文件
$ scp -P 2222 access.log test-server:/tmp/ # 使用2222端口 ??
# 使用私鑰文件
$ scp -i ~/.ssh/id_rsa access.log test-server:/tmp/ # 指定私鑰 ??
# 復制整個目錄
$ scp -r /var/log/nginx/ test-server:/backup/ # 復制整個目錄 ??
# 保留文件屬性
$ scp -p access.log test-server:/tmp/ # 保留時間和權限 ?小貼士：使用 scp 的注意事項
- 確保目標服務器有足夠的磁盤空間
- 檢查網絡連接是否穩定
- 注意文件權限設置
- 大文件傳輸時建議使用 -C 參數壓縮傳輸
想偷偷看看日志最后幾行？試試這個：
$ tail -n 5 access.log
│ │ │
│ │ └── 要查看的日志文件 ??
│ └──── 顯示的行數（這里是5行）??
└──────── tail命令：查看文件末尾內容 ??
192.168.1.100 GET /api/users 200 # 成功啦！??
192.168.1.101 POST /api/login 401 # 哎呀，登錄失敗了 ??
# ... 更多訪問記錄 ...tail 命令參數詳解：
- -n：指定要顯示的行數
- -f：實時監控文件變化（follow模式）
- -F：類似-f，但是文件被刪除后會重試
- -q：不顯示文件名頭部
- -v：顯示詳細的文件名頭部
使用示例：
# 顯示最后10行（默認）
$ tail access.log # 查看最新10條記錄 ??
# 實時監控日志更新
$ tail -f access.log # 像看電影一樣實時觀察 ??
# 同時監控多個文件
$ tail -f access.log error.log # 多文件同步監控 ??
# 顯示文件末尾100字節
$ tail -c 100 access.log # 按字節查看 ??小貼士：tail 命令使用技巧
- 使用 -f 監控時，按 Ctrl+C 可以退出
- 配合 grep 可以過濾特定內容
- 可以用 -n +1 從頭開始顯示文件
- 建議對大文件使用 tail 而不是 cat
記住：溫柔對待你的日志，日志也會溫柔對待你！
來看看誰是最活躍的訪客：
$ cat access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -3
156 192.168.1.100 # 這位可真是個忠實用戶！??
89 192.168.1.101 # 二等獎也不錯哦！??
67 192.168.1.102 # 銅牌得主繼續加油！??讓我們偷偷看看服務器的小秘密：
$ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1234 root 20 0 985148 65404 31220 S 25.0 3.2 12:34 nginx ??♂?
5678 mysql 20 0 1258216 326892 8216 S 15.0 8.1 5:67 mysql ??
9012 redis 20 0 162672 29684 4508 S 5.0 0.7 2:45 redis ??
# 看！每個進程都在忙著工作呢！??這樣看輸出結果是不是更有意思了？每個數字背后都有一個小故事在等著你發現！
檢查服務器狀態：
$ top這就像給服務器量體溫 ：
- PID：每個進程的身份證號
- CPU%：進程的"體溫"
- MEM%：進程的"食量"
- COMMAND：進程的"名字"
小貼士：記住這些命令就像收集寶可夢一樣有趣！
- 每個命令都有特殊技能
- 組合使用威力更大
- 熟能生巧，多練習！
看！這樣是不是更容易理解每個命令在做什么了？繼續加油，你已經是個小小運維高手啦！
響應時間分析：從點菜到上菜
讓我們用專業工具分析響應時間：
# 測試網站響應時間
$ curl -w "\n?? 總耗時: %{time_total}秒\n" -s https://example.com
?? 總耗時: 0.235秒
# 詳細的性能分析
$ ab -n 100 -c 10 https://example.com/
測試結果 ??:
- 平均響應: 0.389秒 ?
- 成功率: 98% ?
- 錯誤數: 2 ??錯誤日志分析：發現并解決問題
當系統出現問題時，錯誤日志是我們的好幫手。讓我們來學習一些實用的日志分析命令：
# 查看錯誤日志
$ grep ERROR /var/log/app.log
│ │ │
│ │ └── 要搜索的日志文件路徑 ??
│ └──── 要搜索的關鍵詞 ??
└──────── grep命令：在文件中搜索文本 ??
[ERROR] 2024-03-20 15:00:23 數據庫連接超時 ??
[ERROR] 2024-03-20 15:00:25 內存不足 ??grep 命令參數詳解：
- -i：忽略大小寫
- -n：顯示行號
- -r：遞歸搜索目錄
- -v：顯示不匹配的行
- -c：只顯示匹配行數
使用示例：
# 顯示行號
$ grep -n ERROR /var/log/app.log # 知道錯誤在第幾行 ??
# 忽略大小寫搜索
$ grep -i error /var/log/app.log # 匹配 ERROR、error 等 ??
# 遞歸搜索所有日志文件
$ grep -r ERROR /var/log/ # 搜索整個日志目錄 ??
# 統計錯誤次數
$ grep -c ERROR /var/log/app.log # 只顯示錯誤數量 ??來看看如何統計錯誤類型：
$ grep ERROR /var/log/app.log | awk '{print $4}' | sort | uniq -c | sort -nr
│ │ │ │ │ │ │
│ │ │ │ └────── 統計出現次數 ??
│ │ │ └── 去重 ??
│ │ └── 排序 ??
│ └── 提取第4列（錯誤類型）??
└── 過濾出錯誤日志 ??
15 數據庫超時 ?? # 最常見的錯誤
8 內存不足 ??
3 網絡異常 ??小貼士：分析錯誤日志的最佳實踐
- 定期檢查錯誤日志，及早發現問題
- 使用 grep 的 -C 參數查看錯誤上下文
- 結合時間戳分析錯誤發生規律
- 建立錯誤類型統計報表，找出常見問題
錯誤日志分析流程圖：
獲取日志 ?? --> 過濾錯誤 ?? --> 分析原因 ?? --> 解決問題 ?面試要點：日志分析技巧
面試官最愛問的問題：
- 如何快速定位性能問題
# 組合使用多個工具
$ dstat -cdngy 1 # 實時監控系統資源 ??
│ │││││ │
│ ││││└─ y: 系統統計信息 ??
│ │││└── g: 顯示頁面統計信息 ??
│ ││└─── n: 網絡統計信息 ??
│ │└──── d: 磁盤統計信息 ??
│ └───── c: CPU 統計信息 ??
└───────── 1: 每秒更新一次 ??
$ iotop # 監控磁盤 I/O ??
PID USER IO> DISK READ DISK WRITE COMMAND
1234 mysql 2.1 50.2 M/s 10.1 M/s mysqld
5678 nginx 0.8 2.1 M/s 1.2 M/s nginx
$ netstat -antp # 查看網絡連接 ??
│ │││└── p: 顯示進程信息 ??
│ ││└─── t: 只顯示TCP連接 ??
│ │└──── n: 顯示數字地址而不是主機名 ??
│ └───── a: 顯示所有連接 ??
└─────────── 查看網絡統計信息 ??- 如何處理大型日志文件？
# 使用高效的日志分析方法
$ zcat large.log.gz | grep ERROR | tail -n 100
│ │ │ │ │ │
│ │ │ │ │ └── 顯示行數 ??
│ │ │ │ └──── 查看末尾 ??
│ │ │ └────────── 過濾ERROR關鍵詞 ??
│ │ └─────────────── 管道傳遞輸出 ??
│ └─────────────────── 壓縮文件分隔符 |
└────────────────────────────── 讀取壓縮文件 ??
$ awk '/ERROR/ {print $4}' large.log | sort | uniq -c
│ │ │ │ │ │ │
│ │ │ │ │ │ └── 計數 ??
│ │ │ │ │ └──── 去重 ??
│ │ │ │ └────── 排序 ??
│ │ │ └──────────── 打印第4列 ??
│ │ └────────────────── 執行的動作 ??
│ └─────────────────────── 匹配模式 ??
└───────────────────────── 文本處理工具 ???性能分析工具對比圖：
dstat ?? 系統整體狀況 ??
├── CPU使用率 ??
├── 磁盤I/O ??
├── 網絡流量 ??
└── 內存使用 ??
iotop ?? 磁盤I/O詳情 ??
├── 讀取速度 ??
├── 寫入速度 ??
└── 進程信息 ??
netstat ?? 網絡連接狀態 ??
├── TCP/UDP連接 ??
├── 端口占用 ??
└── 進程信息 ??小貼士：性能分析最佳實踐
- 先用 dstat 獲取系統整體狀況
- 發現 I/O 異常時使用 iotop 深入分析
- 網絡問題用 netstat 排查
- 注意收集足夠的樣本數據
- 建立基準數據，便于對比分析
常見性能問題及解決方案：
(1) CPU 使用率高
- 使用 top 找出高負載進程
- 分析進程是否存在死循環
- 考慮增加 CPU 核心或優化代碼
(2) 磁盤 I/O 瓶頸
- 使用 iotop 監控磁盤讀寫
- 檢查是否存在大量小文件操作
- 考慮使用 SSD 或優化存儲策略
(3) 網絡延遲高
- 使用 netstat 檢查連接狀態
- 分析網絡包是否丟失
- 考慮優化網絡配置或增加帶寬
責任編輯：趙寧寧
來源：
everystep
