Linux服务管理工具介绍
Linux系统中服务管理可以使用系统自身的服务管理工具(Systemctl),也可以使用像Supervisor这样的工具进行管理。该文档对linux系统自身的服务管理工具和Supervisor进行介绍,从常用功能、使用说明等方面进行介绍,并尝试从几个方面对这常见的几种管理工具信息对比分析。
Linux系统自身的服务管理常见的有两种服务service和systemd,CentOS 7.x开始,CentOS开始使用systemd服务来代替service,原来管理系统启动和管理系统服务的相关命令全部由systemctl命令来代替,下表是两种命令的简单对比:
daemon命令 |
systemctl命令 |
说明 |
service [服务] start |
systemctl start [unit type] |
启动服务 |
service [服务] stop |
systemctl stop [unit type] |
停止服务 |
service [服务] restart |
systemctl restart [unit type] |
重启服务 |
注:deamon可以认为等同于service
1. Service
1.1 System V系统服务的管理方式
早起的linux系统服务的管理方式被称为 SysV ,特点是系统核心第一支呼叫的程序是 init , 然后 init 去唤起所有的系统所需要的服务,不论是本地服务还是网络服务。系统启动的基本流程如下图:
这种管理方式有几个特点:
1.1.1 服务监控方式
所有的服务启动脚本通通放置于 /etc/init.d/ 底下,基本上都是使用 bash shell script 所写成的脚本程序,需要启动、关闭、重新启动、观察状态时, 可以使用service命令进行,下表是命令使用示例:
service命令 |
/etc/init.d/执行 |
说明 |
service [服务] start |
/etc/init.d/[服务脚本] start |
启动 |
service [服务] stop |
/etc/init.d/[服务脚本]stop |
停止 |
service [服务] restart |
/etc/init.d/[服务脚本] restart |
重启 |
service [服务] status |
/etc/init.d/[服务脚本] status |
状态观察 |
1.1.2 服务启动分类
init 服务的分类中,依据服务是独立启动或被总管程序管理着而分为两大类:
独立启动模式 (stand alone):服务独立启动,该服务直接常驻于内存中,提供本机或用户的服务行为,反应速度快。
总管程序 (super daemon):由特殊的 xinetd 或 inetd 这两个总管程序提供 socket 对应或 port 对应的管理。当没有用户要求某 socket 或 port 时, 所需要的服务是不会被启动的。若有用户要求时,xinetd 总管(又被称为 super daemon)才会去唤醒相对应的服务程序。当该要求结束时,这个服务也会被结束掉。这中服务启动方式的好处是可以透过 super daemon 来进行服务的时程、联机需求等的控制,缺点是唤醒服务需要一点时间的延迟。
1.1.3 执行等级
init 是开机后核心主动呼叫的, 然后 init 可以根据用户自定义的执行等级 (runlevel) 来唤醒不同的服务。基本上 Linux 提供 7 个执行等级,分别是 0, 1, 2...6 。而各个执行等级的启动脚本是透过 /etc/rc.d/rc[0-6]/SXXdaemon 连结到 /etc/init.d/daemon , 连结档名 (SXXdaemon) 的功能为: S 为启动该服务,XX 是数字,为启动的顺序。由于有 SXX 的设定,因此在开机时可以『依序执行』所有需要的服务。
若要建立SXXdaemon 的话, 透过如下的指令可以来处理默认启动、预设不启动、观察预设启动否的行为:
n 预设要启动: chkconfig daemon on
n 预设不启动: chkconfig daemon off
n 观察预设为启动否: chkconfig --list daemon
1.1 管理指令
常用的service管理指令如下
service 服务名 [start | stop | restart | reload | status]
1.2 编写init.d启动脚本
下面以一个Nginx的启动脚本编写说明如何将服务交个service进行管理;
1.2.1 新建脚本
新建一个脚本,脚本名称为nginx , 脚本内容如下:
#! /bin/sh # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: starts the nginx web server PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin DESC="nginx daemon" NAME=nginx DAEMON=/usr/local/nginx/sbin/$NAME CONFIGFILE=/usr/local/nginx/conf/$NAME.conf PIDFILE=/usr/local/nginx/logs/$NAME.pid SCRIPTNAME=/etc/init.d/$NAME set -e [ -x "$DAEMON" ] || exit 0 do_start() { $DAEMON -c $CONFIGFILE || echo -n "nginx already running" } do_stop() { kill -INT `cat $PIDFILE` || echo -n "nginx not running" } do_reload() { kill -HUP `cat $PIDFILE` || echo -n "nginx can't reload" } case "$1" in start) echo -n "Starting $DESC: $NAME" do_start echo "." ;; stop) echo -n "Stopping $DESC: $NAME" do_stop echo "." ;; reload|graceful) echo -n "Reloading $DESC configuration..." do_reload echo "." ;; restart) echo -n "Restarting $DESC: $NAME" do_stop do_start echo "." ;; *) echo "Usage: $SCRIPTNAME {start|stop|reload|restart}" >&2 exit 3 ;; esac exit 0 |
1.1.1 复制脚本到init.d目录
将脚本复制到/etc/init.d目录下,复制后的目录结构为/etc/init.d/nginx
1.1.2 设置开机自启
可以使用下面的命令,设置Nginx服务开机自启。
chkconfig --add nginx
chkconfig --level nginx 2345 on
1.1.3 通过service管理
完成上面步骤后,就可以通过service命令控制Nginx服务,常用命令如下:
/etc/init.d/nginx start 命令启动nginx
/etc/init.d/nginx stop 命令停止nginx
/etc/init.d/nginx restart 命令重启nginx
2. Systemd
CentOS 7.x开始,CentOS开始使用systemd服务来代替daemon,原来管理系统启动和管理系统服务的相关命令全部由systemctl命令来代替。systemd 将过去daemon 执行脚本通通称为一个服务单位 (unit),而每种服务单位依据功能分类为不同的类型 (type)。基本的类型包括系统服务、数据监听与交换的插槽档服务 (socket)、储存系统状态的快照类型、提供不同类似执行等级分类的操作环境 (target) 等等。
2.1 配置文件放置位置
服务的配置文件按照启动优先级,主要放置在一下几个位置中:
/usr/lib/systemd/system/ |
每个服务最主要的启动脚本设定,有点类似以前的 /etc/init.d 底下的文件 |
/run/systemd/system/ |
系统执行过程中所产生的服务脚本,这些脚本的优先序要比 /usr/lib/systemd/system/ 高 |
/etc/systemd/system/ |
管理员依据主机系统的需求所建立的执行脚本,执行优先序又比 /run/systemd/system/ 高 |
系统开机执行某些服务其实是看 /etc/systemd/system/ 底下的设定,该目录底下是连结档。而实际执行的 systemd 启动脚本配置文件, 其实都是放置在 /usr/lib/systemd/system/ 底下。
CentOS 7.x以前,如果想要建立系统服务,就得要到 /etc/init.d/ 底下去建立相对应的 bash shell script 来处理。 CentOS 7.x以后,服务的管理是透过 systemd,而 systemd 的配置文件大部分放置于/usr/lib/systemd/system/ 目录内。但是 Red Hat 官方文件指出, 该目录的文件主要是原本软件所提供的设定,建议不要修改!而要修改的位置应该放置于 /etc/systemd/system/ 目录内。
1.1 服务分类
/usr/lib/systemd/system/ 以下的数据按扩展名区分不同的类型 (type)。常见的 systemd 的服务类型:
扩展名 |
主要服务功能 |
.service |
一般服务类型 (service unit):主要是系统服务,包括服务器本身所需要的本地服务以及网络服务。经常被使用到的服务大多是这种类型; |
.socket |
内部程序数据交换的插槽服务 (socket unit):主要是 IPC (Inter-process communication) 的传输讯息插槽文件 (socket file) 功能。 这种类型的服务通常在监控讯息传递的插槽文件,当有透过此插槽文件传递讯息来说要链接服务时,就依据当时的状态将该用户的要求传送到对应的 daemon, 若 daemon 尚未启动,则启动该daemon 后再传送用户的要求。 使用 socket 类型的服务一般是不经常被用到的服务,因此在开机时通常会稍微延迟启动的时间。常用于本地服务,例如我们的图形界面很多的软件都是透过 socket 来进行本机程序数据交换的行为。 |
.target |
执行环境类型 (target unit):其实是unit 的集合,例如 multi-user.target 其实就是若干个服务的集合。也就是说,选择执行 multi-user.target 就是执行其他 若干个.service 或.socket之类的服务。 |
.mount .automount |
文件系统挂载相关的服务 (automount unit / mount unit):例如来自网络的自动挂载、NFS 文件系统挂载等与文件系统相关性较高的程序管理。 |
.path |
侦测特定文件或目录类型 (path unit):某些服务需要侦测某些特定的目录来提供队列服务,例如最常见的打印服务,就是透过侦测打印队列目录来启动打印功能。 |
.timer |
循环执行的服务 (timer unit):有点类似anacrontab。不过是由systemd 主动提供的,比 anacrontab 更加有弹性。 |
1.2 配置文件编写
1.2.1 配置文件结构
配置文件大概能够将整个设置分为三个部份,下面是三个部分的介绍:
l [Unit]:unit 本身的说明,以及与其他相依 daemon 的设定,包括在什么服务之后才启动此 unit 之类的设定值,即这个项目与此 unit 的解释、执行服务相依性有关;
l [Service], [Socket], [Timer], [Mount], [Path]..:不同的 unit type 就得要使用相对应的设定项目。本文使用 [Service] 来设定。 这个项目内主要在规范服务启动的脚本、环境配置文件档名、重新启动的方式等等。即这个项目与实际执行的指令参数有关。
l [Install]:这个项目就是将此 unit 安装到哪个 target 里面去的意思!即这个项目说明此 unit 要挂载哪个 target 底下。
下面对三个部分的配置项进行详细说明:
1.2.1.1 UNIT部分
设定参数 |
参数意义说明 |
Description |
当使用 systemctl list-units或systemctl status时,会输出到命令行的简易说明。 |
Documentation |
提供管理员能够进行进一步的文件查询的功能。提供的文件可以是如下的资料:
|
After |
说明此 unit 是在哪个 daemon 启动之后才启动。基本上仅是说明服务启动的顺序而已,并没有强制要求里头的服务一定要启动后此 unit 才能启动。 |
Before |
与 After 的意义相反,是在什么服务启动前最好启动这个服务的意思。不过这仅是规范服务启动的顺序,并非强制要求的意思。 |
Requires |
明确的定义此 unit 需要在哪个 daemon 启动后才能够启动。如果在此项设定的前导服务没有启动,那么此 unit 就不会被启动。 |
Wants |
与 Requires 刚好相反,规范的是这个 unit 之后最好还要启动什么服务。不过,并没有明确的规范,主要的目的是希望建立让使用者比较好操作的环境。 因此,这个 Wants后面接的服务如果没有启动,其实不会影响到这个 unit 本身。 |
Conflicts |
代表冲突的服务。亦即这个项目后面接的服务如果启动,那么当前这个 unit 本身就不能启动。 |
1.2.1.2 [Service] 部份
设定参数 |
参数意义说明 |
Type |
说明这个 daemon 启动的方式,会影响到ExecStart。一般来说,有以下几种类型:
|
EnvironmentFile |
可以指定启动脚本的环境配置文件。例如 sshd.service 的配置文件写入到 /etc/sysconfig/sshd 当中。你也可以使用 Environment= 后面接多个不同的 Shell 变量来给予设定。 |
ExecStart |
实际执行此 daemon 的指令或脚本程序。也可以使用 ExecStartPre (之前) 以及ExecStartPost (之后) 两个设定项目来在实际启动服务前,进行额外的指令行为。特别注意的是,指令串仅接受『指令 参数 参数...』的格式,不能接受 <, >, >>, |, & 等特殊字符,很多的 bash 语法也不支持。 所以,要使用这些特殊的字符时,最好直接写入到指令脚本里面去。不过,上述的语法也不是完全不能用,亦即,若要支持比较完整的 bash 语法,需要使用 Type=oneshot 才行, 其他的 Type不能支持这些字符。 |
ExecStop |
与 systemctl stop 的执行有关,关闭此服务时所进行的指令。 |
ExecReload |
与 systemctl reload 有关的指令行为 |
Restart |
当设定 Restart=1 时,则当此 daemon 服务终止后,会再次的启动此服务。除非使用 systemctl 强制将此服务关闭,否则这个服务会源一直重复启动。 |
RemainAfterExit |
当设定为 RemainAfterExit=1 时,则当这个 daemon 所属的所有程序都终止之后,此服务会再尝试启动。 |
TimeoutSec |
若这个服务在启动或者是关闭时,因为某些缘故导致无法顺利『正常启动或正常结束』的情况下,要等多久才进入『强制结束』的状态。 |
KillMode |
可以是 process, control-group, none 的其中一种,如果是 process 则 daemon 终止时,只会终止主要的程序 (ExecStart 接的后面那串指令),如果是 control-group 时, 则由此 daemon 所产生的其他 control-group 的程序,也都会被关闭。如果是 none 的话,则没有程序会被关闭。 |
RestartSec |
与 Restart类似,如果这个服务被关闭,然后需要重新启动时,大概要 sleep 多少时间再重新启动。预设是 100ms (毫秒)。 |
1.1.1.1 [Install] 部份
设定参数 |
参数意义说明 |
WantedBy |
这个设定后面接的大部分是 *.target unit 。意思是,这个 unit 本身是附挂在哪一个 target unit 底下的。一般来说,大多的服务性质的 unit 都是附挂在 multi-user.target 底下。 |
Also |
当目前这个 unit 本身被 enable 时,后面接的unit也需要enable。通常配置有相依性的服务。 |
Alias |
为连结赋予别名。当 systemctl enable 相关的服务时,则此服务会进行连结档的建立。以 multi-user.target 为例,这个是用来作为预设操作环境 default.target 的规划的,当Alias设定为 default.target 时 , 这 个 /etc/systemd/system/default.target 就 会 连 结 到 /usr/lib/systemd/system/multi-user.target 。 |
1.1.2 配置文件编写规则
配置文件内有些编写规则:
l 设定项目通常是可以重复的,例如我可以重复设定两个 After 在配置文件中,不过,后面的设定会取代前面的;因此,如果想要将设定值归零, 可以使用类似『 After= 』的设定。
l 如果设定参数需要有『是/否』的项目 (布尔值, boolean),你可以使用 1, yes, true, on 代表启动,用 0, no, false,off 代表关闭。
l 空白行、开头为 # 或 ; 的那一行,都代表批注!
1.1.3 配置文件示例
下面是日志审计系统的服务配置文件:
[Unit] Description=Hikvision LLCAS After=syslog.target network.target remote-fs.target nss-lookup.target
[Service] Type=forking PIDFile=/opt/Hikvision/llcas-1.0/tomcat9.pid ExecStart=/opt/Hikvision/llcas-1.0/bin/startup.sh ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s QUIT $MAINPID PrivateTmp=true
[Install] WantedBy=multi-user.target |
2. Supervisor
Supervisor 是一款基于Python的进程管理工具,可以很方便的管理服务器上部署的应用程序。Supervisor安装完成后会生成三个可执行程序:supervisortd、supervisorctl、echo_supervisord_conf。
l supervisord 是服务端程序,也是supervisor的守护进程程序,接收客户端supervisorctl发送的命令对用户进程进行控制管理(比如重启、关闭等),监控并重启闪退或异常退出的子进程(被管理的用户进程),把子进程的stderr或stdout记录到日志文件中,生成和处理Event等。
l supervisorctl 是客户端程序,用于和守护进程通信,发送管理进程的指令。supervisorctl 有一个类似shell的命令行界面,我们可以利用它来查看子进程状态,启动/停止/重启子进程,获取running子进程的列表等等。
l echo_supervisord_conf 是配置文件生成程序,用于生成初始配置文件。
l Supervisor还提供了一个 web 管理界面,可以在这个界面上管理进程。
Supervisor可以很方便的管理服务器上部署的应用程序。主要功能如下:
l 启动、重启、关闭包括但不限于python进程
l 查看进程的运行状态
批量维护多个进程
1.1 启动说明
Supervisor可以使用命令supervisord启动,此时使用的是默认配置文件,也可以使用 supervisord -c /etc/supervisord.conf来指定配置文件。
supervisor启动的时候如果没有加上-c参数,则会使用默认的配置文件启动,supervisor会按照如下顺序去寻找默认配置文件。
l $CWD/supervisord.conf l $CWD/etc/supervisord.conf l /etc/supervisord.conf |
$CWD表示当前的工作目录,上面三个路径从上到下优先级递减,也就是说supervosir会优先去检查$CWD/supervisord.conf文件是否存在,存在就使用该文件启动supervisor,否则向下继续检查。
也可以使用如下命令生成配置文件:
echo_supervisord_conf > /etc/supervisord.conf |
1.2 配置文件修改
Supervisor配置文件的有以下主要配置项:
[unix_http_server] file=/tmp/supervisor.sock ; socket文件的路径,supervisorctl用XML_RPC和supervisord通信就是通过它进行的。如果不设置的话,supervisorctl也就不能用了不设置的话,默认为none。非必须设置 ;[inet_http_server] ; 侦听在TCP上的socket,Web Server和远程的supervisorctl都要用到他不设置的话,默认为不开启。非必须设置 [supervisord] ;这个主要是定义supervisord这个服务端进程的一些参数的这个必须设置,不设置,supervisor就不用干活了 logfile=/tmp/supervisord.log ; 这个是supervisord这个主进程的日志路径,注意和子进程的日志不搭嘎。默认路径$CWD/supervisord.log,$CWD是当前目录。。非必须设置 logfile_maxbytes=50MB ; 这个是上面那个日志文件的最大的大小,当超过50M的时候,会生成一个新的日志文件。当设置为0时,表示不限制文件大小默认值是50M,非必须设置。 logfile_backups=10 ; 日志文件保持的数量,supervisor在启动程序时,会自动创建10个buckup文件,用于log rotate当设置为0时,表示不限制文件的数量。默认情况下为10。非必须设置 loglevel=info ; 日志级别,有critical, error, warn, info, debug, trace, or blather等默认为info。。。非必须设置项 pidfile=/tmp/supervisord.pid ; supervisord的pid文件路径。默认为$CWD/supervisord.pid。。。非必须设置 nodaemon=false ; 如果是true,supervisord进程将在前台运行默认为false,也就是后台以守护进程运行。。。非必须设置 minfds=1024 ; 这个是最少系统空闲的文件描述符,低于这个值supervisor将不会启动。系统的文件描述符在这里设置cat /proc/sys/fs/file-max 默认情况下为1024。非必须设置 minprocs=200 ; 最小可用的进程描述符,低于这个值supervisor也将不会正常启动。ulimit -u这个命令,可以查看linux下面用户的最大进程数。默认为200。非必须设置
[rpcinterface:supervisor] ;这个选项是给XML_RPC用的,当然你如果想使用supervisord或者web server 这个选项必须要开启的supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface [supervisorctl] ;这个主要是针对supervisorctl的一些配置 serverurl=unix:///tmp/supervisor.sock ; 这个是supervisorctl本地连接supervisord的时候,本地UNIX socket路径,注意这个是和前面的[unix_http_server]对应的默认值就是unix:///tmp/supervisor.sock。。非必须设置
;[eventlistener:theeventlistenername] ;和program的地位是一样的,也是suopervisor启动的子进程,订阅supervisord发送的event。他的名字就叫listener了。我们可以在listener里面做一系列处理,比如报警等等
;[group:thegroupname] ;这个东西就是给programs分组,划分到组里面的program。我们就不用一个一个去操作了我们可以对组名进行统一的操作。 注意:program被划分到组里面之后,就相当于原来的配置从supervisor的配置文件里消失了。。。supervisor只会对组进行管理,而不再会对组里面的单个program进行管理了 ;programs=progname1,progname2 ; 组成员,用逗号分开这个是个必须的设置项 ;priority=999 ; 优先级,相对于组和组之间说的默认999。。非必须选项 ;[include] ;这个东西挺有用的,当我们要管理的进程很多的时候,写在一个文件里面就有点大了。我们可以把配置信息写到多个文件中,然后include过来 ;files = relative/directory/*.ini |
Supervisor配置文件内容按照使用对象可以分为:Supervisord自身的配置项内容、需要管理的应用程程序的配置两种配置,在实际使用中,如果我们应用程序特别多,将两种内容分为多个文件进行配置,然后使用[include] 将应用程序配置引入进来比较方便。下面介绍时,默认是多文件配置方式。
1.1.1 Supervisor配置
下面是配置信息示例:
[rpcinterface:supervisor] supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface [unix_http_server] file=/tmp/supervisor.sock ; supervisord 服务进程的sock文件 [supervisord] logfile=/data/logs/supervisord/supervisord.log ; 日志文件,默认是 $CWD/supervisord.log logfile_maxbytes=50MB ; 日志文件大小,超出50MB会做轮转,默认为50MB logfile_backups=10 ; 日志文件保留备份数量 loglevel=info ; 日志级别,默认 info,其它: debug,warn,trace pidfile=/var/run/supervisord.pid ; pid 文件 nodaemon=false ; 是否在前台启动,默认是 false,即以 daemon 的方式启动 minfds=10240 ; 可以打开的文件描述符的最小值,默认 1024 minprocs=200 ; 可以打开的进程数的最小值,默认 200 #### ### [supervisorctl] serverurl = unix:///tmp/supervisor.sock [include] files = /etc/supervisord.d/*.conf ;包含需要管理的应用程序的配置文件 |
其中[include]项配置的是‘需要管理的应用程程序的配置’,其他项是‘Supervisord自身的配置项内容’。
1.1.2 应用程序配置
在Supervisor配置文件的[include]项中,指定了应用程序配置文件路径,下面介绍下应用程序的配置。
应用程序的配置需要[program:PROGRAM_NAME] 部分的配置,PROGRAM_NAME表示 supervisord 要管理那个进程描述,会在客户端supervisorctl 或 web 界面显示,可以通过 supervisorctl start|restart|stop PROGRAM_NAME 来操作维护该进程。下面是个配置文件结构示例:
[program:PROGRAM_NAME] 属性1=参数1 .... 属性N=参数N |
下面是实际的一个应用程序配置文件内容:
[program:haunt] directory = /opt/haunt_agent ; 程序的启动目录 command= /opt/haunt_agent/bin/haunt_agent -c /opt/haunt_agent/conf/haunt_agent.ini; 启动haunt程序的命令,与手动启动的命令一致 autostart = true ;在 supervisord 启动的时候也自动启动 startsecs = 5 ;启动 5 秒后没有异常退出,就当作已经正常启动了 autorestart = true ;程序异常退出后自动重启 startretries = 3 ; 启动失败自动重试次数,默认是 3 user = app ; 用哪个用户启动 redirect_stderr = true ; 把 stderr 重定向到 stdout,默认 false stdout_logfile_maxbytes = 10MB ; stdout 日志文件大小,默认 20MB stdout_logfile_backups = 10 ; stdout 日志文件备份数 stdout_logfile = /data/logs/supervisor/haunt_stdout.log; stdout日志文件,注意当指定目录不存在时无法正常启动,所以需要手动创建目录(supervisord 会自动创建日志文件); 可以通过 environment 来添加需要的环境变量,一种常见的用法是修改 PYTHONPATH; environment=PYTHONPATH=$PYTHONPATH:/path/to/somewhere |
1.2 常用命令
Supervisor常用的命令有以下几个:
命令示例 |
功能说明 |
supervisorctl stop program_name |
停止某一个进程,program_name 为 配置文件中[program:x] 里的 x |
supervisorctl start program_name |
启动某个进程 |
supervisorctl restart program_name |
重启某个进程 |
supervisorctl stop groupworker: |
结束所有属于名为 groupworker 这个分组的进程 (start,restart 同理) |
supervisorctl stop groupworker:name1 |
结束 groupworker:name1 这个进程 (start,restart 同理) |
supervisorctl stop all |
停止全部进程,注:start、restart、stop 都不会载入最新的配置文件 |
supervisorctl reload |
载入最新的配置文件,停止原有进程并按新的配置启动、管理所有进程,相当于重启所有的服务,该命令慎用 |
supervisorctl update |
根据最新的配置文件,启动新配置或有改动的进程,配置没有改动的进程不会受影响而重启 |
1.3 分组管理进程
在4.2节中,介绍Supervisor配置文件时,有配置项[group:thegroupname]可以将配置的应用程序进行分组,配置示例如下:
[group:GROUP_NAME] programs=prog_name1,prog_name2 ; each refers to 'x' in [program:x] definitions priority=999 ; the relative start priority (default 999) |
使用group配置之后,使用supervisorctl 管理进程的时候,变为管理group组内所有的程序,管理命令如下:
supervisorctl [start|restart|stop|reload] GROUP_NAME 管理单个应用程序 supervisorctl [start|restart|stop|reload] GROUP_NAME:prog_name1 supervisorctl [start|restart|stop|reload] GROUP_NAME:prog_name2 |
如果应用程序很多,而且应用程序间有明细的依存关系,可以使用这种方式替代单个进程管理方法。
1. Monit
下面是Monit官方的介绍信息:
Monit是一个实用程序,用于管理和监视Unix系统上的进程,程序,文件,目录和文件系统。Monit会进行自动维护和修复,并可以在错误情况下执行有意义的因果操作。例如,如果Monit无法运行,它可以启动一个进程;如果它没有响应,则可以重启一个进程;如果使用过多的资源,则可以停止一个进程。您可以使用Monit监视文件,目录和文件系统的更改,例如时间戳更改,校验和更改或大小更改。
Monit通过基于自由格式,面向令牌的语法的易于配置的控制文件进行控制。Monit记录到syslog或自己的日志文件中,并通过可自定义的警报消息通知用户有关错误情况的信息。Monit可以执行各种TCP / IP网络检查,协议检查,并且可以使用SSL进行此类检查。Monit提供了HTTP(S)接口,您可以使用浏览器访问Monit程序。
Monit有以下几个突出特点:
l 超轻量, 稳定, 高可用
l 依赖少, 安装配置方便, 尽量减少运维及学习成本(即使没有任何 Monit 基础的人, 都能轻易的读懂大部分监控文件)
l 非侵入式, 被监控的程序可以不用知道监控程序的存在(如果使用 Supervisor 监控, 则服务必须从 Supervisor 启动)
l 基本功能完备(9种类型监控, 邮件报警, 支持用户自定义 shell 扩展)
1.1 Monit安装
Monit支持从源码编译安装,操作命令如下:
$ tar zxvf monit-x.y.z.tar.gz (where x.y.z denotes version numbers) $ cd monit-x.y.z $ ./configure (use ./configure --help to view available options) $ make && make install |
也可以通过yum进行安装,命令如下:
# yum install -y monit |
1.2 相关配置
Monit通过名为monitrc的控制文件进行配置和控制。该文件的默认位置是〜/ .monitrc。如果该文件不存在,Monit将尝试/etc/monitrc,然后尝试@ sysconfdir@/monitrc,最后是./monitrc。如果从源代码构建Monit,则@sysconfdir@的值可以在配置时指定为./configure –sysconfdir。
为了保护配置文件和密码的安全性,配置文件必须具有不超过0700(u = xrw,g =o =)的读写权限。否则Monit会提醒并退出。
使用yum安装默认配置文件在:
/etc/monitrc # 主配置文件 /etc/monit.d/ # 单独配置各项服务 |
配置文件关键字有:'if', 'and', 'with(in)', 'has', 'us(ing|e)', 'on(ly)', 'then', 'for', 'of'。
1.2.1 配置文件内容
主配置文件完成一些全局配置,同时引入各项服务的单独配置文件,下面是一个简化版的主配置文件说明:
############################################################################### ## Global section ############################################################################### # Start Monit in the background (run as a daemon): # # 设置检测周期30s set daemon 30 # check services at 30 seconds intervals
#设置log路径,这里默认记录到syslog set logfile syslog
# 设置邮件服务器用来发送邮件告警通知 set mailserver mail.abcd.so
# 设置邮件告警通知格式 set mail-format { from: monit@$HOST subject: monit alert -- $EVENT $SERVICE message: $EVENT Service $SERVICE Date: $DATE Action: $ACTION Host: $HOST Description: $DESCRIPTION
Your faithful employee, Monit } # set mail-format { from: monit@foo.bar } # # 设置邮件告警通知人,Monit默认会通知monit进程本身的变化情况,如果不想收到monit进程自身的通知,加上but not on {instance}配置 set alert weian@abcd.so but not on { instance } # receive all alerts # # 设置UI界面访问信息 set httpd port 2812 and use address 10.2.2.28 # only accept connection from localhost # allow localhost # allow localhost to connect to the server and allow admin:monit # require user 'admin' with password 'monit' ########################################################################## ## Services ############################################################################### # # check process apache with pidfile /usr/local/apache/logs/httpd.pid # start program = "/etc/init.d/httpd start" with timeout 60 seconds # stop program = "/etc/init.d/httpd stop" # if cpu > 60% for 2 cycles then alert # if cpu > 80% for 5 cycles then restart # if totalmem > 200.0 MB for 5 cycles then restart # if children > 250 then restart # if loadavg(5min) greater than 10 for 8 cycles then stop # if failed host www.tildeslash.com port 80 protocol http # and request "/somefile.html" # then restart # if failed port 443 type tcpssl protocol http # with timeout 15 seconds # then restart # if 3 restarts within 5 cycles then unmonitor # depends on apache_bin # group server # # 监控进程可以通过上面监控pid文件的方式,当没有pid文件时,可以通过MATCHING正则表达式来匹配进程。 # 测试一个进程是否匹配来自命令行使用的模式monit procmatch "regex-pattern",这将列出匹配或不匹配的所有进程,regex模式。 # 我们这里监控了包含shop-pad-server字段的进程,并指明了启动以及停止的命令,这样在进程因故断掉后,Monit会自动重启进程。 # 同时若进程ID变动,会发送邮件通知到之前指定的收件人。 ############################################################################### ## Includes ############################################################################### # 导入其他单项服务的监控配置 include /etc/monit.d/* |
1.2.2 各项服务配置文件
各项服务配置文件遵从Monit自己的领域专用语言(DSL);配置文件由一系列服务条目和全局选项语句组成。具体可以参考Monit官方网站的说明(https://mmonit.com/monit/documentation/monit.html#Service-checks),这里对进程监控和程序监控的配置进行简要说明。
CHECK PROCESS <unique name> <PIDFILE <path> | MATCHING <regex>> <path>是程序的pid文件的绝对路径。pid文件是一个文件,其中包含进程的唯一ID。如果pid文件不存在或不包含正在运行的进程的PID号,Monit将调用该条目的start方法(如果已定义)。 <regex>是使用PID文件的替代方法,并使用过程名称模式匹配来查找要监视的过程。选择了具有最高正常运行时间的最匹配的父级,因此,如果进程名称是唯一的,则这种形式的检查最有用。应尽可能使用PID文件,因为它准确定义了期望的PID。您可以使用来从命令行测试进程是否与模式匹配monit procmatch "regex-pattern"。这将列出所有匹配或不匹配的进程,正则表达式模式。
CHECK PROGRAM <unique name> PATH <executable file> [TIMEOUT <number> SECONDS] <path>是可执行程序或脚本的绝对路径。该状态测试允许一个检查程序的退出状态。如果程序未在<number>秒内完成执行,Monit将终止它。默认程序超时为300秒(5分钟)。程序的输出将被记录并在用户界面和警报中可用,默认情况下最大为512字节。您可以使用set limit语句更改输出限制。 |
1.1 常用命令
monit -t # 配置文件检测 monit # 启动monit daemon monit -c /var/monit/monitrc # 启动monit daemon时指定配置文件 monit reload # 重新加载配置文件 monit status # 查看所有监控项务状态 monit status nginx # 查看nginx服务状态 monit stop all # 停止所有服务,这里需要注意的是,如果开启了自动重启功能,停止某个被监控的服务必须用monit stop xxx,若用系统命令停止服务,Monit会自动再把服务起来。 monit stop nginx # 停止nginx服务 monit start all # 启动所有服务 monit start nginx # 启动nginx服务 monit -V # 查看版本 |
2. 其他进程管理工具
2.1 Circus
circus 是由mozilla 团队开发基于python 以及zeromq 的进程以及socket 管理的工具,类似supervisord但是比supervisord 更灵活方便。其中官方给了一个与Supervisord的对比图,可以看出两者的区别。
Circus出现时(2013年),相比于Supervisor有两个突出特点:
l 它支持py3,而supervisor不支持
l 它1个可以负责各种服务,取代 supervisor 和gunicorn 两个
但是最近几年的使用情况看,在进程管理方面,Circus的活跃度低于Supervisor,而且Circus的更新停滞了,资料也不容易获取。