AboutDockerProfessional illustrations
Docker Service Logs 基礎教學
好喇，咁我哋就由最基礎嘅 Docker Service Logs 講起。如果你係用開 Docker Swarm 嚟管理你嘅服務（Service），咁識得點樣睇同埋管理日誌（Logs）就係基本中嘅基本。好多新手一開始會撈亂咗「容器日誌」同「服務日誌」，其實概念係有啲唔同㗎。簡單嚟講，當你用 Docker Swarm 模式行一個服務，Swarm Manager 會幫你調度同管理一堆「任務」（Tasks），每個任務就係一個運行緊嘅容器。所以，你平時用開嘅 docker container logs 命令，係用嚟睇單一個容器嘅日誌；而 docker service logs 呢，就係 Swarm 模式專用，俾你一次過睇晒同一個服務底下所有任務（即係所有容器）嘅日誌輸出，對於監察一個分散式服務嘅整體健康狀況真係好方便。
要開始用 docker service logs 呢個 CLI命令，首先你要確保自己已經初始化咗一個 Swarm 叢集，或者已經加入咗一個現有嘅 Swarm 集羣。跟住，你就可以用 Docker CLI 嚟創建同管理服務。例如，你喺命令行打 docker service create --name my_web nginx:latest，咁就創建咗一個叫做 my_web 嘅服務。想睇呢個服務嘅日誌？好簡單，打 docker service logs my_web 就得。呢個命令會將服務底下所有任務嘅標準輸出（stdout）同標準錯誤（stderr）串流返出嚟，你喺終端機就會睇到晒所有容器嘅實時日誌混埋一齊，對於快速除錯好有用。
不過，淨係識得打出嚟睇係唔夠嘅，你要知道背後係點樣運作。Docker 日誌嘅核心，係個「日誌驅動程序」（Logging Driver）。默認情況下，Docker 會用 json-file 呢個驅動程式，即係將容器嘅日誌以 JSON 格式寫入宿主機嘅檔案系統。當你行 docker service logs 時，Docker daemon 其實就係去讀取呢啲 JSON 檔案再呈現俾你睇。但係，喺唔同嘅操作系統上，默認或者推薦嘅日誌驅動程式可能會唔同。例如，如果你喺 Ubuntu 或者 CentOS 呢類原生行 systemd 嘅 Linux 發行版上，你完全可以將日誌驅動程式設定為 journald。咁樣做嘅好處係，所有容器日誌都會直接交俾系統嘅 journald 服務管理，你可以用 journalctl 呢個強大工具嚟統一查詢同過濾日誌，同系統其他日誌整合得更好。至於 macOS 同 Windows，雖然而家好少人再用舊版 Docker Toolbox，主流都用緊 Docker for Mac 同 Docker for Windows（即係 Docker Desktop），但都要留意返，佢哋底層嘅日誌處理可能因為虛擬化層而有少少差異，不過基本嘅 docker service logs 命令用法都係一致嘅。
講到點樣有效使用 docker service logs，一定要識得佢嘅常用命令參數。淨係打命令名出嚟，日誌可能會多到睇唔切，所以你要識得過濾。例如，加 --follow 或者 -f 參數，就可以「跟住」日誌輸出，即係類似 tail -f 嘅效果，對於監察實時情況好重要。加 --tail 參數，例如 --tail 100，就係只顯示最後 100 行日誌，唔使由頭 load 到尾。如果你想睇某個服務入面特定任務嘅日誌，可以加 --task 參數，後面跟住任務嘅 ID。另外，--details 參數會顯示多啲額外資訊，例如環境變數之類，幫你更深入了解個服務嘅運行上下文。喺做服務管理，例如服務更新或者服務檢查時，靈活運用呢啲參數可以大幅提升你嘅工作效率。
最後都要提提一啲實際應用上嘅考慮。當你個服務因為服務擴展而有多個副本（replicas）運行緊，docker service logs 預設會將所有副本嘅日誌撈亂一齊顯示。呢個對於睇整體流量同錯誤模式係好，但如果你想追蹤某一個特定請求，啲日誌混埋就可能好難睇。所以，好多時實戰上會配合一啲更先進嘅日誌策略，例如喺應用層面為每條日誌加上統一嘅請求 ID（Request ID），又或者直接配置個日誌驅動程式，將日誌直接送到好似 Elasticsearch、Fluentd 或者 Loki 呢類中央日誌管理系統，而唔係淨係依賴本地嘅 json-file。不過，作為基礎教學，掌握好 docker service logs 呢個內置工具，絕對係你進行 Docker Swarm 叢集管理 同任務管理嘅第一步，亦係日後設定更複雜日誌管線嘅基石。記住，無論你用緊 Ubuntu、CentOS 定係 macOS，理解清楚日誌嘅來源（係來自服務定係單一容器）同埋點樣有效提取資訊，先至係解決問題嘅關鍵。
AboutSwarmProfessional illustrations
點解要睇服務日誌？
好啦，咁究竟點解要睇服務日誌呢？呢個問題對於用緊 Docker Swarm 或者普通 Docker Service 嘅朋友嚟講，真係核心到不得了。首先你要明，當你將一個應用程式打包成 容器 並以 服務 形式喺 Swarm 叢集入面運行嗰陣，佢已經唔係一個獨立嘅個體咁簡單。一個服務可能會由多個相同嘅任務（Task）組成，每個任務又係一個運行緊嘅容器，散落喺唔同嘅節點上。你喺自己部機用 docker logs 睇單一容器嘅日子已經過去，而家要管理嘅係一個分散式系統。睇服務日誌，就係你唯一可以穿透呢個複雜性，直接睇到服務整體同埋每個任務實時運作狀況嘅「上帝視角」。無論你係用緊 Ubuntu、CentOS 嘅 systemd 配合 journald，定係 macOS 上嘅 Docker for Mac，又或者係 Windows 環境，日誌都係你診斷問題嘅第一手材料。
咁具體有咩情況非睇日誌不可呢？我哋舉幾個實戰例子。假設你喺 Swarm 入面用 docker service scale 將某個服務擴展到10個副本，但係發現有兩個副本狀態成日係「Failed」或者不停重啟。你淨係靠 docker service ps 睇到個狀態係唔夠嘅，你必須要用 docker service logs 呢個 CLI命令 去追查嗰兩個失敗任務嘅日誌，先至可以知道究竟係應用程式本身有bug（例如連唔到數據庫），定係容器啟動時資源不足（例如 memory limit 設得太低），又或者係映象本身就有問題。另一個常見場景係服務更新（Rolling Update）出錯。當你用 docker service update 去部署新版本映象時，如果新版本有問題，服務可能會卡住或者回滾。呢個時候，睇緊急更新中嘅任務日誌，就可以幫你快速定位係新代碼邊一部分出錯，避免成個服務停擺。
深入啲講，日誌嘅來源同格式都好關鍵，呢度就涉及到 Logging Driver（日誌驅動程序）嘅設定。Docker 預設可能用 json-file，將日誌寫喺主機嘅JSON檔案入面。但係喺生產環境，特別係用緊 systemd 嘅 Linux 系統（例如 CentOS 7+、Ubuntu 16.04+），好多管理員會將 Logging Driver 設定為 journald。咁做有好處，因為所有 容器日誌 都會統一交由 systemd 嘅 journald 管理，你可以用 journalctl 呢個強大工具，配合 Docker 服務同容器嘅標籤去集中查詢同分析日誌，仲可以方便咁做日誌轉發。如果你唔了解你嘅環境用緊邊種 日誌驅動程式，你連去邊度搵日誌都可能唔知，所以呢個係基礎中嘅基礎。無論你用 Docker Toolbox 定係新嘅 Docker for Mac，都要去了解背後嘅日誌機制。
最後，從 服務管理 同 叢集管理 嘅宏觀角度睇，持續監察日誌並唔只係為咗救火。透過分析日誌，你可以了解到服務嘅正常行為模式，例如請求量、處理時間、常見嘅資訊級別訊息等。當出現異常模式（例如錯誤訊息突然暴增，或者出現大量 WARNING）時，日誌就係最早嘅預警系統。而且，喺 Docker Swarm 呢類編排平台，Docker daemon 本身同服務調度相關嘅事件同錯誤，有時都會反映喺相關嘅日誌流入面。所以，養成定期同有需要時查閱 服務日誌 嘅習慣，絕對係維運現代化容器化應用不可或缺嘅一環，幫你從被動救火變成主動預防，確保服務嘅穩定同可靠。
AboutServiceProfessional illustrations
2026年最新指令參數詳解
講到2026年最新嘅指令參數詳解，我哋首先要搞清楚，而家Docker CLI同Docker daemon嘅互動已經更加智能，尤其係喺管理Swarm叢集服務嗰陣。Docker service logs 呢個命令，依然係我哋追蹤服務同容器日誌嘅主力，但係參數方面就有啲細微而重要嘅更新同最佳實踐要留意。對於日日同Docker Swarm打交道嘅師兄嚟講，點樣靈活運用呢啲參數，直接影響到你排查問題嘅速度同效率。
最基本又最常用嘅，梗係 --follow 或者 -f 參數啦，佢可以即時tail住服務嘅日誌輸出，對於監察緊急任務或者即時debug係不可或缺。不過2026年嘅新習慣係，配合埋 --tail 參數一齊用，例如 docker service logs --tail 50 --follow 你嘅服務名，咁樣就可以先顯示最近50行日誌，然後先開始即時跟進，唔會一開頭就被陳年舊log淹沒，尤其係當個服務行咗好耐，日誌驅動程序（Logging Driver）係用緊 json-file 儲存咗大量歷史嘅時候，呢個組合就更加實用。
跟住要講嘅係 --details 參數，呢個參數喺2026年變得更加有價值。默認情況下，docker service logs 只會輸出日誌訊息本身，但係加咗 --details 之後，佢會額外顯示出產生該條日誌嘅任務ID、容器ID、甚至係所屬節點等元數據。對於管理一個龐大嘅Docker Swarm集羣，特別係當某個服務有幾十個副本（replica）分散喺唔同主機（可能係Ubuntu、CentOS或者混合環境）上運行時，呢啲詳細資訊就係你快速定位問題容器同主機嘅關鍵。例如，你發現錯誤日誌，即刻就可以知道係Swarm裏面邊部機、邊個具體容器出事，唔使逐部機去SSH再用 journalctl 查（如果Logging Driver係 journald 嘅話）。
另外，針對時間範圍篩選，--since 同 --until 呢對參數你一定要識。佢哋可以幫你精準撈取特定時間段嘅日誌，格式好靈活，可以用相對時間像"10m"（10分鐘前）、"1h30m"，亦可以用絕對時間戳。假設你管理嘅網購平台服務喺今日下晝三點突然有流量高峰，你想睇吓嗰段時間有冇異常，就可以用 docker service logs --since "2026-03-15T14:30:00" --until "2026-03-15T15:30:00" 服務名 嚟提取。呢個功能對於事後分析Incident或者做審計記錄，真係幫到手。
唔好唔記得 --raw 參數。有時我哋需要將日誌原汁原味咁輸出，唔好經過Docker CLI嘅格式化同着色。咁樣做嘅好處係，方便我哋將日誌直接管道（pipe）去其他命令行工具進行二次處理，例如用grep、awk做更複雜嘅分析，或者匯出到檔案做長久保存。呢個參數喺自動化腳本裏面特別常用。
講到日誌驅動程式（Logging Driver），參數嘅應用都會有啲唔同。如果你嘅Docker daemon設定係用 systemd 配合 journald 作為默認驅動（常見於新版本嘅CentOS或Ubuntu伺服器），咁你查日誌其實有兩個途徑：一係用返Docker CLI嘅 docker service logs，佢會幫你從journald度攞資料；二係直接喺主機上用 journalctl -u docker.service 再配合篩選條件去查。前者嘅好處係統一，唔理你個服務行緊邊部機，一個命令睇勻；後者就可能睇到更多底層systemd同Docker daemon本身嘅訊息。至於仲用緊 JSON-file 驅動嘅環境（或者一啲舊版Docker Toolbox、Docker for Mac嘅默認設定），docker service logs 就係直接讀取本地嘅JSON日誌檔案，參數用法一樣，但就要注意主機磁碟空間嘅管理。
最後提一提環境差異。喺2026年，雖然Docker生態已經好統一，但喺唔同操作系統上，日誌管理嘅底層仲係有分別。例如，你喺Windows Server上運行Swarm服務，日誌驅動嘅選項同表現可能同Linux有少少唔同；而喺macOS上用Docker Desktop做開發測試，佢背後嘅虛擬化層亦可能令到日誌嘅存取路徑有別。所以，我嘅建議係，無論你用緊咩平台（Windows、macOS或者各種Linux發行版），最好都係先了解清楚你當前環境嘅默認Logging Driver係咩，同埋相關嘅參數有冇平台特定嘅行為。總而言之，熟練掌握呢堆 docker service logs 嘅參數，就等於有咗一把瑞士軍刀，可以幫你喺複雜嘅容器同服務管理任務中，快、狠、準咁攞到你想要嘅資訊，無論係做日常監察、定係救火debug，都能夠得心應手。
About容器Professional illustrations
實時監控日誌嘅方法
好啦，講完點樣睇歷史日誌，咁我哋即刻跳去最實用嘅環節：實時監控日誌嘅方法。喺 Docker Swarm 入面，尤其係當你個服務有幾十個任務（Task）同時跑緊，能夠即時睇到日誌嘅流向，對於偵錯同監控系統健康狀況係極之重要。最基本又最直接嘅方法，梗係用 Docker CLI 嘅 docker service logs 命令啦。呢個命令係你管理 Docker Service 嘅好幫手，唔使 SSH 入去每部機逐個 容器 查，一個指令就可以追蹤晒成個服務嘅實時輸出。
點樣用呢？好簡單，你喺 命令行接口 打開，打 docker service logs -f 你嘅服務名。後面個 -f 參數就係關鍵，代表「follow」，即係話個指令會一直掛住，只要有新嘅日誌行產生，就會即刻顯示喺你個 Terminal 度，做到真正嘅 實時監控。例如你個服務叫 web_api，咁你打 docker service logs -f web_api，所有屬於呢個服務嘅任務嘅標準輸出（stdout）同錯誤（stderr）就會好似瀑布流咁湧出嚟，你即時就可以見到有冇 Error 爆出，或者啲程式輸出係咪正常。
不過，淨係用 -f 有時會太亂，因為 Swarm 可能會將服務嘅任務分散喺唔同節點運行，所有日誌會撈埋一齊出。咁點算呢？呢個時候就要識得用其他 命令參數 來過濾同精準監控。例如你可以加 --tail 參數，指定只係睇最新嘅幾行，然後先開始跟蹤，例如 docker service logs -f --tail 10 web_api，就會先顯示最後10行，再開始跟實時日誌。另一個超好用嘅參數係 --raw，佢會顯示未經加工嘅日誌內容，冇咗時間戳同任務ID嘅前綴，對於想直接擷取純文字內容去做分析好有用。
如果你只想監控某一個特定任務嘅日誌，又得唔得呢？當然得！你可以先用 docker service ps 你嘅服務名 來列出所有任務同佢哋嘅 ID，然後用 docker service logs -f 任務ID 來專門追蹤嗰個任務。喺複雜嘅 叢集管理 場景下，當你懷疑某個節點上嘅容器有問題，呢個方法可以幫你快速定位，唔使俾其他正常任務嘅日誌干擾視線。
講到實時監控，背後其實係倚賴 Docker daemon 同個 Logging Driver（日誌驅動程序）嘅合作。默認情況下，Docker 會用 json-file 呢個驅動程式，將日誌以 JSON 格式寫喺主機嘅檔案系統度。當你用 docker service logs 命令時，Docker CLI 就會經由 Daemon 去讀取呢啲 JSON 檔案，然後串流俾你睇。所以，實時監控嘅流暢度，某程度上都受呢個底層驅動影響。
但係，如果你嘅環境係用緊 systemd 嘅 Linux 發行版，例如 Ubuntu 或者 CentOS，好多時會建議將 日誌驅動程式 設定為 journald。點解呢？因為咁樣可以將所有容器日誌直接交俾系統嘅 journald 服務統一管理。咁做嘅好處係，你可以用系統原生嘅 journalctl 命令來做更強大嘅實時監控，例如打 journalctl -f CONTAINER_NAME=容器名 來追蹤，又或者用更多 systemd 提供嘅過濾同查詢功能，整合度更高。不過要留意，喺 Swarm 模式底下，每個節點都要統一設定好個 Logging Driver，先可以確保日誌收集方式一致。
至於 Windows 同 macOS 嘅用家，雖然你哋唔會用到 journald，但實時監控嘅原理同命令都係一樣。用 Docker for Mac 或者 Docker Desktop on Windows，你一樣可以喺 PowerShell 或者 Terminal 入面順暢咁運行 docker service logs -f 呢個 CLI命令。以前嘅 Docker Toolbox 就已經係舊時代嘅產物，喺2026年嘅今日，已經冇乜人用，直接用 Desktop 版本就最穩定同功能最齊。
最後提多個實用技巧：有時日誌太多太密，你想一邊監控一邊搵關鍵字點算？你可以配合管道（pipe）同 grep 呢類工具一齊用。例如，你想即時監控 web_api 服務，但只係想睇包含「ERROR」字眼嘅行，你可以試下 docker service logs -f web_api 2>&1 | grep ERROR。當然，呢個方法會令你跟唔到完整嘅日誌流，但對於快速捕捉嚴重錯誤就好有效率。總括來講，掌握 docker service logs 命令同佢嘅參數，靈活配合你嘅 服務管理 同 任務管理 工作，就係做好 實時監控日誌 嘅基本功。
About服務Professional illustrations
點樣過濾同搜尋日誌？
好啦，講到點樣過濾同搜尋 Docker Service 嘅日誌，呢個真係日常維運嘅核心技能嚟。好多時個服務出咗事，日誌多到睇唔切，你唔識得用啲過濾技巧，真係好似大海撈針咁。喺 Docker Swarm 環境入面，用 docker service logs 呢個 CLI命令 係最基本，但佢有好多實用參數幫你精準搵到想要嘅嘢。
首先，最基本就係跟住個 服務 名或者服務ID去睇。例如你個服務叫 web_api，咁你打 docker service logs web_api 就會出晒所有同呢個服務相關嘅 任務 嘅日誌。但係如果個服務有十個八個副本（replicas）一齊行緊，啲日誌就會撈亂晒出，睇到你頭都大。呢個時候，你可以用 --follow（或者 -f）參數去即時追蹤日誌輸出，好似睇緊直播咁，對於監察緊急問題好有用。另外，你想睇返最近嘅記錄，可以用 --tail，例如 --tail 100 就只係顯示最後100行，唔使由開天闢地嗰陣睇起。
不過，淨係咁樣睇晒所有副本嘅日誌仲係好亂。所以，過濾 功能就出場啦。其中一個最常用嘅係 --since 同 --until，用嚟指定時間範圍。例如你想睇過去15分鐘內嘅日誌，就可以用 docker service logs --since 15m web_api。呢個對於追查某個特定時間發生嘅事故好有幫助。另外，你想聚焦睇某一個特定副本（即係某一個 容器）嘅日誌，就可以用 --raw 參數配合 docker service ps 命令搵出特定任務嘅ID，再將個任務ID餵返俾個 logs 命令。雖然步驟多啲，但喺 叢集管理 入面，要精準除錯就係需要咁做。
講到 搜尋，Docker CLI 本身嘅 logs 命令無內置關鍵字搜尋功能（好似 grep 咁）。咁點算呢？標準做法就係將日誌輸出，用管道（pipe）駁去系統本身嘅搜尋工具度處理。呢個就關乎你個 Docker daemon 用緊咩 日誌驅動程序（Logging Driver）喇。如果係用緊預設嘅 json-file（喺 Ubuntu、CentOS 或者 Docker for Mac、Windows 上常見），咁啲日誌通常儲喺主機嘅檔案系統度。你可以直接喺主機用 grep 或者 find 命令去搜尋相關嘅 容器日誌 檔案。但更方便嘅做法係，直接將 docker service logs 嘅輸出，用 | 駁去 grep 度。例如你想搵所有包含 “ERROR” 字眼嘅日誌行，就可以打 docker service logs web_api 2>&1 | grep -i error。記住要將標準錯誤（stderr）都重新導向埋一齊搜尋（2>&1），因為應用程式好多時會將錯誤訊息寫去 stderr，唔係 stdout。
如果你嘅環境係用緊 journald 做 logging driver（常見於用緊 systemd 嘅 Linux 發行版），咁玩法就唔同喇。所有 容器日誌 都會交俾 systemd 嘅 journal 系統管理。呢個時候，你搜尋同過濾日誌嘅主戰場就係 journalctl 命令。你可以用 journalctl CONTAINER_NAME=容器名稱 嘅格式去睇特定容器嘅日誌，又或者用 -u 指定服務單位（service unit）嚟睇。journalctl 本身好強大，支援按時間（--since、--until）、按優先級（-p，例如 -p err 睇錯誤訊息）、同埋關鍵字搜尋（直接用 grep 模式或者加 -g 參數），對於管理 服務日誌 嚟講非常高效。例如，你想睇某個服務最近半個鐘頭嘅錯誤訊息，命令可能係 journalctl CONTAINER_NAME=web_api.1.xyz -p err --since "30 minutes ago"。
對於 Windows 用家嚟講，如果你係用 Docker Desktop for Windows，預設日誌驅動都係 json-file，所以上面講嘅管道駁 findstr（Windows 版嘅 grep）嘅方法一樣適用，例如 docker service logs win_service | findstr "error"。至於 macOS 用家，無論係用緊 Docker for Mac 定係舊版 Docker Toolbox，基本邏輯都係一樣，主要都係靠 json-file 驅動同管道到 grep 進行搜尋。
最後提多個進階技巧，就係點樣喺 服務創建 或 服務更新 嘅時候，預先設定好日誌嘅處理方式，等日後容易啲過濾。你可以用 --log-driver 同 --log-opt 參數。例如，你創建服務時指定 --log-driver json-file --log-opt max-size=10m --log-opt max-file=3，咁就確保日誌檔案唔會無限膨脹，而且係以結構化嘅 JSON 格式儲存，第時你想用 jq 呢類工具去做更複雜嘅過濾同分析都會方便好多。總而言之，熟練運用 docker service logs 嘅各種 命令參數，再配合你作業系統嘅原生工具（grep、journalctl、findstr），同埋了解清楚底層用緊咩 日誌驅動程式，你就可以喺海量嘅 服務日誌 入面，快速鎖定問題根源，做好 服務管理 同 集羣管理 嘅工作。
AboutDockerProfessional illustrations
日誌格式解析同設定
好啦，講到日誌格式解析同設定，呢部分真係管理Docker Service嘅核心，直接影響到你排查問題嘅效率。簡單嚟講，你喺Docker CLI打docker service logs睇到嘅嘢，佢嘅格式同內容，其實係由背後嘅Logging Driver（日誌驅動程序）話事嘅。喺2026年嘅今日，無論你用緊Ubuntu、CentOS呢類Linux系統，定係macOS同Windows，呢個設定概念都係相通嘅，不過具體操作同推薦嘅日誌驅動程式就可能會有啲唔同。
首先，你要明白，Docker 預設嘅日誌驅動程式通常係json-file。點解叫 JSON-file？因為佢會將你個容器或者服務產生嘅每一行日誌（包括標準輸出 stdout 同標準錯誤 stderr），以 JSON 格式嘅結構化數據寫入到宿主機嘅一個文件度。咁樣做嘅好處係，Docker daemon 同 Docker CLI（例如你用docker service logs或者docker container logs呢啲CLI命令）可以好容易咁解析同顯示返啲日誌出嚟，仲可以跟返時間戳同來源。不過，缺點就係如果個容器好嘈，不停輸出日誌，咁呢個 JSON 文件就會不斷變大，有可能食晒你磁碟空間。所以，好多有經驗嘅管理員都會設定 log rotation（日誌輪轉），例如限制文件嘅數量同大小，呢啲參數都可以喺建立服務或者更新服務嗰陣，透過命令參數嚟設定。
不過，如果你嘅系統係用緊systemd（例如新版本嘅Ubuntu、CentOS），咁強烈建議你考慮轉用journald呢個日誌驅動程式。點解呢？因為journald本身就係systemd嘅日誌系統，佢會將你所有容器日誌直接交俾系統嘅 journal 去統一管理。咁樣做有幾個大好處：第一，你可以用journalctl呢個強大嘅命令行接口工具，去統一搜尋同過濾嚟自唔同服務或者容器嘅日誌，唔使下下走去搵 Docker 嘅日誌文件；第二，佢本身已經有完善嘅輪轉同壓縮機制，唔使你自己再額外設定；第三，對於Docker Swarm呢類叢集管理環境，如果每個節點都用journald，咁你集中收集日誌（例如用 Fluentd 或者 Loki）嘅時候，架構會更加一致同簡潔。要設定用journald，你可以喺建立服務嗰陣，加--log-driver journald呢個參數，又或者直接喺 Docker daemon 嘅設定檔度指定全局嘅預設驅動程式。
講到服務日誌嘅格式解析，當你用docker service logs呢個命令嗰陣，後面加唔同嘅命令參數，出嚟嘅格式同資訊都會唔同。例如，加--details會顯示更多關於日誌來源嘅元數據，對於Swarm嘅服務嚟講，會清楚標明係邊個任務（Task）產生嘅日誌，對於任務管理同追蹤好有用。加--timestamps就會喺每一行日誌前面加返個時間戳，方便你對時序。而--tail同--follow (-f) 就係控制顯示幾多行同埋即時追蹤新日誌，呢啲都係日常服務管理必備嘅技巧。要留意嘅係，喺Docker Swarm模式下，docker service logs其實係去每個運行緊該服務任務嘅節點度收集日誌，然後彙總顯示俾你睇，所以佢背後涉及嘅係集羣管理嘅通訊。
最後，針對唔同嘅操作系統，有啲實用嘅設定貼士。例如，如果你仲用緊舊版Docker Toolbox（雖然到2026年應該好少人用啦），或者係Docker for Mac / Docker for Windows 嘅桌面版，你要留意返佢哋嘅日誌文件默認儲存位置可能同 Linux 唔同，特別係當你想直接去磁碟度清理舊日誌嘅時候。另外，對於Windows容器，佢支援嘅日誌驅動程式可能同 Linux 容器有少少差異，例如json-file同syslog都支援，但journald就唔得啦，設定前最好睇清楚官方文檔。總而言之，理解同設定好日誌驅動程式，就等於掌握咗解讀容器同服務行為嘅鎖匙，無論係做服務創建、服務更新定係日常嘅服務檢查同故障排查，都可以事半功倍。
AboutDockerProfessional illustrations
管理多個服務日誌技巧
好啦，講到管理多個服務日誌，喺 Docker Swarm 環境入面，真係同管理單一容器好唔同。你成日要同時睇住幾個、甚至幾十個服務嘅狀況，如果仲係逐個服務用 Docker CLI 嘅 docker service logs 去撈日誌，真係撈到天光都未撈完。所以，一定要有啲系統性嘅技巧，等你可以高效地監控同分析成個 叢集 嘅運作情況。
首先，你一定要識得點樣靈活運用 docker service logs 呢個 CLI命令 本身嘅參數。最基本嘅，你可以用 --follow 或者 -f 去即時追蹤日誌嘅輸出，好似睇緊直播咁。但當服務有好多個 任務（即係容器實例）嘅時候，例如你將某個服務 擴展 到 10 個副本，咁點算？呢個時候，你可以加 --tail 參數，例如 --tail 50，咁就會只顯示每個任務最近嘅 50 行日誌，唔會一次過噴幾千行出嚟嚇親你。另外，--timestamps 參數都好緊要，佢會喺每行日誌前面加返個時間戳，當你將唔同服務嘅日誌擺埋一齊分析時，呢個時間軸就係還原事件順序嘅關鍵。仲有，如果你想集中睇某個服務入面，其中一個有問題嘅任務，你可以用 --task-id 參數，直接指定睇嗰個任務嘅日誌，做精準打擊。
不過，單靠 Docker CLI 逐個指令打，對於管理大量 服務日誌 始終唔夠力。所以，設定一個統一嘅 日誌驅動程式（Logging Driver）就係基本功。喺 Docker Swarm 入面，你可以在建立服務或者更新服務嘅時候，透過 --log-driver 同 --log-opt 參數去設定。例如，喺 Ubuntu 或者 CentOS 呢類用 systemd 做初始化系統嘅 Linux 發行版上，好多人都會選用 journald 呢個驅動程式。點解？因為咁樣所有 容器日誌 就會直接交俾系統嘅 journald 去管理，之後你就可以用 journalctl 呢個強大工具，用統一嘅指令去查詢、過濾同合併所有服務同系統本身嘅日誌，管理起上嚟就一體化好多。例如，你可以用 journalctl CONTAINER_NAME=你的服務名稱 去追蹤特定容器嘅所有記錄，好方便。
當然，默認嘅 JSON-file 驅動程式都依然係個穩陣選擇，特別係喺 Windows 或者 macOS 嘅開發環境（例如 Docker for Mac 或舊版 Docker Toolbox）入面。但你要記住，JSON-file 會將日誌以 JSON 格式寫喺主機嘅檔案系統上，如果某個服務異常瘋狂輸出日誌，有可能會塞爆你嘅磁碟空間。所以，記得要用 --log-opt 去設定 max-size 同 max-file 呢類選項，例如設定每個日誌檔案最大 10MB，最多保留 5 個，咁就可以自動輪替，避免意外。
對於真正複雜嘅生產環境，我哋通常會將日誌集中化。呢個時候，你可以考慮設定 Docker daemon 本身嘅默認日誌驅動程式，或者為每個服務指定好似 syslog、fluentd、gcp 或者 awslogs 呢類第三方驅動程式。例如，你可以在建立 Swarm 服務時，用類似 docker service create --log-driver=fluentd --log-opt fluentd-address=你的 fluentd 伺服器:24224 你的鏡像 嘅指令，咁樣個服務一產生日誌，就會即時傳送去你嘅中央日誌平台（例如 ELK Stack 或 Loki），咁你就可以喺一個靚仔嘅 Web 介面度，對所有服務嘅日誌進行搜尋、篩選同可視化分析，完全唔使再登入去每部主機打命令。呢個方法對於 服務管理 同故障排查嘅效率，係幾何級數嘅提升。
最後，有個實用小貼士：善用 docker service ps 呢個命令去睇清楚你目標服務嘅所有任務同佢哋嘅狀態。搵到有問題嘅任務 ID 之後，再結合 docker service logs --task-id 去深入調查，咁就唔會喺一大堆正常日誌入面迷失。總而言之，管理 多個服務日誌 嘅核心思路，就係要「標準化」同「自動化」—— 透過統一嘅 logging driver 設定，將日誌輸出到一個集中嘅、方便檢索嘅地方，再配合 Docker CLI 嘅靈活參數做即時調查，咁你先可以真正掌控成個 Docker Swarm 集羣嘅脈搏，無論係 服務創建、服務更新 定係日常 服務檢查，都能夠心中有數。
AboutToolboxProfessional illustrations
常見錯誤日誌分析
好啦，而家我哋深入啲，講下點樣分析 Docker Service Logs 入面常見嘅錯誤日誌。作為一個 DevOps 或者系統管理員，識得睇呢啲日誌，就好似識得睇醫生張藥單一樣，可以快速診斷到個 Docker Swarm 服務究竟邊度唔舒服。好多時，你喺 Docker CLI 打 docker service logs
首先，最常見嘅一類錯誤，就係同 容器 本身嘅應用程式有關。呢啲通常唔關 Docker 事，而係你跑緊嘅程式自己出錯。例如，你可能會見到日誌話「Connection refused to database」或者「Required environment variable not set」。呢啲訊息好直接，就係話你知個應用程式連唔到資料庫，或者有環境變數未設定好。處理方法就係要檢查吓你喺建立 服務 嘅時候，用 docker service create 或者更新服務時用 docker service update 所設定嘅參數，例如 --env 或者個網絡設定係咪正確。尤其係喺 Swarm 叢集環境，服務可能被調度去唔同節點運行，你要確保每個節點嘅網絡環境或者依賴服務（如資料庫）嘅連接地址都係通用嘅。
第二類常見錯誤，就係同 Docker 本身嘅資源或者配置有關。呢度就可能會涉及 Docker daemon 嘅狀態。舉個例，你可能會見到日誌出現「no space left on device」呢句經典對白。呢個即係話，個宿主機或者 Docker 用來儲存映像同容器嘅磁碟空間已經爆滿。特別係當你個 日誌驅動程序 (Logging Driver) 設定為預設嘅 json-file，而你又冇設定日誌輪替 (log rotation) 嘅話，容器日誌好快就會食爆你個磁碟。解決方法係，你可以透過 Docker daemon 嘅設定檔（例如喺 Ubuntu 或 CentOS 上編輯 /etc/docker/daemon.json），為個 json-file 驅動程式加上 max-size 同 max-file 參數，限制單個日誌檔嘅大小同數量。又或者，考慮轉用 journald 呢個日誌驅動程式，將日誌直接交俾 systemd 嘅 journalctl 去統一管理，咁樣喺資源管理上會更加有效率。
跟住落嚟，第三類錯誤就同網絡同服務發現有關，特別係喺 Docker Swarm 模式底下。你可能會喺日誌見到「task: non-zero exit」或者係一啲關於「overlay network」嘅錯誤。呢啲通常表示，Swarm 入面某個服務嘅任務 (task) 啟動失敗，或者容器無法加入 Swarm 嘅覆蓋網絡。呢個時候，你就要用 docker service ps
最後，不得不提嘅係日誌驅動程式配置錯誤。如果你喺服務或者全域層面設定咗某個 logging driver，但係個目標系統唔支援，就會出錯。例如，你喺一個冇行 systemd 嘅舊系統上，強行設定日誌驅動程式為 journald，咁個容器就可能會啟動失敗，相關錯誤訊息會喺 docker service logs 度反映出來。又或者，你將日誌驅動程式設定為 syslog 但係個 syslog 伺服器地址打錯，咁樣所有日誌都會丟失，查起錯上嚟就會好頭痕。所以，每次更新服務配置，尤其係用 docker service update 改動 --log-driver 呢類參數時，真係要打醒十二分精神。
總而言之，分析 docker service logs 嘅錯誤，一定要有層次感。先睇吓係咪應用程式自己嘅問題，再檢查 Docker 環境同資源（磁碟、記憶體），然後排查 Swarm 嘅網絡同服務發現配置，最後確認吓個 日誌驅動程式 本身有冇設定失誤。養成呢個習慣，無論你係用緊 macOS、Windows 定係 Ubuntu 做宿主，都可以更加得心應手咁管理你嘅容器化服務同 叢集。
AboutDockerProfessional illustrations
點樣匯出同備份日誌？
好啦，講到 Docker Swarm 入面嘅服務日誌，好多 DevOps 同 SRE 團隊都會問：點樣匯出同備份日誌？ 呢個問題好實際，因為日誌唔單止用嚟即時除錯，仲係合規審計、事故回溯同數據分析嘅重要資產。喺 2026 年嘅今日，Docker Swarm 嘅 logging driver 選項更加成熟，但核心思路依然係要將日誌從容器入面「拎出嚟」，存到一個持久化同安全嘅地方。
首先，你要清楚你嘅 Docker Service 用緊咩 logging driver。呢個設定直接影響你點樣攞到日誌。最常見嘅係 json-file driver，佢會將 容器日誌 寫到宿主機嘅磁碟檔案度。如果你想匯出，可以直接喺運行緊服務嘅 Swarm 節點上，搵到對應嘅 JSON 檔案。不過，呢個方法比較原始，而且當你個 服務 喺唔同節點嘅 任務 之間飄移時，你要逐個節點去搵，好麻煩。所以，對於正式環境，我哋極少直接去宿主機抄檔案嚟做備份。
更主流同建議嘅做法，係喺建立或更新 Docker Service 嘅時候，就透過 Docker CLI 設定好個 logging driver，將日誌直接送到外部系統。例如，你可以設定用 journald（如果你嘅宿主機係用 systemd 嘅 Linux 發行版，好似 Ubuntu 或者 CentOS 新版本）。咁樣，所有 服務日誌 就會由 Docker daemon 寫入到系統嘅 journal。之後，你想匯出同備份，就可以用 journalctl 呢個 命令行接口 工具，配合一啲過濾參數，將特定服務嘅日誌導出成文字檔案。例如，你可以用命令將過去 24 小時嘅日誌 dump 出嚟，再用 cron job 自動打包同傳去雲端儲存，咁就實現咗自動化備份。
對於用緊 Windows 或者 macOS（包括 Docker for Mac）做開發嘅朋友，思路都係一樣，但工具可能唔同。雖然你唔會用 journald，但你可以設定個 logging driver 去 syslog，或者更好嘅係，直接去第三方日誌平台，好似 Loki、Elasticsearch 或者商業嘅日誌管理服務。喺 Docker Swarm 入面，你喺 docker service create 或者 docker service update 呢啲 CLI命令 度，加 --log-driver 同 --log-opt 呢啲 命令參數 就可以輕鬆做到。例如，設定日誌驅動程式為 syslog，並指定 syslog 伺服器地址，咁樣日誌一產生就會自動傳走，匯出同備份嘅責任就交咗俾後面嗰套日誌系統，唔使再擔心 容器 被刪除後日誌唔見咗。
最後，分享一個實用嘅本地備份技巧。如果你暫時未搭建外部日誌系統，又想定期將 Docker Service 嘅日誌保存低，你可以寫一個簡單嘅 Shell 腳本。個腳本會用 docker service logs 呢個命令，配合 --since 同 --tail 等參數，去拉取指定時間段內嘅日誌，然後重定向輸出到一個檔案，再壓縮同搬去備份位置。不過要留意，docker service logs 命令預設只係顯示任務嘅最新日誌，而且如果個服務已經被刪除，日誌就可能攞唔到。所以，呢個方法比較適合輔助性、短期嘅手動備份，長遠都係要設定正確嘅 日誌驅動程序，從根源上解決問題。總而言之，匯出同備份嘅關鍵，在於將日誌視為獨立於容器生命週期嘅數據流，並喺 服務管理 層面就做好導向設定，咁先至係最穩陣嘅做法。
AboutDockerProfessional illustrations
日誌輪替最佳實踐
講到日誌輪替最佳實踐，對於用 Docker 同 Docker Swarm 管理服務嘅團隊嚟講，真係一個唔可以忽視嘅課題。你諗下，如果你唔做輪替，任由容器日誌不停噉寫入，好快就會食爆你嘅磁碟空間，到時唔單止影響服務運行，連查歷史日誌都變得好麻煩。所以，設定一個穩陣嘅日誌輪替策略，係確保你嘅 Docker 服務可以長期穩定運行嘅關鍵一步。
首先，你要明嘅係，Docker 本身嘅日誌驅動程序（Logging Driver）直接影響你點樣做輪替。最常見嘅係 json-file 呢個驅動，佢預設就會將容器嘅標準輸出同標準錯誤寫到主機上嘅 JSON 檔案度。喺 2026 年嘅今日，無論你用緊 Ubuntu、CentOS 呢類 Linux 系統，定係 macOS（即係 Docker for Mac）或者 Windows，呢個都係基礎。但係，json-file 驅動預設係唔會自動輪替日誌檔嘅，呢個就係問題嘅根源。所以，最佳實踐嘅第一步，就係喺啟動容器或者配置 Docker daemon 嗰陣，就要設定好日誌嘅大小同數量上限。
點樣設定呢？你可以直接喺運行容器嘅 Docker CLI 命令度加參數。例如，用 docker run 嗰陣，加上 --log-opt max-size=10m 同 --log-opt max-file=3 呢類選項。咁樣就等於話，每個日誌檔案最大 10MB，最多保留 3 個，當第 4 個檔案產生嘅時候，最舊嗰個就會被刪除。對於 Docker Service 嚟講，道理都一樣，你喺建立或者更新服務（服務創建、服務更新）嗰陣，都可以透過 --log-opt 去設定呢啲參數。呢個方法簡單直接，尤其適合啲用 Docker Toolbox 或者簡單部署嘅情況。
不過，如果你係管理一個 Docker Swarm 叢集，咁就要考慮得更全面啲。因為服務嘅任務可能會喺唔同嘅節點上飄移，你唔能夠只係依賴單一主機上嘅檔案輪替。呢個時候，另一個最佳實踐就係考慮使用更強大嘅日誌驅動程式，例如 journald。尤其係喺用 systemd 做初始化系統嘅 Linux 發行版（好似新版本嘅 Ubuntu 同 CentOS）上面，用 journald 做 Docker 嘅 logging driver 好處多多。點解呢？因為 systemd 嘅 journalctl 工具本身已經內置咗高效嘅日誌管理同輪替機制，佢會自動壓縮同清理舊日誌，你仲可以好方便噉按時間、服務單位去篩選查閱。設定方法係修改 Docker daemon 嘅配置文件，加上 --log-driver=journald，然後重啟 daemon。咁樣一嚟，所有容器嘅日誌都會交俾系統嘅 journald 去管理，輪替嘅煩惱就少好多。
當然，有啲環境可能唔適合用 journald，例如你嘅團隊習慣直接睇日誌檔案，又或者有啲第三方工具要直接讀取 json-file。咁點算呢？呢個時候，就要結合系統層面嘅工具嚟做輪替。例如，你可以配置 Linux 嘅 logrotate 工具去定期處理 Docker 嘅日誌檔案。你要寫一個 logrotate 嘅配置文件，指定 Docker 日誌檔案嘅路徑（通常係 /var/lib/docker/containers//.log），然後設定輪替嘅條件，好似每日輪替、保留 7 日、壓縮舊檔案等等。呢個方法嘅好處係非常靈活，你可以設定到好精細，而且對所有用 json-file 驅動嘅容器日誌都生效，唔使逐個服務去設定。不過要記住，如果你已經用咗 Docker 自己嘅 max-size 同 max-file 設定，就要小心同 logrotate 嘅設定有冇衝突，最好就統一用其中一種方法，避免日誌無端端消失或者輪替混亂。
另外，對於生產環境嘅 Docker Swarm 集羣管理，我哋強烈建議將日誌收集同輪替分開處理。即係，唔好將輪替嘅責任完全交俾 Docker 主機或者單一驅動程序。真正嘅最佳實踐，係配置一個集中式嘅日誌管理系統（例如 ELK Stack 或者 Loki）。點樣做呢？你可以設定 Docker 嘅日誌驅動為例如 syslog、fluentd 或者 gelf，將日誌實時噉轉發去集中式服務。咁樣，本地嘅 Docker 容器日誌就可以設定一個比較短嘅保留期（例如只保留最近 24 小時嘅日誌檔案），甚至設定 max-file=1，純粹用嚟做緩衝同短期查詢。所有重要嘅歷史日誌就交由後端嘅日誌系統去負責儲存、索引同歸檔。呢個做法唔單止解決咗輪替問題，更重要係提升咗日誌嘅可用性同可分析性，對於做故障排查同服務監察（服務檢查）係一個巨大嘅升級。
最後，唔好忘記定期檢查同測試你嘅日誌輪替設定係咪有效。你可以用 docker info 嚟查看當前 Docker daemon 用緊咩日誌驅動，用 docker inspect 去睇某個容器或者服務嘅具體日誌配置。亦都可以手動噉用 docker service logs 或者 docker container logs 呢啲 CLI命令 去追蹤日誌輸出，感受下日誌量係點。定期模擬一下磁碟空間不足嘅情況，睇下你嘅輪替機制係咪真係會啟動，會唔會誤刪重要嘅日誌。記住，日誌輪替唔係「設定完就唔理」嘅工作，佢係你整體 服務管理 同 任務管理 嘅一部分，需要跟隨你嘅應用規模同業務需求不斷調整優化。
AboutLoggingProfessional illustrations
用第三方工具分析日誌
好啦，講咗咁耐點樣用 Docker CLI 嘅 docker service logs 同埋點樣配置 Logging Driver（日誌驅動程式）去睇 Docker Swarm 服務嘅日誌，係時候要講下進階玩法喇。當你個 Docker 叢集規模越來越大，服務數量多到數唔清，又或者日誌量多到好似瀑布咁沖落嚟嘅時候，單靠 Docker CLI 逐個服務、逐個容器咁撈 log，真係會撈到手軟兼睇到眼花。呢個時候，引入第三方日誌分析工具就唔係「錦上添花」，而係「必要生存技能」嚟㗎喇。點解呢？因為呢啲工具唔單止可以集中收集晒所有 Docker Service 同容器嘅日誌，重可以幫你做索引、搜尋、分析，甚至設定警報，令你管理成個 Swarm 集羣嘅健康狀況事半功倍。
首先，你要明白個流程係點。無論你係用緊 Docker for Mac、Docker Toolbox，定係生產環境嘅 Ubuntu 或 CentOS 伺服器，Docker daemon 本身嘅 logging driver（例如預設嘅 json-file 或者同系統整合更好嘅 journald）負責產生同儲存日誌。第三方工具嘅角色，就係要透過一個叫 log driver 或者一個輕量級嘅日誌收集器（Agent），去「訂閱」或者「追蹤」呢啲日誌流。例如，你可以直接配置你嘅 Docker Service 用 syslog、fluentd 或者 gelf 呢類非預設嘅 logging driver，將日誌直接發送到外部日誌伺服器，完全 bypass 本地嘅 json-file。不過，呢個方法對 Swarm 服務嚟講，配置起上嚟要係 服務創建 或 服務更新 嘅時候就指定好，彈性冇咁大。
更常見同靈活嘅做法，係喺每個 Swarm 節點（Node）上面，安裝一個輕量級嘅日誌收集 Agent，例如 Fluent Bit、Logstash 或者 Filebeat。呢個 Agent 就好似一個駐守喺節點上嘅哨兵，佢會持續監控 Docker daemon 產生嘅日誌文件（如果係 json-file 驅動程式）或者透過命令如 journalctl 去讀取 journald 嘅日誌（如果係 Linux 系統用咗 systemd）。佢會自動偵測新啟動嘅 容器 或者 服務任務，然後將佢哋嘅標準輸出（stdout）同標準錯誤（stderr）日誌，即係你平時用 docker service logs 睇到嗰啲，實時收集起嚟。之後，Agent 會對日誌進行初步處理，例如解析 JSON 格式、附加額外標籤（例如 服務 名稱、容器ID、所屬 Swarm 堆棧等 叢集管理 必需嘅後設資料），然後打包發送到中央日誌平台，例如 Elasticsearch、Loki 或者雲端供應商嘅日誌服務。
噉樣做有咩好處呢？第一，係集中化。你唔使再 SSH 去十幾二十部機度逐部行 docker service logs 或者 docker container logs 呢啲 CLI命令。所有嘢喺一個 Web 介面就睇得晒，仲可以用 服務 名稱、時間範圍、日誌等級等條件做閃電式搜尋。第二，係歷史分析同視覺化。好多日誌平台都可以將日誌數據同指標（Metrics）結合，讓你喺 Grafana 度整 Dashboard，一眼睇晒某個 服務 嘅錯誤率變化趨勢，或者搵出邊個容器最近成日拋出異常。對於 服務管理 同故障排查嚟講，呢個係無價嘅。第三，係警報。你可以設定規則，例如當某個關鍵字（例如「ERROR」或「Exception」）喺某段時間內出現超過特定次數，就自動發送通知去 Slack 或者 Email，等你可以主動出擊，而唔係等到客戶投訴先發現問題。
舉個具體例子，假設你個團隊用緊 Docker Swarm 管理一個網上商店嘅微服務架構，服務分散喺幾個 Ubuntu 節點上。你可以喺每個節點部署 Fluent Bit 做 Agent，配置佢去讀取 /var/lib/docker/containers//.log 呢啲 JSON-file 日誌文件。Fluent Bit 會自動將日誌發送到 Elasticsearch 叢集。之後，開發同運維人員就可以用 Kibana（Elasticsearch 嘅視覺化工具）開一個介面，直接搜尋「payment-service」呢個 服務 過去一小時嘅日誌，並且用顏色高亮顯示錯誤訊息。比起用 命令參數 如 docker service logs --since 1h payment-service 然後喺終端機密密麻麻嘅文字入面用肉眼搵錯誤，效率同體驗簡直係天淵之別。就算你係用緊 Windows Server 或者 macOS 做開發環境，同樣嘅架構概念都適用，只係日誌文件嘅路徑同收集 Agent 嘅配置可能稍有不同。
總括嚟講，當你嘅 Docker 環境從單機發展到 Swarm 集羣，日誌管理 嘅思維都要同步升級。內置嘅 docker service logs 命令對於快速、簡單嘅 任務管理 同即時偵錯依然不可或缺，但對於系統化嘅監控、合規性審計同長期趨勢分析，投資一個合適嘅第三方日誌分析方案就變得非常重要。呢個過程需要你對 Docker 嘅 logging driver 選項、日誌收集器嘅配置，以及後端存儲平台都有基本了解，但一旦設定好，佢將會成為你管理複雜 容器 化應用程式最得力的眼睛同耳朵。
About日誌驅動程序Professional illustrations
Docker Swarm 日誌管理
講到 Docker Swarm 日誌管理，我哋首先要搞清楚，同你單機玩 Docker 唔同，Swarm 係一個叢集環境，你啲服務（Service）會分散喺唔同嘅節點（Node）上面跑。所以，你唔可以再單純用 docker logs 去睇一隻容器咁簡單，因為你根本唔知個任務（Task）跑咗去邊部機。呢個時候，就要出動 Docker CLI 裏面嘅 docker service logs 呢個命令嘞。呢個命令就係 Swarm 模式嘅日誌查看神器，佢會自動幫你追蹤同彙集屬於同一個 Docker Service 嘅所有任務嘅日誌，唔使你逐個節點登入去搵，對於 服務管理 同故障排查真係方便好多。
不過，點樣先至睇得有效率、睇得精準呢？就要識得用 命令參數 啦。最基本就係 docker service logs [SERVICE_NAME]，佢會顯示嗰個服務最近嘅日誌。但成日咁樣睇會好亂，因為佢預設會跟返時間順序，但就唔會標明條日誌係來自邊個容器或者邊部主機。所以，我強烈建議你加返 --details 參數，佢會顯示更多元數據，例如服務 ID、任務 ID、容器 ID，甚至係節點名稱，等你一眼就知條日誌嘅來源。另外，--follow （或者 -f）就係即時追蹤日誌，好似 tail -f 咁，有新日誌出就會即時顯示，監察服務狀態時必用。仲有 --tail，你可以指定睇最後幾多行，例如 --tail 100 就係睇最後一百行，唔使由頭 load 晒出嚟咁論盡。
講到日誌嘅來源，就不得不提 Logging Driver（日誌驅動程序）呢個核心概念。簡單嚟講，就係你嘅 容器 入面，應用程式（例如係個 Web Server）寫日誌去 stdout（標準輸出）同 stderr（標準錯誤），咁 Docker daemon 就會用一個指定嘅 日誌驅動程式 去捕捉呢啲流，然後儲存或者轉發去第二度。喺 Swarm 環境度，每個節點嘅設定都好重要。預設嘅 logging driver 係 json-file，即係將日誌以 JSON 格式寫入主機嘅檔案系統度。呢個方法簡單，但如果你唔定期清理，好易會打爆你個硬碟。所以喺 服務創建 或者 服務更新 嘅時候，你可以用 --log-driver 同 --log-opt 參數去指定用邊種 driver 同埋佢嘅選項。
例如，如果你啲節點係行 systemd 嘅 Linux 系統（好似 Ubuntu 或者 CentOS 嘅新版本），用 journald 做 日誌驅動程序 會係個好選擇。你喺創建服務時可以咁設定：--log-driver=journald。咁樣，所有容器日誌就會交俾系統嘅 journald 去統一管理，然後你就可以用 journalctl 呢個強大工具去查閱、過濾同分析日誌，例如 journalctl CONTAINER_NAME=你的容器名，整合得非常好，對於 叢集管理 嚟講，統一嘅日誌收集點會令後續監控同分析容易好多。
至於 Windows 同 macOS 嘅朋友就要留意吓。雖然而家好少人直接用 Docker Toolbox（到 2026 年真係可以當古董啦），而係用 Docker for Mac 或者 Docker Desktop for Windows，但佢哋底層嘅日誌處理都係有分別。尤其係 macOS，佢本身冇 systemd，所以用 journald 唔係選項。通常呢類桌面開發環境，用返預設嘅 json-file 或者為咗方便開發，可能會設定將日誌推送到一個中央化嘅地方，例如 Elasticsearch 或者 Loki，咁樣就算你喺本地起咗個小型 Swarm 做測試，查日誌都可以一站式搞掂。
最後都要提提，docker service logs 呢個命令本身，其實都係透過同各節點嘅 Docker daemon 溝通，攞取返相應嘅 容器日誌。所以，如果某個節點嘅 daemon 死咗，或者網絡唔通，你就可能睇唔到該節點嘅日誌。另外，喺大規模嘅 集羣管理 場景，依賴呢個命令做即時排查可以，但要做歷史日誌分析同長期儲存，就一定要配合額外嘅日誌基礎設施，例如設定全局嘅 logging driver 去將所有日誌即時推送到好似 ELK Stack（Elasticsearch, Logstash, Kibana）或者 Grafana Loki 呢類日誌平台。總而言之，管理 Docker Swarm 嘅日誌，關鍵在於理解日誌流嘅去向，善用 docker service logs 嘅 命令行接口 參數做快速診斷，同埋根據你嘅作業系統（Windows / macOS / Ubuntu / CentOS）同生產環境需求，規劃好 日誌驅動程式 嘅策略，咁先可以確保你對服務嘅運行狀況一目了然。
AboutJSONProfessional illustrations
日誌驅動程式點揀？
好啦，講到 Docker Service 嘅日誌，好多朋友都會問：「日誌驅動程式點揀？」呢個真係一個好實際嘅問題，揀得啱，你查 log 就輕鬆自在；揀得唔好，隨時搵唔到想要嘅記錄，或者搞到部機冇晒位。喺 2026 年嘅今日，Docker 生態已經好成熟，選擇亦都多咗，我哋就一齊拆解下點樣根據你嘅環境同需求去揀。
首先，你要知你而家用緊咩 logging driver。最簡單嘅方法，就係用 Docker CLI 打 docker info 去睇，喺輸出嘅資訊入面，你會見到一行係講緊預設嘅日誌驅動程式。通常，喺唔同嘅作業系統上，Docker 會有一個預設選擇。例如，喺最新版嘅 Ubuntu 或者 CentOS 呢類 Linux 發行版上，如果系統係用 systemd 做初始化系統嘅，咁預設好大機會係 journald。咁樣做嘅好處係，所有系統同 容器 嘅日誌，都可以用同一個工具 journalctl 去統一管理同查詢，整合度高，對於習慣用 systemd 嘅管理員嚟講好方便。相反，如果你用緊 Docker for Mac 或者 Windows 嘅 Docker Desktop，又或者係一啲舊版設定，預設好可能仲係經典嘅 json-file 驅動程式。
咁 json-file 同 journald 有咩主要分別，又應該點揀呢？其實好睇你嘅管理習慣同日誌量。json-file 驅動程式會將每一個 容器 嘅標準輸出（stdout）同標準錯誤（stderr）寫入到主機磁碟上一個 JSON 格式嘅檔案度。佢嘅最大優點係簡單、直接，而且完全唔使依賴其他系統服務。你用 docker logs 或者 docker service logs 呢啲 CLI命令 去睇嘅時候，就係直接讀緊呢啲檔案。對於開發、測試，或者係細規模嘅部署，json-file 係非常直觀易明嘅選擇。不過，你要小心留意日誌輪替（log rotation）嘅設定，如果唔係，好容易就會寫爆磁碟。你可以喺 Docker daemon 嘅設定檔（daemon.json）入面，設定 max-size 同 max-file 呢類參數去控制每個日誌檔案嘅最大尺寸同保留數量。
而 journald 驅動程式，就係將容器日誌直接傳送俾系統嘅 journald 服務。呢個選擇特別適合已經全面擁抱 systemd 生態嘅 Linux 伺服器。佢嘅好處係，日誌會跟番系統日誌一齊被管理，你可以用強大嘅 journalctl 命令，配合豐富嘅過濾參數（例如按單位、按時間、按優先級）去精準搜尋 容器日誌。對於用 Docker Swarm 模式部署嘅 服務 嚟講，如果你嘅 Swarm 節點都係行 systemd，用 journald 可以讓你在每個節點上用統一方式查閱所有 任務 嘅日誌，對於 叢集管理 有一定便利性。但要注意，如果你需要將日誌收集到中央系統（例如 Elasticsearch、Loki），你可能需要額外配置 journald 嘅轉發功能，或者考慮其他更適合做日誌轉發嘅驅動程式。
除咗呢兩個常見選擇，Docker 其實仲支援其他 日誌驅動程序，例如 syslog、fluentd、gcplogs、awslogs 等等。點揀？關鍵在於你成個系統嘅日誌策略。如果你間公司已經有一套中央日誌收集系統（比如話 ELK Stack 或者 Grafana Loki），咁你直接揀用 fluentd 或者 syslog 呢類驅動程式，讓容器一產生日誌就實時轉發過去，會係最理想嘅做法。咁樣，你查日誌就唔使再登入每部主機，喺中央日誌平台就可以睇晒成個 Swarm 集群裏面所有 服務 嘅記錄，做 服務管理 同故障排查會快好多。
最後，點樣設定同更改呢？有幾個層次。如果你係想為某個特定嘅 服務 設定日誌驅動程式，你可以在建立服務嘅時候，用 docker service create 命令，加上 --log-driver 同 --log-opt 呢啲 命令參數 去指定。例如，你想用 json-file 並設定輪替，個命令可能會係 --log-driver json-file --log-opt max-size=10m --log-opt max-file=3。如果你係想更改成個 Docker 守護進程嘅預設驅動程式，就要去修改 Docker daemon 嘅設定檔（通常係 /etc/docker/daemon.json），加入 "log-driver": "journald" 呢類設定，然後重啟 Docker 服務。記住，改完 daemon 設定，只會影響之後新創建嘅容器，現有嘅容器唔會受影響。
總括嚟講，揀 日誌驅動程式 冇話邊個一定最好，最重要係睇你個環境同工作流程。本地開發用 json-file 夠簡單；全 Linux systemd 環境用 journald 整合性好；要集中式日誌分析就揀 fluentd 或 syslog。建議你喺設定前，先諗清楚日誌嘅生命週期：點樣產生、點樣儲存、點樣輪替、同最後點樣查閱。諗通呢條鏈，自然就知道點揀最適合你團隊同項目嘅 logging driver 啦。
AboutJournaldProfessional illustrations
效能監控與日誌關聯
講到效能監控，好多 DevOps 同系統管理員都會同意，淨係睇 CPU、RAM 用量係唔夠㗎，一定要同服務日誌（Service Logs）夾埋一齊分析，先至可以搵到問題嘅根源。喺 Docker Swarm 環境入面，效能監控與日誌關聯 呢個動作就更加關鍵，因為你管理緊嘅係一個分散式叢集，一個服務（Docker Service）可能由幾十個甚至幾百個任務（Tasks）組成，分佈喺唔同嘅節點上面。如果你淨係用 Docker CLI 嘅 docker service logs 命令去睇某個服務嘅輸出，雖然可以睇到所有相關容器嘅日誌流，但當你想深入調查點解某個節點嘅容器特別食 CPU，或者點解某個服務版本更新（Service Update）之後回應時間慢咗，你就需要將呢啲日誌數據，同你嘅監控系統（例如 Prometheus 收集到嘅指標）進行關聯分析。
點樣做關聯呢？首先你要理解你嘅 日誌驅動程式（Logging Driver） 點樣影響你收集同分析日誌。預設嚟講，Docker 會用 json-file driver，將容器同服務日誌寫到主機嘅 JSON 檔案度。呢個做法簡單，但對於進階嘅效能關聯分析就可能唔夠力。例如，當你喺 Ubuntu 或者 CentOS 呢類 Linux 系統上，好多時會建議轉用 journald driver。點解？因為 journald 係 systemd 系統嘅一部份，佢可以將 Docker daemon 同所有容器嘅日誌，統一收集到系統日誌度，然後你可以用 journalctl 命令，配合精確嘅時間戳記、單元名稱（unit）同優先級去查詢。呢個統一嘅時間線索，對於關聯效能事件（例如下晝三點 CPU 突然飆升）同當時嘅錯誤日誌（例如三點正有大量資料庫連線超時嘅記錄）係極之有用。你喺 Docker Swarm 設定服務嗰陣，可以用 --log-driver journald 呢個參數去指定，確保叢集裡面所有節點都用同一個日誌驅動程式，咁樣收集同分析日誌先會一致。
不過，環境唔同，設定都要變通。如果你嘅團隊用緊 macOS 做開發，行緊 Docker for Mac，或者用緊 Windows，甚至係舊版嘅 Docker Toolbox，咁就要留意番。journald 係 Linux systemd 特有嘅，所以喺 macOS 同 Windows 上唔適用。呢啲環境通常會用返預設嘅 json-file，或者係 Docker for Mac/Windows 自己提供嘅日誌整合方案。喺生產環境嘅 Docker Swarm 叢集，我哋強烈建議所有節點（Node）都使用相同嘅 Linux 發行版同 日誌驅動程式，例如全部行 Ubuntu 22.04 LTS 配 journald driver，咁樣無論你係做服務檢查（Service Inspect）、服務擴展（Service Scale），定係日常嘅 效能監控，你都可以用同一套方法（例如透過 journalctl 命令查詢特定時間段嘅日誌）去追溯問題，唔使因為系統唔同而要記幾套指令。
實際操作上，點樣將監控圖表同日誌關聯起嚟呢？假設你嘅監控告警系統通知你，某個運行住 API 服務嘅 Docker Swarm 節點，記憶體使用率喺過去十分鐘內不斷上升。你第一時間會用 Docker CLI 嘅 docker service ps <你的服務名> 去睇吓呢個服務嘅任務分佈喺邊啲節點，然後 SSH 到出事嘅節點，用 docker stats 快速睇吓邊個容器異常。跟住，關鍵步驟嚟啦：你要用 journalctl 命令去篩選出該容器喺記憶體開始上升前後嘅日誌。因為你用咗 journald driver，所以你可以咁樣查：
journalctl CONTAINER_NAME=你嘅容器名 --since "10 minutes ago"
呢個命令會列出該容器過去十分鐘所有日誌，而且 journald 記錄嘅時間戳記非常精準。你喺呢堆日誌入面，好大機會會發現相關線索，例如可能係記憶體洩漏（Memory Leak）嘅錯誤訊息、某個特定 API 請求激增導致嘅緩存問題，又或者係垃圾回收（GC）異常。將呢段日誌內容，對比你監控圖表入面記憶體上升嘅曲線，你就能夠確切咁知道係邊段程式碼或者邊個操作觸發咗效能問題。呢個就係 日誌關聯 嘅威力——將抽象的資源指標，變成具體、可追蹤嘅應用程式事件。
最後都要提一提，當你管理一個大規模 Docker Swarm 叢集時，手動逐個節點用 命令行接口（CLI） 去查日誌唔係辦法。進階嘅做法係設定一個中央日誌收集系統，例如將 日誌驅動程式 設定為 syslog、gelf 或者 fluentd，直接將所有節點上嘅 服務日誌 同 容器日誌 即時傳送到 Elasticsearch、Loki 呢類日誌平台。咁樣，你嘅監控儀表板（Dashboard）就可以直接嵌入日誌查詢功能，當你喺 Grafana 度見到某條效能曲線有異常，一 click 就可以彈出對應時間段嘅相關日誌，實現真正一體化嘅 效能監控與日誌關聯。無論你係用緊 Ubuntu、CentOS 定係其他 Linux 系統，統一嘅日誌收集策略都係有效管理 Docker Swarm 服務不可或缺嘅一環。
AboutsystemdProfessional illustrations
疑難排錯實戰案例
好啦，我哋而家就入正題，講下幾個用 Docker Service Logs 做疑難排錯嘅實戰案例。呢啲案例好多時都係資深 DevOps 工程師每日會遇到嘅麻煩嘢，特別係喺 Docker Swarm 呢類叢集管理環境入面，問題可以好錯綜複雜。第一個案例係關於日誌突然「消失」。有冇試過用 docker service logs 跟住個服務名，但係乜都睇唔到，或者只係得最近幾行，之前嘅紀錄不翼而飛？呢個好多時同個 Logging Driver，即係日誌驅動程序嘅設定有關。默認情況下，Docker 會用 json-file 呢個 driver，但佢有 size 同 file 數量限制。如果你個容器好 busy，不斷輸出 log，好快就會輪轉（rotate）咗舊嘅。所以第一時間，你要用 docker service inspect 睇清楚個服務用緊邊隻 logging driver 同佢嘅設定，例如 max-size 同 max-file 係幾多。喺 Ubuntu 或者 CentOS 呢類 Linux 系統上，好多人會轉用 journald，等日誌直接交俾 systemd 嘅 journalctl 去管理，咁樣可以用強大嘅 journalctl 指令去搜尋同過濾。但轉用 journald 之後，你就要記住，唔可以用返 docker service logs 呢個 Docker CLI 指令喇，你要用返 journalctl -u docker.service 或者直接查容器 ID 先睇到。呢個係一個好常見嘅「踩坑」位。
另一個經典實戰案例，係喺 Windows 同 macOS 開發環境嘅差異。雖然而家好少人用 Docker Toolbox，主要用 Docker for Mac 或者 Docker Desktop for Windows，但底層嘅日誌處理都有啲唔同。例如喺 macOS 上，Docker 其實係跑緊一個輕量化 Linux VM，所以日誌嘅儲存同輪轉邏輯都跟返 Linux。但如果你發現日誌量異常龐大，搞到成個 VM 硬碟爆滿，咁你就可能要深入去調整個 Docker daemon 嘅設定檔（daemon.json），入面去限制全域或者個別容器嘅日誌 driver 參數。呢個就牽涉到服務管理嘅深層知識，唔止係識打 command 咁簡單。你要識得點樣更新個 Docker daemon 設定，然後重啟個 daemon 服務，再重新部署你嘅 Docker Service。記住，喺 Swarm mode 入面，更新 daemon 設定係要逐個節點（node）去做嘅，唔可以就咁喺 manager 節點改完就當搞掂。
跟住講一個更刁鑽嘅案例，就係關於任務管理同日誌嘅關係。喺 Docker Swarm，一個 服務 下面會有多個任務（task），每個任務就係一個運行中或者曾經運行過嘅容器。當你發現某個服務嘅某個副本（replica）行為異常，你用 docker service logs SERVICE_NAME 睇到嘅日誌，其實係所有任務日誌混合埋一齊嘅 stream，喺問題排查時會好混亂。呢個時候，你要識得用 --task-id 呢個參數，或者更精準地用 docker service ps 搵出有問題嗰個任務嘅 ID，然後用 docker service logs --task-id TASK_ID 去單獨追蹤嗰個特定任務嘅日誌。呢個方法對於追查一啲間歇性出現、只發生喺某個特定副本身上嘅 bug 係極之有用。另外，有時任務會不斷失敗重啟，形成一個失敗循環，咁啲日誌就會分散喺好多個已經退出咗嘅容器度。呢個時候，你就要加埋 --details 參數，或者甚至考慮暫時將服務 scale 到 1，等問題容易重現同捕捉。
最後分享一個同網絡同時間有關嘅排錯案例。有時你睇 容器日誌，發現啲時間戳記（timestamp）唔啱，或者日誌嘅順序亂哂龍，特別係當你個應用係分佈式、跨時區嘅。呢個時候，你就要留意番 docker service logs 指令本身嘅參數，例如 --timestamps 可以幫你加上 Docker 記錄每行日誌嘅時間，而 --since 同 --until 就可以幫你篩選特定時間範圍嘅日誌，對於追查某個特定事件幾時發生同影響有幾大，係不可或缺嘅工具。另外，如果你嘅服務係用緊某啲第三方 logging driver（例如 fluentd, syslog），咁問題可能會出喺網絡延遲或者緩衝區設定度，令到日誌未能實時傳送，造成排查上嘅時間差錯覺。總括嚟講，疑難排錯從來都唔係單靠一條命令參數就搞掂，而係要你對成個 Docker 生態，由 Docker CLI、服務日誌 機制、底層 日誌驅動程式 嘅運作，到 集羣管理 嘅邏輯，都有通盤嘅理解，先可以好似偵探咁，由雜亂無章嘅日誌線索入面，還原出問題嘅真相。記住，日誌本身只係原材料，點樣解讀同串連佢哋，先係工程師嘅真正價值所在。