在 Linux 中使用日誌來排錯
人們建立日誌的主要原因是排錯。通常你會診斷為什麼問題發生在你的 Linux 系統或應用程式中。錯誤資訊或一系列的事件可以給你提供找出根本原因的線索,說明問題是如何發生的,並指出如何解決它。這裡有幾個使用日誌來解決的樣例。
登入失敗原因
如果你想檢查你的系統是否安全,你可以在驗證日誌中檢查登入失敗的和登入成功但可疑的使用者。當有人透過不正當或無效的憑據來登入時會出現認證失敗,這通常發生在使用 SSH 進行遠端登入或 su 到本地其他使用者來進行訪問權時。這些是由插入式驗證模組(PAM)來記錄的。在你的日誌中會看到像 Failed password 和 user unknown 這樣的字串。而成功認證記錄則會包括像 Accepted password 和 session opened 這樣的字串。
失敗的例子:
pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.2.2
Failed password for invalid user hoover from 10.0.2.2 port 4791 ssh2
pam_unix(sshd:auth): check pass; user unknown
PAM service(sshd) ignoring max retries; 6 > 3
成功的例子:
Accepted password for hoover from 10.0.2.2 port 4792 ssh2
pam_unix(sshd:session): session opened for user hoover by (uid=0)
pam_unix(sshd:session): session closed for user hoover
你可以使用 grep 來查詢哪些使用者失敗登入的次數最多。這些都是潛在的攻擊者正在嘗試和訪問失敗的賬戶。這是一個在 ubuntu 系統上的例子。
$ grep "invalid user" /var/log/auth.log | cut -d ' ' -f 10 | sort | uniq -c | sort -nr
23 oracle
18 postgres
17 nagios
10 zabbix
6 test
由於沒有標準格式,所以你需要為每個應用程式的日誌使用不同的命令。日誌管理系統,可以自動分析日誌,將它們有效的歸類,幫助你提取關鍵字,如使用者名稱。
日誌管理系統可以使用自動解析功能從 Linux 日誌中提取使用者名稱。這使你可以看到使用者的資訊,並能透過點選過濾。在下面這個例子中,我們可以看到,root 使用者登入了 2700 次之多,因為我們篩選的日誌僅顯示 root 使用者的嘗試登入記錄。
日誌管理系統也可以讓你以時間為做座標軸的圖表來檢視,使你更容易發現異常。如果有人在幾分鐘內登入失敗一次或兩次,它可能是一個真正的使用者而忘記了密碼。但是,如果有幾百個失敗的登入並且使用的都是不同的使用者名稱,它更可能是在試圖攻擊系統。在這裡,你可以看到在3月12日,有人試圖登入 Nagios 幾百次。這顯然不是一個合法的系統使用者。
重啟的原因
有時候,一臺伺服器由於系統崩潰或重啟而當機。你怎麼知道它何時發生,是誰做的?
關機命令
如果有人手動執行 shutdown 命令,你可以在驗證日誌檔案中看到它。在這裡,你可以看到,有人從 IP 50.0.134.125 上作為 ubuntu 的使用者遠端登入了,然後關閉了系統。
Mar 19 18:36:41 ip-172-31-11-231 sshd[23437]: Accepted publickey for ubuntu from 50.0.134.125 port 52538 ssh
Mar 19 18:36:41 ip-172-31-11-231 23437]:sshd[ pam_unix(sshd:session): session opened for user ubuntu by (uid=0)
Mar 19 18:37:09 ip-172-31-11-231 sudo: ubuntu : TTY=pts/1 ; PWD=/home/ubuntu ; USER=root ; COMMAND=/sbin/shutdown -r now
核心初始化
如果你想看看伺服器重新啟動的所有原因(包括崩潰),你可以從核心初始化日誌中尋找。你需要搜尋核心類(kernel)和 cpu 初始化(Initializing)的資訊。
Mar 19 18:39:30 ip-172-31-11-231 kernel: [ 0.000000] Initializing cgroup subsys cpuset
Mar 19 18:39:30 ip-172-31-11-231 kernel: [ 0.000000] Initializing cgroup subsys cpu
Mar 19 18:39:30 ip-172-31-11-231 kernel: [ 0.000000] Linux version 3.8.0-44-generic (buildd@tipua) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #66~precise1-Ubuntu SMP Tue Jul 15 04:01:04 UTC 2014 (Ubuntu 3.8.0-44.66~precise1-generic 3.8.13.25)
檢測記憶體問題
有很多原因可能導致伺服器崩潰,但一個常見的原因是記憶體用盡。
當你係統的記憶體不足時,程式會被殺死,通常會殺死使用最多資源的程式。當系統使用了所有記憶體,而新的或現有的程式試圖使用更多的記憶體時就會出現錯誤。在你的日誌檔案查詢像 Out of Memory 這樣的字串或類似 kill 這樣的核心警告資訊。這些資訊表明系統故意殺死程式或應用程式,而不是允許程式崩潰。
例如:
[33238.178288] Out of memory: Kill process 6230 (firefox) score 53 or sacrifice child
[29923450.995084] select 5230 (docker), adj 0, size 708, to kill
你可以使用像 grep 這樣的工具找到這些日誌。這個例子是在 ubuntu 中:
$ grep “Out of memory” /var/log/syslog
[33238.178288] Out of memory: Kill process 6230 (firefox) score 53 or sacrifice child
請記住,grep 也要使用記憶體,所以只是執行 grep 也可能導致記憶體不足的錯誤。這是另一個你應該中央化儲存日誌的原因!
定時任務錯誤日誌
cron 守護程式是一個排程器,可以在指定的日期和時間執行程式。如果程式執行失敗或無法完成,那麼 cron 的錯誤出現在你的日誌檔案中。具體取決於你的發行版,你可以在 /var/log/cron,/var/log/messages,和 /var/log/syslog 幾個位置找到這個日誌。cron 任務失敗原因有很多。通常情況下,問題出在程式中而不是 cron 守護程式本身。
預設情況下,cron 任務的輸出會透過 postfix 傳送電子郵件。這是一個顯示了該郵件已經傳送的日誌。不幸的是,你不能在這裡看到郵件的內容。
Mar 13 16:35:01 PSQ110 postfix/pickup[15158]: C3EDC5800B4: uid=1001 from=<hoover>
Mar 13 16:35:01 PSQ110 postfix/cleanup[15727]: C3EDC5800B4: message-id=<20150310110501.C3EDC5800B4@PSQ110>
Mar 13 16:35:01 PSQ110 postfix/qmgr[15159]: C3EDC5800B4: from=<hoover@loggly.com>, size=607, nrcpt=1 (queue active)
Mar 13 16:35:05 PSQ110 postfix/smtp[15729]: C3EDC5800B4: to=<hoover@loggly.com>, relay=gmail-smtp-in.l.google.com[74.125.130.26]:25, delay=4.1, delays=0.26/0/2.2/1.7, dsn=2.0.0, status=sent (250 2.0.0 OK 1425985505 f16si501651pdj.5 - gsmtp)
你可以考慮將 cron 的標準輸出記錄到日誌中,以幫助你定位問題。這是一個你怎樣使用 logger 命令重定向 cron 標準輸出到 syslog的例子。用你的指令碼來代替 echo 命令,helloCron 可以設定為任何你想要的應用程式的名字。
*/5 * * * * echo ‘Hello World’ 2>&1 | /usr/bin/logger -t helloCron
它建立的日誌條目:
Apr 28 22:20:01 ip-172-31-11-231 CRON[15296]: (ubuntu) CMD (echo 'Hello World!' 2>&1 | /usr/bin/logger -t helloCron)
Apr 28 22:20:01 ip-172-31-11-231 helloCron: Hello World!
每個 cron 任務將根據任務的具體型別以及如何輸出資料來記錄不同的日誌。
希望在日誌中有問題根源的線索,也可以根據需要新增額外的日誌記錄。
via: http://www.loggly.com/ultimate-guide/logging/troubleshooting-with-linux-logs/
作者:Jason Skowronski 作者:Amy Echeverri 作者:Sadequl Hussain 譯者:strugglingyouth 校對:wxy
相關文章
- 在Linux中,如何使用logrotate命令管理日誌檔案?Linuxlogrotate
- 在Linux中,如何使用ELK進行日誌管理和分析?Linux
- 在Linux中,如何檢視系統日誌?Linux
- 在Linux中,有哪些日誌管理和分析工具?Linux
- 在Linux中,有哪些系統日誌檔案?Linux
- mysql之 日誌體系(錯誤日誌、查詢日誌、二進位制日誌、事務日誌、中繼日誌)MySql中繼
- 在thinkjs3中使用自定義日誌來滿足專案需求JSS3
- mysql 日誌之錯誤日誌MySql
- MySQL資料庫中的日誌檔案---(1)錯誤日誌MySql資料庫
- 在Linux中,如何管理和最佳化日誌檔案?Linux
- 在Hibernate中開啟日誌
- 如何在 Linux 中管理日誌Linux
- 華納雲:linux系統中如何查詢oracle錯誤日誌LinuxOracle
- 大家來做linux除錯日誌 (tomcat jsp server 配置方法) (轉)Linux除錯TomcatJSServer
- 使用logrotate來壓縮日誌(轉)logrotate
- 在Linux中,日誌檔案通常儲存在哪些目錄?Linux
- 在Linux中,有一堆日誌檔案,如何刪除7天前的日誌檔案?Linux
- Apche日誌系列(2):錯誤日誌(轉)
- Linux日誌Linux
- 使用logrotate 管理Linux日誌檔logrotateLinux
- 排查錯誤日誌
- 日誌與除錯除錯
- 在Linux中,日誌檔案作用是什麼及如何檢視?Linux
- 檢查Linux系統日誌error和mysql錯誤日誌的指令碼薦LinuxErrorMySql指令碼
- 使用 logzero 在 Python 中進行簡單日誌記錄Python
- 在oracle中Logmnr進行日誌挖掘Oracle
- alert日誌中的兩種ORA錯誤分析
- Data guard 中 alert 日誌報錯 "FAL archive failed"HiveAI
- 關閉Druid中某些錯誤日誌列印UI
- 使用logrotate 管理Linux日誌檔(zt)logrotateLinux
- linux日誌管理Linux
- Mabatis配置錯誤日誌BAT
- net 日誌分析錯誤
- 日誌查詢錯誤
- 錯誤日誌檢視
- Android除錯----日誌Android除錯
- SQL Server 錯誤日誌SQLServer
- hpux的報錯日誌UX