1. 项目概述与核心需求解析家里设备一多管理起来就头疼。特别是那些默默无闻、却又至关重要的“幕后英雄”——比如负责存储家庭照片和重要文件的NAS负责全屋智能联动的MQTT服务器和openHAB还有那些安防用的网络摄像头。它们一旦“罢工”轻则数据丢失重则家里的自动化场景全部失灵而你却可能毫不知情直到需要用的时候才发现为时已晚。我自己就遇到过好几次IP摄像头因为网络波动离线了好几天NAS在意外断电后没能自动重启导致备份中断。这种“事后诸葛亮”的感觉非常糟糕。于是一个简单而直接的需求诞生了我需要一个“哨兵”7x24小时不间断地监视我网络里所有关键设备的“心跳”。一旦某个设备停止响应它能立刻通知我而不是让我自己去发现。通知方式上我偏爱电子邮件。它足够正式能携带详细信息并且几乎能在所有设备上即时推送比依赖短信或特定App更通用、更可靠。“Ping The Thing”这个项目就是为了解决这个痛点而生的。它的核心就是一个运行在树莓派或者任何一台常开的Linux服务器上的Python脚本。这个脚本会周期性地向一个你预先定义好的设备列表发送网络Ping探测。如果某个设备连续多次没有回应脚本就会判定它“失联”并自动触发一封告警邮件发送到你指定的邮箱。整个过程完全自动化你只需要在初始配置时告诉它“监视谁”和“通知谁”之后它就会在后台默默工作充当你的家庭网络健康管家。2. 方案设计与工具选型考量2.1 为什么选择“Ping”作为探测手段在众多网络探测方式中选择ICMP Ping协议作为核心是基于其普适性、轻量化和低侵入性的综合考虑。首先普适性极高。几乎任何接入网络的设备无论是Windows PC、Linux服务器、NAS、网络打印机、智能家居网关甚至是许多IoT设备只要其网络栈支持并开启了ICMP Echo Reply绝大多数设备默认如此就能响应Ping请求。这避免了为不同设备开发不同探测协议如HTTP、SNMP的复杂性用一个统一的方法覆盖了绝大多数场景。其次实现极其轻量。Ping探测本身只产生微小的网络流量一个ICMP Echo Request包通常只有几十字节对网络带宽和设备性能的影响可以忽略不计。这对于需要长时间、高频率例如每分钟一次运行的监控脚本至关重要能保证其自身资源消耗极低。最后结果明确且快速。Ping的响应Reply或超时Timeout能非常直观地反映网络层的连通性。设备宕机、网络断开、IP冲突等问题都会直接导致Ping失败。虽然它无法判断应用层服务如Web服务器端口80是否正常但对于“设备是否在线”这个基础问题Ping是最快、最直接的诊断工具。注意有些出于安全考虑的网络环境或设备可能会禁用ICMP响应。如果你的目标设备属于这种情况Ping方案将失效需要考虑TCP端口探测等替代方案。2.2 核心组件与依赖解析整个项目可以拆解为三个核心功能模块每个模块都有成熟、稳定的工具或库可供选择。网络探测模块负责执行Ping操作。Python标准库中的subprocess模块可以调用系统自带的ping命令这是最兼容的方式。但更优雅、跨平台的选择是使用第三方库pythonping或ping3。它们提供了纯Python的实现无需依赖系统命令并且能更精细地控制超时、重试次数并直接返回成功/失败的结果便于程序判断。邮件发送模块负责在设备离线时发送告警邮件。Python内置的smtplib和email库是完成此任务的标准答案。它们功能完整可以构造包含主题、正文、甚至附件的邮件并通过SMTP协议发送到邮件服务器如Gmail、QQ邮箱、企业邮箱等。任务调度模块负责让脚本周期性地如每5分钟执行一次探测任务。对于这种简单的后台守护任务最佳实践是借助操作系统的能力。我们可以将脚本配置为一个Systemd服务或Cron定时任务。Systemd服务更适合需要持续运行、具备依赖管理、日志收集和自动重启能力的场景而Cron则更简单直接适合“到点执行”的脚本。为什么选择树莓派作为运行平台树莓派功耗极低通常仅2-5瓦7x24小时运行电费几乎可忽略不计它本身就是一个完整的Linux计算机可以轻松安装Python和邮件客户端如msmtp而且很多家庭已经有一台树莓派在运行Pi-hole等常驻服务在其上增加这个监控脚本是资源复用的绝佳选择无需额外添置硬件。3. 环境准备与基础配置在开始编写和运行脚本之前我们需要为树莓派或你的Linux服务器搭建好运行环境。这个过程就像给哨兵搭建岗亭和配备通信工具。3.1 系统更新与Python环境确认首先确保你的系统是最新的并且Python3已就位。通过SSH连接到你的树莓派执行以下命令# 更新软件包列表并升级现有软件 sudo apt update sudo apt upgrade -y # 检查Python3是否已安装及其版本 python3 --version # 预期输出类似Python 3.9.2如果未安装Python3可以使用sudo apt install python3 -y进行安装。本项目推荐使用Python 3.6及以上版本。3.2 安装轻量级邮件发送工具msmtp虽然Python脚本可以用smtplib直接发邮件但配置邮箱的SMTP密码在脚本中明文存储存在安全风险。一个更安全、更专业的做法是使用独立的邮件传输代理MTA如msmtp。脚本只需调用msmtp命令而敏感的邮箱认证信息则单独存储在系统用户的配置文件中。# 安装 msmtp 和 msmtp-mta # msmtp-mta 包会提供一个 /usr/sbin/sendmail 的兼容接口让系统认为msmtp就是默认邮件发送程序 sudo apt install msmtp msmtp-mta -y安装完成后需要配置msmtp。这里以配置一个Gmail账户为例请注意Gmail需要应用专用密码而非你的登录密码。创建并编辑配置文件nano ~/.msmtprc将以下配置粘贴进去替换其中的[YOUR_EMAIL],[YOUR_NAME],[YOUR_APP_PASSWORD]# 设置默认账户 defaults auth on tls on tls_trust_file /etc/ssl/certs/ca-certificates.crt logfile ~/.msmtp.log # Gmail 账户配置 account gmail host smtp.gmail.com port 587 from [YOUR_EMAIL] user [YOUR_EMAIL] password [YOUR_APP_PASSWORD] # 将上述账户设置为默认账户 account default : gmail[YOUR_APP_PASSWORD]需要在Google账户的“安全性”设置中生成一个“应用专用密码”。tls on和port 587确保了通信加密。设置配置文件权限防止其他用户读取你的密码chmod 600 ~/.msmtprc测试邮件发送echo -e Subject: Test from PingTheThing\n\nThis is a test email from your Raspi. | msmtp [YOUR_RECIPIENT_EMAIL]将[YOUR_RECIPIENT_EMAIL]替换为你希望接收告警的邮箱地址。稍等片刻检查收件箱是否收到测试邮件。实操心得使用msmtp而非在Python脚本中硬编码SMTP密码是遵循了“关注点分离”和“最小权限”的安全原则。即使脚本被他人看到你的邮箱凭证也是安全的。此外msmtp的日志文件~/.msmtp.log在排查邮件发送问题时非常有用。3.3 安装Python依赖库我们将使用ping3这个库来进行Ping操作它比调用系统命令更简洁。# 使用pip3安装ping3库 pip3 install ping3如果系统提示pip3未找到可能需要先安装它sudo apt install python3-pip -y。至此基础环境已经准备就绪。我们有了Python3、安全的邮件发送工具msmtp以及网络探测库ping3。接下来就可以着手编写核心的监控脚本了。4. 核心脚本编写与逐行解析有了稳固的基础环境我们现在来构建“哨兵”的大脑——监控脚本。我将提供一个功能完整、注释详细的版本并逐一解释关键代码段的设计意图和注意事项。4.1 脚本完整代码创建一个名为ping_the_thing.py的文件#!/usr/bin/env python3 Ping The Thing - 家庭网络设备存活监控脚本 作者基于实际需求自研 功能周期性Ping一组设备连续失败则发送邮件告警。 import subprocess import time import sys from datetime import datetime import logging from typing import Dict, List # ------------------ 用户配置区域 ------------------ # 1. 被监控设备列表 # 格式 {设备友好名称: IP地址或主机名} DEVICES_TO_MONITOR { 主NAS: 192.168.1.100, MQTT服务器: 192.168.1.101, OpenHAB服务器: 192.168.1.102, 客厅摄像头: 192.168.1.150, 书房打印机: 192.168.1.88, # 请在此处继续添加你的设备... } # 2. 邮件接收者 EMAIL_RECIPIENT your-emailexample.com # 替换为你的告警邮箱 # 3. 监控参数 PING_TIMEOUT 2 # 单次Ping超时时间秒 PING_COUNT 3 # 每次探测发送的Ping包数量 CHECK_INTERVAL 300 # 检查间隔秒例如300秒5分钟 FAILURE_THRESHOLD 2 # 连续失败次数阈值达到此值才发告警 # 4. 日志配置 LOG_FILE /var/log/ping_the_thing.log # ------------------ 全局状态记录 ------------------ # 用于记录每个设备连续失败的次数 failure_counters: Dict[str, int] {device: 0 for device in DEVICES_TO_MONITOR} # 记录设备当前状态up 或 down用于状态变化判断 device_status: Dict[str, str] {device: up for device in DEVICES_TO_MONITOR} # ------------------ 初始化日志 ------------------ logging.basicConfig( levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(LOG_FILE), logging.StreamHandler(sys.stdout) # 同时输出到控制台 ] ) logger logging.getLogger(__name__) # ------------------ 核心函数定义 ------------------ def ping_host(hostname: str) - bool: 使用系统ping命令探测主机是否在线。 返回: True 在线 False 离线 # 构造ping命令-c指定次数-W指定超时秒-q静默模式 command [ping, -c, str(PING_COUNT), -W, str(PING_TIMEOUT), -q, hostname] try: # 执行命令超时时间略大于 PING_COUNT * PING_TIMEOUT result subprocess.run( command, stdoutsubprocess.DEVNULL, stderrsubprocess.DEVNULL, timeout(PING_TIMEOUT * PING_COUNT 2) ) # 返回码为0表示至少收到一个回复包 return result.returncode 0 except subprocess.TimeoutExpired: # 命令执行超时通常不会发生因为ping自身有超时 logger.warning(fPing command timed out for {hostname}) return False except Exception as e: # 其他意外错误如命令不存在 logger.error(fError pinging {hostname}: {e}) return False def send_alert_email(device_name: str, device_ip: str, failure_count: int): 使用系统sendmail命令由msmtp提供发送告警邮件。 current_time datetime.now().strftime(%Y-%m-%d %H:%M:%S) subject f[网络告警] 设备 {device_name} 可能离线 body f 告警时间{current_time} 设备详情 - 名称{device_name} - IP地址{device_ip} - 连续探测失败次数{failure_count} 脚本已尝试 Ping 该设备 {failure_count} 次均未收到响应。 请及时检查该设备电源、网络连接及服务状态。 此邮件由 Ping The Thing 监控脚本自动发送。 # 构造完整的邮件内容包含Headers email_content fTo: {EMAIL_RECIPIENT} Subject: {subject} Content-Type: text/plain; charsetutf-8 {body} try: # 使用subprocess调用sendmail命令 # -t 参数表示从邮件内容中提取收件人To: proc subprocess.Popen( [sendmail, -t], stdinsubprocess.PIPE, stdoutsubprocess.PIPE, stderrsubprocess.PIPE, textTrue ) stdout, stderr proc.communicate(inputemail_content) if proc.returncode 0: logger.info(f告警邮件已发送{device_name} ({device_ip})) else: logger.error(f发送邮件失败{stderr}) except Exception as e: logger.error(f调用sendmail时发生错误{e}) def check_devices(): 遍历所有设备执行Ping检查并更新状态和计数器。 global failure_counters, device_status logger.info(--- 开始本轮设备状态检查 ---) for device_name, device_ip in DEVICES_TO_MONITOR.items(): is_alive ping_host(device_ip) if is_alive: # 设备在线 if device_status[device_name] down: # 状态从“离线”恢复为“在线”发送恢复通知可选 logger.info(f[状态恢复] {device_name} ({device_ip}) 已重新上线。) # 你可以在这里添加发送“恢复通知”邮件的逻辑 pass # 重置失败计数器更新状态为在线 failure_counters[device_name] 0 device_status[device_name] up logger.debug(f{device_name} 在线。) else: # 设备离线 failure_counters[device_name] 1 logger.warning(f{device_name} Ping失败。连续失败次数{failure_counters[device_name]}) # 检查是否达到告警阈值 if failure_counters[device_name] FAILURE_THRESHOLD and device_status[device_name] up: # 首次达到阈值发送告警邮件 logger.error(f!!! 设备 {device_name} 判定为离线发送告警邮件。) send_alert_email(device_name, device_ip, failure_counters[device_name]) device_status[device_name] down # 更新状态为离线避免重复告警 elif failure_counters[device_name] FAILURE_THRESHOLD and device_status[device_name] down: # 已经处于告警状态记录日志但不重复发邮件 logger.warning(f设备 {device_name} 持续离线中。) logger.info(--- 本轮检查完成 ---\n) def main(): 主循环 logger.info(fPing The Thing 监控脚本启动。共监控 {len(DEVICES_TO_MONITOR)} 台设备。) logger.info(f检查间隔{CHECK_INTERVAL}秒 失败阈值{FAILURE_THRESHOLD}次。) try: while True: check_devices() time.sleep(CHECK_INTERVAL) except KeyboardInterrupt: logger.info(收到中断信号脚本停止。) except Exception as e: logger.critical(f脚本运行出现未预期错误{e}, exc_infoTrue) sys.exit(1) if __name__ __main__: main()4.2 关键代码逻辑深度解析1. 配置参数的设计哲学脚本开头的配置区域是核心。FAILURE_THRESHOLD失败阈值和CHECK_INTERVAL检查间隔是两个关键参数它们共同决定了监控的“敏感度”和“抗干扰能力”。FAILURE_THRESHOLD 2意味着需要连续两次检查都失败才判定设备离线。这有效避免了因网络瞬时抖动比如Wi-Fi信号波动、设备短暂高负载导致的误报。单次Ping失败很常见但连续失败的概率就小得多。CHECK_INTERVAL 300(5分钟)这是对设备状态采样的频率。太频繁如10秒会给网络和设备带来不必要的负担且日志量巨大太稀疏如1小时则会导致告警严重延迟。对于家庭环境5-15分钟是一个平衡点。你可以根据设备的重要性调整核心设备可以设短一些如2分钟非关键设备可以设长一些。2. 状态机与防骚扰机制脚本维护了两个核心字典failure_counters和device_status。这是一个简单的状态机实现。device_status记录设备的“告警状态”‘up’ 或 ‘down’而非瞬时连通状态。逻辑是只有当设备从 ‘up’ 状态转换到 ‘down’ 状态时即failure_counters首次达到阈值才会触发一次告警邮件。此后只要设备持续离线device_status保持 ‘down’脚本只会记录日志而不会重复发送邮件。这避免了邮箱被海量的重复告警淹没。当设备恢复在线时device_status被重置为 ‘up’同时计数器清零为下一次可能的故障做好准备。代码中还预留了发送“恢复通知”的接口你可以根据需要启用。3. 为什么使用subprocess调用系统ping命令虽然我们安装了ping3库但脚本中我选择了调用系统命令。原因有三兼容性与一致性系统ping命令的行为经过了数十年的检验在不同Linux发行版上结果高度一致。而纯Python的Ping库可能在处理某些网络环境或ICMP响应时存在细微差异。功能完整系统ping命令的-c次数和-W超时参数组合能很好地模拟我们“发送多个探测包等待一段时间”的意图。ping3库虽然简单但在超时和重试逻辑上需要更多代码来控制。结果明确ping命令的返回码returncode是一个非常清晰的信号——0表示成功至少收到一个回复非0表示失败。这简化了我们的判断逻辑。当然使用ping3也是完全可行的代码会更简洁。你可以根据喜好选择。如果使用ping3ping_host函数可以改写为from ping3 import ping def ping_host(hostname): delay ping(hostname, timeoutPING_TIMEOUT) return delay is not None and delay is not False4. 邮件发送的安全与可靠性脚本没有使用Python的smtplib直接连接邮箱服务器而是通过subprocess调用sendmail -t命令。这样做的好处是解耦邮件发送的认证、加密、中继等复杂逻辑全部交给专业的msmtp处理。脚本只负责生成邮件内容。安全邮箱密码等敏感信息存储在~/.msmtprc配置文件中并通过chmod 600严格限制访问权限不会在脚本中泄露。可靠msmtp自带队列和重试机制在网络临时中断时更能保证邮件最终被发出。5. 部署、运行与系统集成脚本写好了但它现在还只是一个普通的文件。我们需要把它变成一个可靠的后台服务确保树莓派重启后它能自动运行并且能够方便地查看运行日志。5.1 脚本权限与试运行首先给脚本添加可执行权限并手动运行一次测试基本功能。# 进入脚本所在目录例如 /home/pi/scripts cd /home/pi/scripts # 添加可执行权限 chmod x ping_the_thing.py # 首次试运行前台运行方便观察输出和错误 ./ping_the_thing.py运行后你应该能在终端看到类似以下的日志输出2023-10-27 14:30:01,123 - INFO - Ping The Thing 监控脚本启动。共监控 5 台设备。 2023-10-27 14:30:01,124 - INFO - 检查间隔300秒 失败阈值2次。 2023-10-27 14:30:01,124 - INFO - --- 开始本轮设备状态检查 --- 2023-10-27 14:30:04,567 - DEBUG - 主NAS 在线。 2023-10-27 14:30:07,890 - DEBUG - MQTT服务器 在线。 ... 2023-10-27 14:30:01,128 - INFO - --- 本轮检查完成 ---按CtrlC可以停止脚本。如果一切正常日志中没有报错并且你收到了测试邮件可以临时将一个不存在的IP加入监控列表触发告警说明脚本功能完好。5.2 创建Systemd服务推荐将脚本配置为Systemd服务是让它成为系统级后台守护进程的最佳方式。Systemd提供了强大的生命周期管理、日志集成journalctl、依赖关系和自动重启功能。创建服务单元文件sudo nano /etc/systemd/system/ping-the-thing.service写入以下服务配置[Unit] DescriptionPing The Thing - Network Device Monitor Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple Userpi Grouppi WorkingDirectory/home/pi/scripts # 修改为你的脚本所在目录 ExecStart/usr/bin/python3 /home/pi/scripts/ping_the_thing.py Restarton-failure RestartSec10 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target关键参数解析Afternetwork-online.target确保在网络就绪之后才启动本服务避免因网络未准备好而导致的误判。Userpi/Grouppi以普通用户pi身份运行而非root更安全。WorkingDirectory设置工作目录方便脚本处理相对路径如日志文件。Restarton-failure当脚本非正常退出返回非0码时自动重启。RestartSec10重启前等待10秒避免频繁重启循环。启用并启动服务# 重新加载systemd配置使其识别新服务 sudo systemctl daemon-reload # 设置开机自启 sudo systemctl enable ping-the-thing.service # 立即启动服务 sudo systemctl start ping-the-thing.service # 查看服务状态确认运行正常 sudo systemctl status ping-the-thing.service如果状态显示为active (running)说明服务已成功在后台运行。5.3 管理服务与查看日志服务化之后管理起来非常方便查看实时日志使用journalctl命令这是Systemd服务的统一日志管理器。# 查看服务的全部日志 sudo journalctl -u ping-the-thing.service # 查看最新日志并持续滚动输出类似 tail -f sudo journalctl -u ping-the-thing.service -f # 查看指定时间段的日志 sudo journalctl -u ping-the-thing.service --since 2023-10-27 14:00:00 --until 2023-10-27 15:00:00管理服务生命周期# 停止服务 sudo systemctl stop ping-the-thing.service # 重启服务修改脚本后常用 sudo systemctl restart ping-the-thing.service # 禁用开机自启 sudo systemctl disable ping-the-thing.service实操心得强烈推荐使用Systemd而非Cron。Cron适合定时执行独立任务而Systemd服务是常驻进程更容易管理状态、收集日志并且能更好地处理“网络就绪”这种启动依赖关系。journalctl的日志查询功能也比分散的Cron邮件或文件日志强大得多。6. 高级配置、优化与故障排查脚本和服务都能运行后我们可以根据实际需求进行优化并准备好应对可能出现的各种问题。6.1 监控参数调优指南配置文件中的几个数字对监控效果影响很大需要根据你的网络环境和设备特性进行调整。参数默认值调优建议场景说明PING_TIMEOUT2秒局域网1-2秒跨网段/复杂网络3-5秒等待单个Ping回复的最长时间。局域网内响应通常在毫秒级2秒足够。如果设备经过多个路由器或网速较慢可适当延长。PING_COUNT3次稳定性高的网络2次Wi-Fi/不稳定网络3-4次每次检查发送的Ping包数量。次数越多单次检查的结论越可靠但耗时也越长。3次是一个平衡点。CHECK_INTERVAL300秒 (5分钟)核心设备60-180秒普通设备300-600秒检查频率。对于NAS、服务器等核心设备可以缩短间隔以便更快发现故障。对于打印机、智能灯泡等可以放宽间隔。FAILURE_THRESHOLD2次抗误报优先3次快速响应优先1次连续失败多少次才告警。这是防误报的关键。家庭Wi-Fi环境可能存在偶发丢包设为2或3能有效过滤掉大部分瞬时故障。设为1则非常敏感可能产生较多误报。组合策略示例对于核心NASIP: 192.168.1.100CHECK_INTERVAL120(2分钟),FAILURE_THRESHOLD2。意味着每2分钟检查一次连续2次即4分钟内无响应就告警。对于客厅摄像头IP: 192.168.1.150连接Wi-FiCHECK_INTERVAL300(5分钟),FAILURE_THRESHOLD3。Wi-Fi可能不太稳定增加失败阈值到3次即连续15分钟离线再告警避免因信号波动频繁通知。注意你可以在DEVICES_TO_MONITOR字典中为每个设备单独定义一组参数但这需要修改脚本结构将配置从全局变量改为字典嵌套。对于初学者建议先使用全局参数运行稳定后再考虑按设备定制。6.2 常见问题与排查技巧实录即使配置得当在实际运行中也可能遇到各种问题。下面是我在长期使用中积累的排查经验。问题1脚本运行正常但从未收到过告警邮件即使故意拔掉设备网线。排查思路检查邮件发送基础首先手动测试msmtp配置是否真的能发邮件。echo Test Body | msmtp -a gmail your-emailexample.com替换为你配置的账户和收件邮箱。如果失败检查~/.msmtprc文件权限必须是600检查Gmail的应用专用密码是否正确检查网络是否能连接Gmail的SMTP服务器端口587。检查脚本日志查看journalctl日志确认脚本是否真的检测到了故障并执行了send_alert_email函数。日志中应有告警邮件已发送或发送邮件失败的记录。检查垃圾邮件箱告警邮件的发件人可能是你的邮箱地址但有些邮件服务商可能会将此类自动发送的邮件归类为垃圾邮件。问题2频繁收到误报警设备明明在线。排查思路检查Ping本身在树莓派上手动Ping一下那个IP观察延迟和丢包率。ping -c 10 192.168.1.150如果出现Request timeout或很高的延迟100ms说明网络连接本身不稳定可能是Wi-Fi信号弱、设备性能瓶颈或网络拥塞。调整监控参数这是最主要的手段。立即增大FAILURE_THRESHOLD比如从2调到3或4。同时可以考虑稍微增加CHECK_INTERVAL给网络更多恢复时间。检查设备防火墙确认被监控设备的防火墙没有屏蔽ICMP Echo RequestPing请求。有些安全级别较高的NAS或服务器系统可能默认禁Ping。问题3Systemd服务启动失败状态显示failed。排查思路查看详细错误信息sudo systemctl status ping-the-thing.service -l-l参数会显示完整的错误输出。常见原因路径错误WorkingDirectory或ExecStart中的路径不存在或脚本没有执行权限。确保路径正确并用chmod x给脚本授权。Python依赖缺失服务运行时可能找不到ping3库。尝试在服务配置的ExecStart前使用绝对路径的pip安装的库或者使用虚拟环境。更简单的方法是在系统全局安装sudo pip3 install ping3。权限问题脚本或日志文件 (/var/log/ping_the_thing.log) 需要写入权限。确保WorkingDirectory和日志文件所在目录对运行用户如pi可写。问题4如何监控非ICMP设备如仅开放特定端口的设备Ping的局限性在于它只能检查网络层连通性。如果你想监控一个Web服务器是否正常更准确的方法是检查它的HTTP端口如80或443。你可以修改ping_host函数或者新增一个check_port函数。例如使用Python的socket库进行TCP端口连接测试import socket def check_port(hostname: str, port: int, timeout5) - bool: 检查指定主机的TCP端口是否开放 try: sock socket.create_connection((hostname, port), timeouttimeout) sock.close() return True except (socket.timeout, ConnectionRefusedError, OSError): return False然后在设备列表和检查逻辑中为这类设备指定检查方式为check_port并传入端口号。这需要对脚本结构进行更大的改造将设备配置从简单的IP字典升级为包含检查类型和参数的字典。6.3 扩展思路从监控到自动化修复一个成熟的监控系统不仅要知道“病了”还能尝试“治”。我们可以扩展脚本在检测到故障后执行一些简单的恢复操作。请注意自动操作有风险务必谨慎仅适用于你非常了解且后果可控的场景。示例远程唤醒Wake-on-LAN如果你的台式机支持WOL并且因节能设置进入睡眠可以在检测到其离线时发送魔术包唤醒它。安装WOL工具sudo apt install wakeonlan在脚本中添加函数import subprocess def wake_on_lan(mac_address: str): 发送Wake-on-LAN魔术包 try: subprocess.run([wakeonlan, mac_address], checkTrue) logger.info(f已发送WOL魔术包至 {mac_address}) except subprocess.CalledProcessError as e: logger.error(f发送WOL失败: {e})在send_alert_email函数之后或在判定设备离线时调用此函数需要提前在配置中记录设备的MAC地址。示例通过智能插座重启设备如果设备连接在支持远程控制的智能插座上如通过MQTT或HTTP API控制可以在告警后脚本自动发送指令重启插座。重要警告自动化修复是一把双刃剑。务必设置严格的触发条件和次数限制避免因脚本误判或网络环路导致设备被频繁重启造成更大问题。建议初期仅用于告警稳定运行一段时间并对误报率有把握后再考虑添加简单的自动恢复功能。这个“Ping The Thing”项目从一个简单的需求出发逐步构建了一个稳定、可配置、易于维护的家庭网络设备监控系统。它没有复杂的界面却实实在在地解决了“设备离线了却不知道”的痛点。通过Systemd集成它变得像一项系统服务一样可靠。通过参数调优和日志分析你可以让它越来越精准地为你服务。