红联Linux门户
Linux协助

Linux进程监督

发布时刻:2018-04-24 14:01:38来历:不知道作者:hl
由于复刻了 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 的最新功用不匹配的状况。这样的问题将会不断发作,咱们需求对它进行主动化测验。
 
对装备过错的主动测验或许会影响体系安全,这是一个很大的问题,我将来或许写一篇关于这方面的独自的博客文章。