docker完全可以輕易構建使用者的應用，即為 build；
docker還可以將應用快速分發，即為 ship；
最後，docker依然有能力秒級啟動應用，即為 run。
build，ship，run，簡單的3步，分分鐘為 devops 建立了管理應用生命週期的捷徑。
應用是執行起來了，應用執行後，執行狀態相信是工程師最關心的點。這一點，docker如何幫工程師排憂解難呢？
想知道應用是否仍在執行？「docker ps」會告訴您。
想獲知應用的資源使用情況如何？「docker stats」為您呈現。
如今，docker 容器應用的日誌分析，已經是乙個獲悉應用執行邏輯的狀態，以及分析應用執行效能的不二法寶。
基於 docker 容器的日誌，已然有很多人在做；那大家是否了解 docker 容器的日誌是怎麼來的呢？如果大家還不清楚 docker 日誌的實現原理，那麼本文可以帶您窺探 docker logs 的究竟。
docker 從誕生伊始，就從未對使用者應用做出標準性規範，日誌也不例外，從未有過限制。既然如此，docker容器應用的日誌也不外乎以上兩種。第二種很好理解，依然往容器中某個日誌檔案列印；然而第一種，應用通過標準輸出（stdout）的方式列印日誌，該如何呈現給使用者？
對於日誌檔案，docker 不可能也不應該深入應用內部邏輯，截獲並接管日誌檔案內容，這只會破壞 docker 的通用性。但是對於 docker 容器內應用的標準輸出，docker 則是做了工作的。具體實現，可以參考下圖：
由於此 goroutine 繫結了整個容器內所有程序的標準輸出檔案描述符，因此容器內應用的所有標準輸出日誌，都會被 goroutine 接收。goroutine 接收到容器的標準輸出內容時，立即將這部分內容，寫入與此容器—對應的日誌檔案中，日誌檔案位於/var/lib/docker/containers/，檔名為-json.log。至此，關於容器內應用的所有標準輸出日誌資訊，已經全部被 docker daemon 接管，並重定向到與容器—對應的日誌檔案中。
日誌總是需要被使用者檢視的，docker 則通過 docker logs 命令向使用者提供日誌介面。docker logs 實現原理的本質均基於與容器一一對應的 -json.log，除了 docker logs -f 命令。
以下簡要介紹 docker logs 命令下各引數的含義：
總而言之，docker 容器日誌的處理並不會很複雜。此文閱完，日誌的來龍去脈，一清二楚。當然，您也可以做兩個實驗檢驗以上內容：
實驗是檢驗真理的唯一標準。您會發現，experiement 1 中，檢視日誌會有日誌；而experiement 2 中卻找不到 echo、cat 等命令標準輸出的日誌內容。experiement 2 做完，瞬間毀三觀，難道以上內容有差錯？可以明確告訴您沒有，那矛盾如何會存在？
docker logs 日誌原理
docker logs options container options details 顯示更多的資訊 f,follow 跟蹤日誌輸出，最後一行為當前時間戳的日誌 since string 顯示自具體某個時間或時間段的日誌 tail string 從日誌末尾顯示多少行日誌，預設是all t,ti...
docker logs 檢視docker容器日誌
通過docker logs命令可以檢視容器的日誌。docker logs f t tail 100 datacenter 命令格式 docker logs options container options details 顯示更多的資訊 f,follow 跟蹤實時日誌 since string 顯...
docker logs不顯示顏色解決
實驗室新評測日誌系統使用的是google的glog，然而上線之後發現使用docker logs輸出的日誌內容沒有顏色顯示，這對於運維檢視問題很不方便，於是便著手解決。最開始以為是glog的原因，後來docker exec到容器內部執行一段測試 之後，發現容器內部終端有顏色輸出啊 所以初步可以肯定不是...