目錄html
文章 GitHub 地址 :運維經常使用應用的日誌分割linux
在實際生產中,咱們知道哪些應用的日誌會自動分割嗎?哪些應用日誌須要咱們經過服務進行定時分割?接下來咱們來看看。nginx
日誌名稱 | 日誌描述 | 是否自動切割 | 是否須要定時切割 |
---|---|---|---|
access.log | Nginx 訪問日誌 | 否 | 是 |
error.log | Nginx 錯誤日誌 | 否 | 是 |
若是須要單獨配置網站日誌的話須要在 server 模塊添加access_log logs/djx.log ;
git
日誌名稱 | 日誌描述 | 是否自動切割 | 是否須要定時切割 |
---|---|---|---|
catalina.out | Tomcat 運行時日誌和輸出到控制檯日誌(應用) | 否 | 是 |
catalina.2019-04-28.log | Tomcat自己運行的日誌,主要是啓動和暫停的。 | 是 | 否 |
localhost_access_log.2019-04-28.txt | 訪問 Tomcat 的日誌,請求時間和資源,狀態碼都有記錄 | 是 | 否 |
localhost.2019-04-28.log | 應用初始化(listener, filter, servlet)未處理的異常最後被 Tomcat 捕獲而輸出的日誌 | 是 | 否 |
host-manager.2019-04-28.log | 放 Tomcat 的自帶的 Host Manager項目的日誌信息的 | 是 | 否 |
manager.2019-04-28.log | Tomcat 自帶 Manager項目專有的日誌文件 | 是 | 否 |
Tomcat 的日誌比較特別和有意思,我也是認真看了看才發現其中的奧祕。github
Tomcat 的 catalina.out
日誌是 不會自動切割的,因此咱們須要對它進行定時切割,重啓 Tomcat 也是不會自動切割的。redis
其它的日誌 Tomcat 是會進行自動切割的,可是會遵循這樣的一個規則:日誌隔天切割,有日誌才切割,重啓會切割:mongodb
上面內容有點繞,咱們舉幾個示例理解下。tomcat
示例1:bash
Tomcat 在 2019 年 4 月28號15.30分啓動的,有日誌文件 catalina.2019-04-28.log 等。2019 年 4月29號的第一條日誌在 2019 年 4月29號9.30分。那麼日誌切割在何時? 日誌切割是在 2019 年 4月29號9.30分。
示例2:app
Tomcat 在 2019 年 4 月28號10.30分啓動的,有日誌文件 catalina.2019-04-28.log 等。在 2019 年 4月29號3.30分重啓了 Tomcat ,可是在重啓前,Tomcat 在2019 年 4月29號3.30分當天是沒有產生日誌的,但在 2019 年 4月29號 3.50 產生了日誌。問在何時切割了日誌? Tomcat 重啓時就進行了切割。
MongoDB 的日誌咱們平時是關注的比較少,可是咱們這邊仍是作下記錄。
MongoDB 的日誌是否切割取決於 MongoDB 的配置參數。
logRotate= rename/reopen #3.0.0版中的新功能。能夠取值爲 rename 或 reopen: rename 重命名日誌文件。每次重啓都會重命名日誌文件。 reopen 按照典型的 Linux/Unix 日誌循環行爲關閉並從新打開日誌文件。使用 reopen 使用的 Linux/Unix logrotate的工具時,以免日誌的丟失。 若是指定 reopen,則還必須使用 logappend logappend= true # 當 MongoDB 實例從新啓動時,將新的日誌內容添加到現有日誌文件的末尾。若是沒有此選項,MongoDB 將備份現有日誌並建立新文件。
可是,MongoDB 的日誌默認是不會進行切割的(若是不重啓的話)。
MongoDB
日誌切割 見文章 :MongoDB 日誌切割三種方式
Redis 日誌默認也是不切割的, 重啓也不切割。 Redis 日誌在實際環境中咱們也是建議進行切割的,切割頻率能夠下降。我看到有的 Redis 日誌達到 1G,運行了2年,那麼咱們進行查找日誌就比較不方便的,因此建議 Redis 的日誌也進行切割。
咱們一般會去尋找對應的日誌切割服務,可是咱們不知道系統默認已經默認帶了一個日誌的切割服務 logrotate
。像咱們系統的日誌 /var/log/cron
、/var/log/maillog
、/var/log/messages
等等這些都是經過 logrotate
來進行切割的,咱們能夠在文件 /etc/logrotate.d/syslog
看到具體的配置。logrotate
能夠天天或者每月按週期對日誌進行自動切割和壓縮,以及經過郵件發送。logrotate
的自動切割是 經過 crond
來運行任務的。
logrotate [OPTION...] <configfile> -d, --debug # 僅僅是測試,並不作任何東西。在測試配置文件是否正確的時候可使用。 -f, --force # 指定配置文件 -m, --mail=command # 指定發送郵件的命令,替代 /bin/mail -s, --state=statefile # 指定狀態文件的路徑 ,默認路徑是 /var/lib/logrotate.status 。 -v, --verbose # 顯示 logrotate 分割信息 -l, --log=STRING # 指定日誌文件的路徑 --version # 顯示版本信息
logrotate
配置文件的位置 位於/etc/logrotate.conf
logrotate
用戶配置文件位於 /etc/logrotate.d/
logrotate
的執行狀態文件/var/lib/logrotate.status
compress # 是否經過gzip壓縮轉儲之後的日誌文件,如xxx.log-20131216.gz ;若是不須要壓縮,註釋掉就行 compresscmd # 指定壓縮的命令,默認 gzip uncompresscmd # 用於解壓縮的日誌文件的命令 默認是 gunzip compressext # 啓用壓縮的擴展名,默認 gzip 的擴展名就是 .gz。 copy # 製做日誌文件的副本,與create選項互斥。 copytruncate # 用於還在打開中的日誌文件,把當前日誌備份並截斷;是先拷貝再清空的方式,拷貝和清空之間有一個時間差,可能會丟失部分日誌數據。與create選項互斥。 create mode owner group # 在切割後,建立新的日誌文件,並指定數據的權限和全部者和所屬組。 dateext # 這個參數很重要!就是切割後的日誌文件以當前日期YYYYMMDD爲格式結尾,如xxx.log-20131216這樣,若是註釋掉,切割出來是按數字遞增,即前面說的 xxx.log-1這種格式 dateformat format_string # 指定日誌文件後綴日期格式 ifempty # 表示即便是空文件也要選擇,該選項是默認值。與 notifempty 相反 notifempty # 當日志文件爲空時,不進行輪轉,與 ifempty 相反 mailfirst # 當配置了郵件地址,指定發送最新的文件 maillast # 當配置了郵件地址,指定發送最舊的文件,(默認設置) rotate count # 日誌保留的次數, 若是該參數不寫的話,默認就是刪除以前全部的文件日誌。好比切割了200次,那麼只保留最新的180第二天志,並刪除舊的20第二天志。若是配置文件指定的是 daily,那天天切割一第二天志,就意味着保留180天日誌。 maxage count # 刪除早於 count 天的日誌,若是配置了 mail 則經過郵件發送。 daily # 天天 切割 weekly # 每週運行一次,一般在每週的第一天。 monthly # 每個月運行一次切割,一般會在該月的第一天。 yearly # 若是當前年份與上一次年份不相同,就會進行切割 nocompress # 不進行壓縮。 size size # 日誌文件達到多大就切割 olddir dir # 切割後存放的目錄 start count # 當沒有指定日期後綴,將數字做爲後綴內容,默認是從 1 開始 。能夠指定其餘數字開始。 missingok # 若是日誌丟失,不報錯繼續滾動下一個日誌 mail 112@163.com # 該參數與 rotate 是有關聯的,當超過 rotate 指定次數,文件不是刪除,而是經過郵件發送到指定位置。 prerotate # 在logrotate轉儲以前須要執行的指令 postrotate # 在logrotate轉儲以後須要執行的指令 ### 3.85 版本增長每一個小時切割 hourly # 每一個小時切割
# 文件路徑,可使用通配符。 /opt/tomcat/logs/catalina.out{ compress compressext .gz copytruncate dateext notifempty maillast rotate 180 daily size 10M olddir /opt/logs/tomcat missingok mail 888888@qq.com # 若是咱們本地沒有配置好發送郵件配置的話是發送不了郵件的。 }
logrotate -d -f /etc/logrotate.d/tomcat # 測試配置文件是否配置正常 logrotate -f /etc/logrotate.d/tomcat # 馬上切割文件,能夠將該命令放到定時任務中實現定時切割
當咱們設置好日誌按日進行切割的時候,具體的執行時間是在何時呢?咱們不要覺得是會在 24.00 的時候進行切割的,它進行切割的時間是隨機的。這個隨機值取決於
crond
服務的,最終會取決於文件/etc/anacrontab
,[root@localhost ~]# cat /etc/anacrontab # /etc/anacrontab: configuration file for anacron # See anacron(8) and anacrontab(5) for details. SHELL=/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root # the maximal random delay added to the base delay of the jobs # 延遲時間 RANDOM_DELAY=45 # the jobs will be started during the following hours only 執行時間段 START_HOURS_RANGE=3-22 #period in days delay in minutes job-identifier command 1 5 cron.daily nice run-parts /etc/cron.daily 7 25 cron.weekly nice run-parts /etc/cron.weekly @monthly 45 cron.monthly nice run-parts /etc/cron.monthly咱們能夠發現 定時任務是會在 3-22點的5分-45分裏面進行日誌切割。
生產環境中該如何定時日誌分割
咱們在實際的生產環境中,咱們一般會進行按日進行日誌分割,也就是咱們但願在 24.00 進行前一天的日誌分割,咱們能夠經過
crond
服務進行定時切割 (logrotate -f /etc/logrotate.d/tomcat ), 可是咱們一般在不少應用中會有定時任務在 24.00進行執行,那個時間段也就會產生大量的日誌,若是咱們在此時切割,那麼咱們可能會致使比較多的重要的日誌丟失(而且此時任務多,資源消耗多,切割也慢),那麼咱們建議先諮詢開發,24.00 是否有大量定時任務,咱們能夠在 24.00以前幾分鐘或者以後幾分鐘 進行切割。這樣就避免大量的日誌丟失。
示例:Nginx
日誌保存在 /opt/nginx/logs/
,包含日誌 access.log
和 error.log
。
/opt/nginx/logs/* { compress compressext .gz copytruncate dateext notifempty maillast rotate 180 daily size 10M olddir /opt/logs/nginx missingok mail 888888@qq.com # 若是咱們本地沒有配置好發送郵件配置的話是發送不了郵件的。 }
示例:Tomcat
日誌保存在 /opt/tomcat/logs/
,包含日誌 catalina.out
,其餘日誌會自動切割。
/opt/tomcat/logs/catalina.out{ compress compressext .gz copytruncate dateext notifempty maillast rotate 180 daily size 10M olddir /opt/logs/tomcat missingok mail 888888@qq.com # 若是咱們本地沒有配置好發送郵件配置的話是發送不了郵件的。 }