通常 Nginx 的訪問日志和錯誤日志在 /var/log/nginx/ 目錄下：
cd /var/log/nginx/
同時 Nginx 支持自動切割并壓縮日志, 訪問日志以 access.log.[數字].gz 格式命名, 錯誤日志以 error.log.[數字].gz 格式命名, 默認是每天都會產生訪問日志和錯誤日志的 .gz 文件。
通過 ls -l 命令查看 /var/log/nginx/ 目錄下的文件創建時間：
Nov 2 22:18 access.log
Nov 1 23:59 access.log.1
Oct 23 23:36 access.log.10.gz
Oct 22 23:48 access.log.11.gz
Oct 21 23:50 access.log.12.gz
Oct 20 23:55 access.log.13.gz
Oct 19 23:35 access.log.14.gz
Oct 31 23:59 access.log.2.gz
Oct 30 23:51 access.log.3.gz
Oct 29 23:59 access.log.4.gz
Oct 28 23:47 access.log.5.gz
Oct 27 23:38 access.log.6.gz
Oct 26 23:41 access.log.7.gz
Oct 25 23:45 access.log.8.gz
Oct 24 23:46 access.log.9.gz
Nov 2 22:11 error.log
Nov 1 21:16 error.log.1
Oct 23 22:50 error.log.10.gz
Oct 22 10:37 error.log.11.gz
Oct 21 12:21 error.log.12.gz
Oct 20 22:52 error.log.13.gz
Oct 19 17:03 error.log.14.gz
Oct 31 10:48 error.log.2.gz
Oct 30 23:43 error.log.3.gz
Oct 29 16:50 error.log.4.gz
Oct 28 21:02 error.log.5.gz
Oct 27 18:05 error.log.6.gz
Oct 26 17:35 error.log.7.gz
Oct 25 20:11 error.log.8.gz
Oct 24 23:30 error.log.9.gz
可以看到 access.log 是當天的訪問日志, 可以看到 error.log 是當天的錯誤日志。然后 .log.[數字] 中的數字表示倒退幾天, 比如 error.log.1 是昨天 (1天前) 的日志、error.log.2.gz 是前天 (2天前) 的日志、error.log.3.gz 是大前天 (3天前) 的日志, 以此類推。可以得知 Nginx 最多可以保存 15 天的日志。
下載日志目錄
為了能把日志文件下載到本地查看, 我們可以將 /var/log/nginx 設置權限為所有人都可以操作：
sudo chmod 644 /var/log/nginx
ls -l /var/log
確認 /var/log/nginx 的權限變成 drwxrwxrwx 后, 我們就可以通過 SFTP 等工具將 /var/log/nginx 目錄打包下載到本地，并進行后續的分析。
匯總日志目錄
然后本地的 /nginx 目錄下, 創建一個 nginx_log.py 文件, 文件的代碼如下：
import os
import gzip
def decompress_files(directory: str = '.'):
"""
解壓目錄下的.gz壓縮文件為原始文件
:param directory: 目錄路徑
"""
# 遍歷目錄下所有文件
for filename in os.listdir(directory):
filepath = os.path.join(directory, filename)
# 判斷文件是否為.gz壓縮包
if filepath.endswith('.gz'):
# 解壓縮.gz壓縮包
with gzip.open(filepath, 'rb') as f_in:
uncompressed_filepath = filepath[:-3] # 去掉.gz后綴
with open(uncompressed_filepath, 'wb') as f_out:
f_out.write(f_in.read())
def merge_nginx_log_files(filter_condition, merged_file_path, directory: str = '.'):
"""
合并訪問日志文件
:param filter_condition: 篩選日志文件的文件名前綴
:param merged_file_path: 存儲合并后文件的路徑
:param directory: 存儲日志文件的目錄
"""
# 獲取目錄下所有以 filter_condition 開頭的文件
files = [f for f in os.listdir(directory) if f.startswith(filter_condition) and not f.endswith('.gz')]
# 打開一個新文件，用于存儲合并后的內容
merged_file = open(merged_file_path, 'w')
# 遍歷每個文件，將內容寫入合并后的文件
for file in files:
with open(os.path.join(directory, file), 'r', encoding='utf-8') as f:
merged_file.write(f.read())
# 關閉合并后的文件
merged_file.close()
if __name__ == '__main__':
decompress_files()
merge_nginx_log_files('access.log', 'merged_access.log')
merge_nginx_log_files('error.log', 'merged_error.log')
這個腳本做了三件事情：
- 將當前目錄下的
.gz壓縮文件全部解壓 - 將全部
access.log*前綴的文件合并為新的merged_access.log文件 - 將全部
error.log*前綴的文件合并為新的merged_error.log文件
這樣我們只需通過 merged_access.log 文件就可以查看最近15天的全部訪問日志, 通過 merged_error.log 文件就可以查看最近15天的全部錯誤日志。
分析問題
以我遇到的服務頻繁出現 504 Gateway Time-out 問題的排除為例, 從 merged_error.log 文件看到錯誤日志里有下面兩種異常：
upstream timed out (110: Unknown error) while reading response header from upstream
upstream timed out (110: Unknown error) while reading upstream
然后就知道 504 Gateway Time-out 的真實原因有兩個：
- Nginx代理服務 從上游 讀取響應標頭時 超時
- Nginx代理服務 讀取上游數據時 超時
因為我的 Nginx 和應用服務是部署在同一臺服務器上的, 首先可以排除網絡問題, 那就只剩下一個可能, 就是應用服務中的請求獲取的數據比較多, 或者后端處理該請求花費的時間較長。
這樣問題就找到了, 那現在有兩個解決方案：
- 對該接口的處理邏輯代碼進行優化, 或者減少請求響應中的數據包大小, 這里根據實際情況來判斷
- 通過調整 Nginx 的配置將超時時間設置長些
第一個方案不可行, 因為我這個接口是調用第三方 OpenAI 的實時流數據, 這個接口本質上就是個中間商, 所以就只能用第二個方案, 即調整 Nginx 的配置。
具體是 Nginx 的 proxy_read_timeout 參數, 這個參數值指的是從上游服務器兩次成功 (響應標頭、響應內容) 的讀操作耗時的超時時間, 也就意味著從上游服務器成功讀操作后, 過了多長時間沒有再從上游服務器成功讀操作的話, 就會關閉該連接。默認值是 60s, 我們可以設置為 240s 或者更長, 來應對上游服務器處理請求慢的問題。
