Nginx 日誌模組深度解析：error_log 與 access_log 架構、緩存機制與最佳實踐

Nginx 日誌系統由 error_log (錯誤/診斷) 與 access_log (訪問/審計) 兩大核心指令構建，底層涉及多模組協作、文件描述符緩存、紅黑樹管理等機制。本文從源碼視角剖析兩指令註冊差異、作用域繼承、變量路徑處理、緩存策略，助力運維與二次開發。

雙模組註冊機制：為何有兩個 error_log？

設計意圖： Core 模組優先註冊，捕獲 HTTP 模組載入前的早期錯誤；HTTP 模組提供分級配置 (server/location 覆蓋)，實現精細化錯誤路由。兩者互不耦合，各司其職。

配置繼承與合併邏輯

// ngx_http_core_merge_loc_conf 片段
if (conf->error_log == NULL) {
    if (prev->error_log) {
        conf->error_log = prev->error_log;      // 繼承父級
    } else {
        conf->error_log = &cf->cycle->new_log;  // 回退 core error_log
    }
}

若 http {} 未顯式設定 error_log，所有 server/location 自動繼承 main 級 core error_log，保證無遺漏。

access_log 核心架構

1. 階段處理器

屬於 NGX_HTTP_LOG_PHASE (最後階段)，請求處理完畢前執行，記錄完整訪問資訊。

2. 變量路徑支援 (關鍵差異)

# 常量路徑 → 緩存 fd 於 cycle->open_files
access_log logs/access.log main;

# 變量路徑 → 動態解析，走 script 機制
access_log logs/'$remote_addr'-access.log main;

• 常量路徑： 啟動時打開 fd 存入 cycle->open_files 鏈表 (去重)，寫入調用 ngx_write_fd，極高效。
• 變量路徑： 每請求解析變量生成路徑，走 ngx_http_log_script_write，需管理 fd 緩存，避免海量 fd 耗盡系統上限。

3. 變量日誌 fd 緩存策略 (open_log_file_cache)

open_log_file_cache max=1000 inactive=60s min_uses=2 valid=10s;

• 使用紅黑樹 (rbtree) + 隊列 (queue) 管理緩存項 (ngx_cached_open_file_t)。
• inactive 內未達 min_uses → 淘汰；達標 → 進入活躍隊列。
• valid 間隔檢查是否超時。
• 請求結束銷毀內存池時，cleanup 機制自動關閉未緩存 fd。

兩大 fd 緩存指令對比

兩者底層均調用 ngx_open_file_cache_init 初始化紅黑樹，但管理對象完全隔離。

運維最佳實踐

1. 錯誤日誌分級： main 設 warn，server 覆蓋 error，location 關鍵業務設 debug (臨時)。
2. 訪問日誌切分： 高流量站點啟用 open_log_file_cache，max=5000 inactive=30s，避免單進程 fd 爆滿。
3. 日誌輪轉： 外部 logrotate + nginx -s reopen (發送 NGX_REOPEN_SIGNAL)，Nginx 重新打開 fd，舊檔交由 logrotate 壓縮備份。
4. 避免刪除日誌檔： 運行中 rm access.log 不會生成新檔，fd 指向已刪除 inode，日誌丟失。正確做法：mv access.log access.log.old && nginx -s reopen。
5. 關閉不必要的 access_log： 內部 API、健康檢查端點設 access_log off; 減少 I/O。

深入理解 Nginx 日誌模組架構，能精準排查「日誌不寫入、fd 洩漏、磁碟爆滿」等疑難雜症，亦為高性能日誌管道設計奠基。