通常 Nginx 的訪問(wèn)日志和錯(cuò)誤日志在 /var/log/nginx/ 目錄下：

cd /var/log/nginx/

同時(shí) Nginx 支持自動(dòng)切割并壓縮日志, 訪問(wèn)日志以 access.log.[數(shù)字].gz 格式命名, 錯(cuò)誤日志以 error.log.[數(shù)字].gz 格式命名, 默認(rèn)是每天都會(huì)產(chǎn)生訪問(wèn)日志和錯(cuò)誤日志的 .gz 文件。

通過(guò) ls -l 命令查看 /var/log/nginx/ 目錄下的文件創(chuàng)建時(shí)間：

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 是當(dāng)天的訪問(wèn)日志, 可以看到 error.log 是當(dāng)天的錯(cuò)誤日志夺巩。然后 .log.[數(shù)字] 中的數(shù)字表示倒退幾天, 比如 error.log.1 是昨天 (1天前) 的日志五芝、error.log.2.gz 是前天 (2天前) 的日志苟呐、error.log.3.gz 是大前天 (3天前) 的日志, 以此類(lèi)推备韧≈掳澹可以得知 Nginx 最多可以保存 15 天的日志昆稿。

下載日志目錄

為了能把日志文件下載到本地查看, 我們可以將 /var/log/nginx 設(shè)置權(quán)限為所有人都可以操作：

sudo chmod 644 /var/log/nginx
ls -l /var/log

確認(rèn) /var/log/nginx 的權(quán)限變成 drwxrwxrwx 后, 我們就可以通過(guò) SFTP 等工具將 /var/log/nginx 目錄打包下載到本地辫封，并進(jìn)行后續(xù)的分析侠碧。

匯總?cè)罩灸夸?/h2>

然后本地的 /nginx 目錄下, 創(chuàng)建一個(gè) 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 = '.'):
    """
    合并訪問(wèn)日志文件
    :param filter_condition: 篩選日志文件的文件名前綴
    :param merged_file_path: 存儲(chǔ)合并后文件的路徑
    :param directory: 存儲(chǔ)日志文件的目錄
    """
    # 獲取目錄下所有以 filter_condition 開(kāi)頭的文件
    files = [f for f in os.listdir(directory) if f.startswith(filter_condition) and not f.endswith('.gz')]
    # 打開(kāi)一個(gè)新文件抹估，用于存儲(chǔ)合并后的內(nèi)容
    merged_file = open(merged_file_path, 'w')
    # 遍歷每個(gè)文件，將內(nèi)容寫(xiě)入合并后的文件
    for file in files:
        with open(os.path.join(directory, file), 'r', encoding='utf-8') as f:
            merged_file.write(f.read())
    # 關(guān)閉合并后的文件
    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')

這個(gè)腳本做了三件事情：

1. 將當(dāng)前目錄下的 .gz 壓縮文件全部解壓
2. 將全部 access.log* 前綴的文件合并為新的 merged_access.log 文件
3. 將全部 error.log* 前綴的文件合并為新的 merged_error.log 文件

這樣我們只需通過(guò) merged_access.log 文件就可以查看最近15天的全部訪問(wèn)日志, 通過(guò) merged_error.log 文件就可以查看最近15天的全部錯(cuò)誤日志弄兜。

分析問(wèn)題

以我遇到的服務(wù)頻繁出現(xiàn) 504 Gateway Time-out 問(wèn)題的排除為例, 從 merged_error.log 文件看到錯(cuò)誤日志里有下面兩種異常：

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 的真實(shí)原因有兩個(gè)：

1. Nginx代理服務(wù) 從上游 讀取響應(yīng)標(biāo)頭時(shí) 超時(shí)
2. Nginx代理服務(wù) 讀取上游數(shù)據(jù)時(shí) 超時(shí)

因?yàn)槲业?Nginx 和應(yīng)用服務(wù)是部署在同一臺(tái)服務(wù)器上的, 首先可以排除網(wǎng)絡(luò)問(wèn)題, 那就只剩下一個(gè)可能, 就是應(yīng)用服務(wù)中的請(qǐng)求獲取的數(shù)據(jù)比較多, 或者后端處理該請(qǐng)求花費(fèi)的時(shí)間較長(zhǎng)药蜻。

這樣問(wèn)題就找到了, 那現(xiàn)在有兩個(gè)解決方案：

1. 對(duì)該接口的處理邏輯代碼進(jìn)行優(yōu)化, 或者減少請(qǐng)求響應(yīng)中的數(shù)據(jù)包大小, 這里根據(jù)實(shí)際情況來(lái)判斷
2. 通過(guò)調(diào)整 Nginx 的配置將超時(shí)時(shí)間設(shè)置長(zhǎng)些

第一個(gè)方案不可行, 因?yàn)槲疫@個(gè)接口是調(diào)用第三方 OpenAI 的實(shí)時(shí)流數(shù)據(jù), 這個(gè)接口本質(zhì)上就是個(gè)中間商, 所以就只能用第二個(gè)方案, 即調(diào)整 Nginx 的配置。

具體是 Nginx 的 proxy_read_timeout 參數(shù), 這個(gè)參數(shù)值指的是從上游服務(wù)器兩次成功 (響應(yīng)標(biāo)頭替饿、響應(yīng)內(nèi)容) 的讀操作耗時(shí)的超時(shí)時(shí)間, 也就意味著從上游服務(wù)器成功讀操作后, 過(guò)了多長(zhǎng)時(shí)間沒(méi)有再?gòu)纳嫌畏?wù)器成功讀操作的話, 就會(huì)關(guān)閉該連接语泽。默認(rèn)值是 60s, 我們可以設(shè)置為 240s 或者更長(zhǎng), 來(lái)應(yīng)對(duì)上游服務(wù)器處理請(qǐng)求慢的問(wèn)題。