對進程的監視

由於復刻了 mon 項目到 etbemon 中，我花了一些時間做監視腳本。事實上監視一些事情通常很容易，但是決定監視什麼才是困難的部分。進程監視腳本 ps.monitor 是我重新設計過的一個。

對於進程監視我有一些思路。如果你對進程監視如何做的更好有任何建議，請通過評論區告訴我。

給不使用 mon 的人介紹一下，如果一切 OK 該監視腳本就返回 0，而如果有問題它會返回 1，並使用標準輸出顯示錯誤信息。雖然我並不知道有誰將 mon 腳本掛進一個不同的監視系統中，但是，那樣做其實很容易實現。我計划去做的一件事情就是，將來實現 mon 和其它的監視系統如 Nagios 之間的互操作性。

基本監視

ps.monitor tor:1-1 master:1-2 auditd:1-1 cron:1-5 rsyslogd:1-1 dbus-daemon:1- sshd:1- watchdog:1-2

我現在計劃重寫該進程監視腳本的某些部分。現在的功能是在命令行上列出進程名字，它包含了要監視的進程的最小和最大實例數量。上面的示例是一個監視的配置。在這裡有一些限制，在這個實例中的 master 進程指的是 Postfix 的主進程，但是其它的守護進程使用了相同的進程名（這是那些錯誤的名字之一，因為它太直白了）。一個顯而易見的解決方案是，給一個指定完整路徑的選項，這樣，那個 /usr/lib/postfix/sbin/master 就可以與其它命名為 master 的程序區分開了。

下一個問題是那些可能以多個用戶身份運行的進程。比如 sshd，它有一個以 root 身份運行的單獨的進程去接受新的連接請求，以及在每個登入用戶的 UID 下運行的進程。因此，作為 root 用戶運行的 sshd 進程的數量將比 root 登錄會話的數量大 1。這意味著如果一個系統管理員直接以 root 身份通過 ssh 登入系統（這是有爭議的，但它不是本文的主題—— 只是有些人需要這樣做，所以我們必須支持這種情形），然後 master 進程崩潰了（或者系統管理員意外或者故意殺死了它），這時對於該進程丟失並不會產生警報。當然正確的做法是監視 22 號埠，查找字元串 SSH-2.0-OpenSSH_。有時候，守護進程的多個實例運行在需要單獨監視的不同 UID 下面。因此，我們需要通過 UID 監視進程的能力。

在許多情形中，進程監視可以被替換為對服務埠的監視。因此，如果在 25 號埠上監視，那麼有可能意味著，Postfix 的 master 在運行著，不用去理會其它的 master 進程。但是對於我而言，我可以在方便地進行多個監視，如果我得到一個關於無法向一個伺服器發送郵件的 Jabber 消息，我可以通過這個來自伺服器的 Jabber 消息斷定 master 沒有運行，而不需要挨個查找才能發現問題所在。

SE Linux

我想要的一個功能就是，監視進程的 SE Linux 上下文，就像監視 UID 一樣。雖然我對為其它安全系統編寫一個測試不感興趣，但是，我很樂意將別人寫好的代碼包含進去。因此，不管我做什麼，都希望它能與多個安全系統一起靈活地工作。

短暫進程

大多數守護進程在進程啟動期間都有一個相同名字的 次級進程 second process 。這意味著如果你為了精確地監視一個進程的一個實例，當 logrotate 或者類似的守護進程重啟時，你或許會收到一個警報說有兩個進程運行。如果在重啟期間，恰好在一個錯誤的時間進行檢查，你也或許會收到一個警報說，有 0 個實例。我現在處理這種情況的方法是，在與 alertafter 2 指令一起的次級進程失敗事件之前我的伺服器不發出警報。當監視處於一個失敗的狀態時，failure_interval 指令允許指定檢查的時間間隔，將其設置為一個較低值時，意味著在等待一個次級進程失敗結果時並不會使提示延遲太多。

為處理這種情況，我考慮讓 ps.monitor 腳本在一個指定的延遲後再次進行自動檢查。我認為使用一個單個參數的監視腳本來解決這個問題比起使用兩個配置指令的 mon 要好一些。

CPU 使用

mon 現在有一個 loadavg.monitor 腳本，它用於檢查平均負載。但是它並不能捕獲一個單個進程使用了太多的 CPU 時間而沒有使系統平均負載上升的情況。同樣，也沒有捕獲一個渴望獲得 CPU 的進程進入沉默（例如，SETI at Home 停止運行）（LCTT 譯註：SETI，由加州大學伯克利分校創建的一項利用全球的聯網計算機的空閑計算資源來搜尋地外文明的科學實驗計劃），而其它的進程進入一個無限循環狀態的情況。解決這種問題的一個方法是，讓 ps.monitor 腳本也配置另外的一個選項去監視 CPU 的使用，但是這也可能會讓人產生迷惑。另外的選擇是，使用一個獨立的腳本，它用來報警任何在它的生命周期或者最後幾秒中，使用 CPU 時間超過指定百分比的進程，除非它在一個豁免這種檢查的進程或用戶的白名單中。或者每個普通用戶都應該豁免這種檢查，因為你壓根就不知道他們什麼時候運行一個文件壓縮程序。也應該有一個包含排除的守護進程（像 BOINC）和系統進程（像 gzip，有幾個定時任務會運行它）的簡短列表。

對例外的監視

一個常見的編程錯誤是在 setgid() 之前調用 setuid()，這意味著那個程序沒有許可權去調用 setgid()。如果沒有檢查返回代碼（而犯這種低級錯誤的人往往不會去檢查返回代碼），那麼進程會保持較高的許可權。檢查以 GID 0 而不是 UID 0 運行的進程是很方便的。順利說一下，對一個 Debian/Testing 工作站運行的一個快速檢查顯示，一個使用 GID 0 的進程並沒有獲得較高的許可權，但是可以使用一個 chmod 770 命令去改變它。

在一個 SE Linux 系統上，應該只有一個進程與 init_t 域一起運行。目前在運行守護進程（比如，mysqld 和 tor）的 Debian Stretch 系統中，並不會發生策略與守護進程服務文件所請求的 systemd 的最新功能不匹配的情況。這樣的問題將會不斷發生，我們需要對它進行自動化測試。

對配置錯誤的自動測試可能會影響系統安全，這是一個很大的問題，我將來或許寫一篇關於這方面的單獨的博客文章。

via: https://etbe.coker.com.au/2017/09/28/process-monitoring/

作者：Andrew 譯者：qhwdw 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive