zabbix 6.0 监控自定义服务
0.Linux系统中服务的相关理论
在 Linux 系统中,服务(Service)是指在后台运行的程序或一系列程序,它们提供系统功能或网络功能,通常在系统启动时自动启动,并在用户不需要直接交互的情况下运行。以下是 Linux 中服务的一些关键概念:
-
守护进程(Daemon): 服务通常是以守护进程的形式运行的。守护进程是一种在后台运行,没有与终端相关联的进程。
-
系统服务管理: Linux 系统使用服务管理器(如
systemd
、Upstart
或SysVinit
)来控制服务的启动、停止、重启和状态检查。 -
服务单元(Service Unit): 在
systemd
中,服务由服务单元文件定义,这些文件包含有关服务如何运行的信息,包括启动命令、依赖关系和配置选项。 -
服务状态: 服务可以处于不同的状态,如活动的(active)、不活动的(inactive)、随系统自启(enabled)、不随系统自启(disabled)和故障(failed)。
-
服务依赖: 服务之间可以有依赖关系,即一个服务可能需要另一个服务先启动或运行。例如:
After=network.target
,说明该服务依赖系统网络服务。 -
运行级别(Runlevel): 在传统的
System V
和Upstart
服务管理中,运行级别定义了系统启动时应该启动哪些服务。 -
服务目标(Target):
systemd
使用目标(如multi-user.target
或graphical.target
)来定义一组应该一起启动的服务。 -
服务配置文件: 服务的配置通常存储在配置文件中,通常存储在
/etc/systemd/system/
或/usr/lib/systemd/system/
目录下并以服务名.service
命名,这些文件在服务启动时被读取,首先判断该服务是否是开启自启的(enable)或非开机自启的(disable),然后决定是否启动该服务。/etc/systemd/system/
目录的优先级高于/usr/lib/systemd/system/
,也就是说如果同名的服务配置文件同时存在于以上两个目录中,/etc/systemd/system/
目录下的配置会覆盖/usr/lib/systemd/system/
目录下的配置。如果要使用zabbix监控自定义的服务,需要将
service
配置文件放在/usr/lib/systemd/system/
目录下,否则zabbix-agent2自带的systemd模板无法获取数据。 -
服务日志: 服务的输出和错误通常被记录在日志中,可以使用
journalctl
、dmesg
或/var/log/
目录下的日志文件来查看。 -
服务管理命令: 使用命令行工具(如
systemctl
、service
或/etc/init.d/
脚本)来管理服务。 -
系统启动和关闭脚本: 在系统启动和关闭时,服务管理器会执行特定的脚本或命令来启动和停止服务。
-
服务的安全性和权限: 服务通常以非 root 用户权限运行,以减少安全风险,除非特定服务需要 root 权限来执行。
服务是 Linux 系统中不可或缺的一部分,它们提供了网络服务、系统功能、硬件管理和其他关键任务的自动化执行。通过服务管理器,系统管理员可以方便地控制这些服务的生命周期。
1.将脚本定义成服务
如果只需要运行一次就退出生命周期的程序或脚本改成服务的模式似乎意义不太大,但是对于一些启动后就进入守护的server程序却有非常大的实用价值。如果程序写的不健壮,长时间的运行很有可能引起内存泄漏、CPU资源占用过高等一系列的问题,通过监控程序的服务状态结合监控工具可以提供基于系统(systemd)的解决方案(重启服务,开机自启服务等)提升程序的健壮性。
为了说明这个问题,修改前文中的python脚本(原脚本是打印一条日志消息)改成每隔一分钟打印一次日志消息。
1.1 编写脚本
🚀 只打印一次日志的脚本sayaword.py
#!/usr/bin/env python3
import logging
import logging.handlers
def setup_logger():
# 创建一个logger
logger = logging.getLogger('my_logger')
logger.setLevel(logging.INFO) # 设置日志级别为INFO
# 创建一个handler,用于写入系统日志
handler = logging.handlers.SysLogHandler(address='/dev/log')
handler.setLevel(logging.INFO)
# 定义handler的格式
formatter = logging.Formatter('%(name)s: %(levelname)s %(message)s')
handler.setFormatter(formatter)
# 将handler添加到logger中
logger.addHandler(handler)
return logger
def main():
logger = setup_logger()
logger.info('This is a test log message.')
if __name__ == '__main__':
main()
🚀 每隔一分钟打印一次的脚本sayaword2.py
#!/usr/bin/env python3
import logging
import logging.handlers
import time
def setup_logger():
# 创建一个logger
logger = logging.getLogger('my_logger')
logger.setLevel(logging.INFO) # 设置日志级别为INFO
# 创建一个handler,用于写入系统日志
handler = logging.handlers.SysLogHandler(address='/dev/log')
handler.setLevel(logging.INFO)
# 定义handler的格式
formatter = logging.Formatter('%(name)s: %(levelname)s %(message)s')
handler.setFormatter(formatter)
# 将handler添加到logger中
logger.addHandler(handler)
return logger
def main():
logger = setup_logger()
while True: # 创建一个无限循环
logger.info('This is a test log message.') # 写入日志
time.sleep(60) # 暂停60秒(即一分钟)
if __name__ == '__main__':
main()
将脚本保存在/home/script
目录下,并通过chmod +x
命令给脚本赋可执行权限。
1.2 编写服务配置文件
为了实现能够通过zabbix
自带的模板监控服务状态,我们需要把服务配置文件放在/usr/lib/systemd/system
目录下。
vim /usr/lib/systemd/system/sayaword.service
在sayaword.service
中添加以下内容。
[Unit]
Description=Say a word Device
After=network.target
[Service]
Type=simple
ExecStart=/home/script/sayaword2.py
Restart=always
[Install]
WantedBy=multi-user.target
使用下面的命令重新加载服务
systemctl daemon-reload
接下来就能够使用systemctl
命令对我们自定义的服务进行操作了。
👿 为了让我们的服务更健壮,在[Service]单元中增加了Restart=always
,这个选项的作用就是防止服务进程被意外杀死,如果被意外杀死了,systemd机制会自动将它拉起。
下图就是验证过程。
如果service
的[Service]中缺少了Restart=always
这个选项,结果就是进程被杀后就不会再重启了。
下面是修改后的sayaword.service
文件
[Unit]
Description=Say a word Device
After=network.target
[Service]
Type=simple
ExecStart=/home/script/sayaword2.py --supervised systemd
[Install]
WantedBy=multi-user.target
👿 修改service配置文件后,要使用systemctl daemon-reload
命令使修改生效。
2.使用zabbix-agent2
自带模板监控服务
在zabbix-agent2
的自带模板中有一个Systemd by Zabbix agent 2
的模板,使用这个模板就可以监控服务了(模板中自带服务自动发现),只要在我们的主机上配置了这个模板,就能实现服务的监控了。
3.使用过滤器监控指定的服务
前面我们通过zabbix-agent2
自带模板对系统服务做了监控,但是监控结果如下:
模板会自动监控系统所有的服务,而我们只想监控我们自定义的服务,这样才能重点突出。
在”配置“中找到我们的主机,进入”自动发现“而后选择“Service units discovery”.
打开过滤器。
在过滤器中添加一个我们要监控的服务的匹配项。
再次回到监控面板会发现面板中只剩下我们指定的服务了。
🤖 这里需要等待模板的更新周期,过了模板的更新周期后才会生效。如果想尽快看到修改结果可以将资源周期不足修改成0,执行一下,然后再回到监控面板就会发现出现我们想要的结果了。
👿 测试完成后,正式的监控环境建议将更新间隔(30m),资源周期不足(30d)的值改回默认,否则会增加服务器的资源占用。
如果我们想监控多个指定的服务应该怎么操作呢?
还是通过过滤器,只要我们把过滤器的条件设置成or就可以了,下图是一个示例。
👿 修改完过滤器不要忘记”更新“,”立即执行“等操作。
4.自定义触发器的处理脚本
4.1 创建自定义脚本
为了提升自定义服务的健壮性,当服务出现异常时为触发器定义处理脚本。
首先进入zabbix的web管理界面,打开“管理–>脚本–>创建脚本”,创建一个重启服务的自定义脚本。
4.2 创建动作
通过zabbix的web管理界面,打开”配置–>动作–>创建动作“,为指定的主机(模板或主机群组等)创建动作。
然后将我们自定义的脚本作用于操作。
5.修改客户端配置文件
5.1 修改sudoers
配置
由于systemctl restart <服务名>
需要使用sudo权限,zabbix 服务端执行脚本时,在客户端是以zabbix
用户执行的,为了使zabbix
用户能够执行sudo权限,需要修改sudoers
文件。
visudo
- zabbix ALL=NOPASSWD: ALL zabbix设置为所有命令sudo权限
- zabbix ALL=(ALL) NOPASSWD: /usr/bin/systemctl 只为
systemctl
命令设置sudo权限 - zabbix ALL=(ALL) NOPASSWD: /usr/bin/echo, /usr/bin/systemctl, /usr/bin/touch 可以为zabbix用户设置多个命令的sudo权限,命令之间使用逗号隔开。
5.2 修改zabbix-agent2.conf
配置文件
要想让zabbix-agent执行(来自zabbix-server)远程命令,需要在配置文件中添加以下语句。
AllowKey=system.run[*]
6.验证
我们手动关闭sayaword
服务,根据我们的设想当sayaword
服务异常时会触发我们自定义的重启脚本,服务会强制重启。
重启脚本用了20秒,感觉这个20秒可以配置。
关注博主不迷路,每天带你学习新技术。