Python 爬虫项目 爬虫运行状态监控与异常告警

前言爬虫服务完成开发、定时部署与增量逻辑改造后便进入长期无人值守运行阶段。网络波动、目标站点反爬策略升级、数据库连接中断、程序逻辑报错、服务器资源耗尽等问题都会造成爬虫任务停滞、数据采集中断。若缺少完善的状态监控与异常告警体系故障往往会持续数小时甚至数日才被发现直接导致业务数据缺失、项目运营受损。爬虫运行状态监控覆盖任务启停、执行耗时、数据采集量、请求成功率、资源占用等多维度指标异常告警则能够在故障发生的第一时间推送消息至运维人员实现问题快速响应与处理。本文从监控指标设计、日志体系搭建、运行状态采集、异常捕获、多渠道告警实现、服务守护等维度展开讲解结合 Python 原生模块、第三方工具完成全流程代码落地同时拆解各模块底层运行原理适配单机爬虫、定时爬虫、增量爬虫等现有架构所有方案均可直接应用于生产环境。文中涉及的第三方库、工具均提供官方链接方便读者快速查阅文档与完成环境部署。相关依赖库官方链接requests网络请求基础库用于爬虫业务与告警接口调用https://requests.readthedocs.io/psutil系统资源监控库获取 CPU、内存、磁盘、进程状态https://pypi.org/project/psutil/loggingPython 内置日志模块实现分级日志记录与持久化https://docs.python.org/3/library/logging.htmltracebackPython 内置异常追踪模块抓取完整报错堆栈信息https://docs.python.org/3/library/traceback.htmlsmtplibPython 内置邮件发送模块实现邮件渠道告警https://docs.python.org/3/library/smtplib.htmldatetimePython 内置时间处理模块统计任务执行时长、记录时间节点https://docs.python.org/3/library/datetime.htmlthreadingPython 内置多线程模块实现后台常驻监控线程https://docs.python.org/3/library/threading.html一、爬虫监控体系整体规划1.1 核心监控指标分类监控指标是判断爬虫运行状态是否正常的依据结合爬虫业务特性与运维需求将指标划分为业务指标、程序指标、服务器资源指标三大类别不同类别指标对应不同的监控逻辑与告警规则下表为各类指标明细、采集方式与告警触发条件。表格指标分类具体监控项采集方式常规告警触发条件业务指标任务启动 / 停止状态程序内部埋点记录定时任务未按预期启动、任务无故终止业务指标单任务执行耗时时间戳差值计算执行耗时超出预设阈值判定为请求阻塞业务指标数据采集总量 / 新增量业务逻辑中计数统计连续多轮采集新增数据为 0判定数据源无更新或爬取失效业务指标网络请求成功率成功请求数 / 总请求数成功率低于 90%存在大面积访问异常程序指标代码运行异常全局异常捕获 堆栈抓取程序抛出运行时异常、函数调用报错程序指标数据库连接状态主动探活检测数据库连接失败、查询 / 写入操作报错程序指标进程存活状态进程 ID 轮询检测爬虫进程意外退出、被系统强制终止服务器资源指标CPU 使用率系统接口轮询采集瞬时 CPU 占用超过 85%持续 5 分钟以上服务器资源指标内存占用率系统接口轮询采集内存占用超过 90%存在内存泄漏风险服务器资源指标磁盘剩余空间系统接口轮询采集磁盘剩余空间低于 10%防止日志 / 数据写失败业务指标聚焦爬虫核心采集业务直接反映数据产出情况程序指标定位代码、第三方组件、中间件的运行故障服务器资源指标保障运行环境稳定三类指标结合可实现全方位状态感知。1.2 监控与告警整体架构一套完整的爬虫监控告警系统分为五层架构各层级各司其职形成数据采集、分析判断、消息推送的闭环架构逻辑适用于所有 Python 爬虫项目。 第一层为数据采集层通过代码埋点、第三方库、系统接口定时采集上文所列的各类监控指标原始数据是整个体系的数据来源。 第二层为数据存储层将采集到的指标数据、运行日志、异常信息进行持久化存储支持历史数据回溯、故障溯源常用载体为本地日志文件、SQLite、MySQL 数据库。 第三层为规则判断层预设各类指标的阈值与判定规则对实时采集的数据进行校验区分正常状态、预警状态、故障状态。 第四层为告警触发层当数据触碰预设告警规则时抓取异常详情、上下文日志、堆栈信息组装告警内容。 第五层为消息推送层对接不同告警渠道将告警信息推送至运维人员主流渠道包含日志文件、企业微信 / 钉钉机器人、邮件、短信等。该架构采用解耦设计采集逻辑、判断逻辑、推送逻辑相互独立后续可按需新增监控指标与告警渠道扩展性极强。1.3 日志系统监控数据的基础载体日志是爬虫监控的核心载体所有运行状态、异常信息、指标数据都会以日志形式留存。单纯使用print语句无法满足工程化运维需求必须基于 Pythonlogging模块搭建分级、分文件、按时间切割的标准日志体系。日志按照严重等级由低到高划分为 DEBUG、INFO、WARNING、ERROR、CRITICAL 五级爬虫项目常规使用 INFO 记录正常运行状态WARNING 记录潜在风险ERROR 与 CRITICAL 记录程序异常与严重故障。同时为避免单一日志文件体积无限膨胀采用按时间自动分割的日志策略按天生成独立日志文件并自动清理过期日志。二、标准化日志系统搭建实战日志是监控与故障排查的第一手资料本节实现分级日志 按时间切割 多文件分类的日志方案区分运行日志、错误日志、监控日志不同类型信息写入对应文件便于分类查阅。2.1 日志模块完整代码实现python运行import logging from logging.handlers import TimedRotatingFileHandler import os from datetime import datetime # 日志根目录 LOG_BASE_DIR ./spider_logs # 日志保留天数 LOG_SAVE_DAYS 7 # 创建日志目录 if not os.path.exists(LOG_BASE_DIR): os.mkdir(LOG_BASE_DIR) def init_logger(): 初始化全局日志配置 # 设置日志总级别 logger logging.getLogger(spider_monitor) logger.setLevel(logging.INFO) # 清除默认处理器避免重复输出 logger.handlers.clear() # 定义日志输出格式 log_format logging.Formatter( %(asctime)s - %(name)s - %(levelname)s - %(filename)s:%(lineno)d - %(message)s, datefmt%Y-%m-%d %H:%M:%S ) # 1. 控制台输出处理器用于本地调试 console_handler logging.StreamHandler() console_handler.setFormatter(log_format) logger.addHandler(console_handler) # 2. 全量日志文件按天切割保留7天 all_log_path os.path.join(LOG_BASE_DIR, spider_all.log) all_file_handler TimedRotatingFileHandler( filenameall_log_path, whenD, interval1, backupCountLOG_SAVE_DAYS, encodingutf-8 ) all_file_handler.setFormatter(log_format) logger.addHandler(all_file_handler) # 3. 错误日志文件仅记录ERROR及以上级别日志 error_log_path os.path.join(LOG_BASE_DIR, spider_error.log) error_file_handler TimedRotatingFileHandler( filenameerror_log_path, whenD, interval1, backupCountLOG_SAVE_DAYS, encodingutf-8 ) error_file_handler.setLevel(logging.ERROR) error_file_handler.setFormatter(log_format) logger.addHandler(error_file_handler) return logger # 全局日志实例 spider_logger init_logger()2.2 代码原理详解目录初始化代码首先判断日志根目录是否存在不存在则自动创建保证日志文件可正常写入避免路径不存在引发程序报错。TimedRotatingFileHandler 原理该处理器为 Python 标准日志切割工具whenD代表按天分割日志interval1表示每 1 天生成一个新日志文件backupCount7代表仅保留最近 7 天的日志文件自动删除过期文件控制磁盘占用。日志格式字段说明格式字符串中包含时间、日志名称、日志等级、代码文件名称、代码行号、日志内容出现异常时可直接定位到报错代码位置大幅提升排查效率。分级日志隔离单独创建错误日志文件只收录 ERROR、CRITICAL 级别的信息运维人员可直接查看错误日志快速定位故障无需在海量正常日志中筛选异常内容。多处理器协同同时配置控制台输出与文件输出本地开发调试时查看控制台线上运行时留存文件日志兼顾开发与运维场景。2.3 日志调用示例在爬虫业务代码中直接调用全局日志实例替代传统打印语句示例如下python运行import requests def demo_spider(): spider_logger.info(爬虫任务开始执行) try: resp requests.get(https://httpbin.org/get, timeout10) spider_logger.info(f网络请求成功状态码{resp.status_code}) except Exception as e: spider_logger.error(f网络请求失败异常信息{str(e)}, exc_infoTrue) if __name__ __main__: demo_spider()exc_infoTrue参数会在日志中附加简易异常信息结合后续traceback模块可输出完整堆栈是异常日志记录的标准用法。三、程序内部状态监控与异常捕获在日志体系基础上实现爬虫任务执行状态、运行耗时、数据统计、全局异常捕获等内部监控逻辑无需依赖第三方组件轻量化且兼容性强适配所有单机爬虫项目。3.1 任务执行耗时与数据量监控通过时间戳计算任务执行时长同时对采集数据条数、请求次数进行计数统计实时监控业务运行效率与数据产出。3.1.1 代码实现python运行import time import requests from datetime import datetime # 引入全局日志实例 from 上文代码 import spider_logger # 全局统计变量 TOTAL_REQUEST_COUNT 0 # 总请求次数 SUCCESS_REQUEST_COUNT 0 # 成功请求次数 NEW_DATA_COUNT 0 # 本轮新增数据条数 def spider_business_task(): 模拟爬虫核心业务逻辑 global TOTAL_REQUEST_COUNT, SUCCESS_REQUEST_COUNT, NEW_DATA_COUNT task_start_time time.time() spider_logger.info(新一轮爬虫任务启动) url_list [ https://httpbin.org/get, https://httpbin.org/headers, https://httpbin.org/ip ] for url in url_list: TOTAL_REQUEST_COUNT 1 try: resp requests.get(url, timeout8) SUCCESS_REQUEST_COUNT 1 # 模拟解析数据、判定增量、新增数据计数 NEW_DATA_COUNT 1 spider_logger.debug(f请求地址{url}响应正常) except Exception as e: spider_logger.warning(f请求地址{url} 访问失败异常{str(e)}) # 计算任务执行耗时 task_cost_time round(time.time() - task_start_time, 2) # 计算请求成功率 success_rate round(SUCCESS_REQUEST_COUNT / TOTAL_REQUEST_COUNT * 100, 2) if TOTAL_REQUEST_COUNT 0 else 0 # 输出本轮监控统计信息 spider_logger.info(f任务执行完成总耗时{task_cost_time} 秒) spider_logger.info(f总请求数{TOTAL_REQUEST_COUNT}成功请求数{SUCCESS_REQUEST_COUNT}请求成功率{success_rate}%) spider_logger.info(f本轮新增数据条数{NEW_DATA_COUNT}) # 阈值判断执行耗时超过5秒触发预警 if task_cost_time 5: spider_logger.warning(f任务执行耗时超标当前耗时{task_cost_time} 秒存在阻塞风险) # 阈值判断成功率低于90%触发预警 if success_rate 90: spider_logger.warning(f请求成功率过低当前成功率{success_rate}%访问异常增多) if __name__ __main__: spider_business_task()3.1.2 原理详解耗时统计原理在任务开始时记录时间戳任务结束后用当前时间戳减去起始时间戳得到任务总执行时长保留两位小数便于读取。数据计数逻辑使用全局变量统计请求次数、成功次数、新增数据量每完成一次请求、一条数据采集就对应累加实现全流程数据统计。阈值预警逻辑预设耗时、成功率阈值当统计数据超出范围时输出 WARNING 级别日志标记风险运维人员可通过日志快速识别异常状态。适用场景该方案属于代码埋点监控和爬虫业务深度结合无需额外服务是中小型爬虫项目首选方案。3.2 全局异常捕获与完整堆栈抓取普通异常捕获只能获取异常描述信息无法定位具体报错代码行结合traceback模块可抓取完整异常堆栈信息同时实现全局异常拦截避免单一报错导致整个爬虫服务终止。3.2.1 代码实现python运行import traceback import requests from functools import wraps from 上文代码 import spider_logger def global_exception_catch(func): 全局异常捕获装饰器 wraps(func) def wrapper(*args, **kwargs): try: return func(*args, **kwargs) except Exception as e: # 抓取完整异常堆栈 error_stack traceback.format_exc() spider_logger.critical(f函数 {func.__name__} 运行出现严重异常{str(e)}\n完整堆栈信息\n{error_stack}) return None return wrapper # 为爬虫任务添加异常捕获装饰器 global_exception_catch def error_test_spider(): # 模拟非法请求触发异常 resp requests.get(https://invalid-test-url-12345.com, timeout5) data resp.json() return data if __name__ __main__: error_test_spider()3.2.2 原理详解装饰器原理采用 Python 装饰器模式封装全局异常逻辑所有被装饰的函数执行时都会进入try-except代码块统一拦截异常无需在每个函数内重复编写异常捕获代码简化代码结构。traceback 模块作用traceback.format_exc()会捕获从异常触发点到调用链路的全部堆栈信息包含报错文件、代码行号、函数调用顺序是定位代码 BUG 的核心工具。日志级别区分严重运行异常使用 CRITICAL 级别日志区别于普通 ERROR 日志在日志文件中可快速筛选出致命故障。异常隔离特性装饰器捕获异常后函数返回空值不会向上抛出异常保证主线程、定时调度服务不会因为单个函数报错而整体崩溃实现异常隔离。3.3 APScheduler 定时任务状态监控结合前文定时爬虫框架对 APScheduler 任务进行状态监听感知任务启动、执行完成、异常报错等事件实现定时任务专属监控。3.3.1 代码实现python运行from apscheduler.schedulers.blocking import BlockingScheduler from apscheduler.events import EVENT_JOB_EXECUTED, EVENT_JOB_ERROR, EVENT_JOB_MISSED import requests from 上文代码 import spider_logger # 初始化调度器 scheduler BlockingScheduler() def scheduler_monitor_listener(event): 定时任务监听器监听任务各类事件 job_id event.job_id if event.job_id else 未知任务 # 任务正常执行完成 if event.code EVENT_JOB_EXECUTED: spider_logger.info(f定时任务 {job_id} 执行完成) # 任务执行报错 elif event.code EVENT_JOB_ERROR: spider_logger.error(f定时任务 {job_id} 执行异常异常信息{event.exception}) # 任务错过执行时间上一轮未完成下一轮已触发 elif event.code EVENT_JOB_MISSED: spider_logger.warning(f定时任务 {job_id} 错过执行时间存在任务阻塞) # 绑定监听器监听三大核心事件 scheduler.add_listener( scheduler_monitor_listener, EVENT_JOB_EXECUTED | EVENT_JOB_ERROR | EVENT_JOB_MISSED ) # 测试定时任务 def scheduler_test_task(): spider_logger.info(定时任务正在运行) requests.get(https://httpbin.org/get, timeout10) # 添加定时任务每2分钟执行一次 scheduler.add_job(scheduler_test_task, interval, minutes2, idmonitor_job_001) if __name__ __main__: spider_logger.info(带监控的定时爬虫服务启动) try: scheduler.start() except (KeyboardInterrupt, SystemExit): scheduler.shutdown() spider_logger.info(定时爬虫服务正常关闭)3.3.2 原理详解事件监听机制APScheduler 内置事件分发机制任务状态发生变化时会主动触发对应事件开发者通过绑定监听器即可感知状态。核心事件说明EVENT_JOB_EXECUTED代表任务正常结束EVENT_JOB_ERROR代表任务抛出异常EVENT_JOB_MISSED代表任务因阻塞错过执行时间是判断任务堆积的重要依据。任务 ID 定位通过任务唯一 ID 区分不同定时任务多任务场景下可精准定位出问题的任务监控粒度更精细。四、服务器资源与进程监控爬虫长期部署在服务器中运行进程意外退出、CPU / 内存占用过高、磁盘空间不足等环境问题会直接导致服务瘫痪。本节使用psutil库实现进程存活检测、系统资源监控同时搭建后台常驻监控线程不影响爬虫主业务运行。4.1 环境依赖安装执行以下命令安装系统监控库shellpip install psutil4.2 进程存活监控通过进程 ID 检测爬虫进程是否正常运行适用于服务器后台常驻的爬虫服务。4.2.1 代码实现python运行import psutil import time from 上文代码 import spider_logger def check_process_alive(pid): 检测指定PID的进程是否存活 try: # 根据PID获取进程对象 process psutil.Process(pid) # 判断进程是否处于运行状态 return process.is_running() except psutil.NoSuchProcess: return False except Exception as e: spider_logger.error(f进程检测异常{str(e)}) return False def process_monitor(pid, check_interval10): 后台进程监控循环默认10秒检测一次 spider_logger.info(f开始监控爬虫进程进程PID{pid}) while True: is_alive check_process_alive(pid) if not is_alive: spider_logger.critical(f警告爬虫进程 {pid} 已意外终止) break time.sleep(check_interval) if __name__ __main__: # 替换为实际爬虫进程PID TARGET_PID 12345 process_monitor(TARGET_PID)4.2.2 原理详解psutil 进程操作原理psutil.Process(pid)根据进程编号获取系统进程实例is_running()方法查询进程运行状态若 PID 不存在会抛出NoSuchProcess异常代表进程已退出。轮询检测机制采用循环轮询方式每隔指定时间检测一次进程状态一旦发现进程消失立即输出严重级别日志标记故障。使用方式线上部署时先通过ps、tasklist等系统命令获取爬虫进程 PID再传入监控函数实现常驻检测。4.3 系统资源监控CPU / 内存 / 磁盘实时采集服务器 CPU 使用率、内存占用、磁盘剩余空间设置阈值触发风险预警防止资源耗尽导致服务卡顿或宕机。4.3.1 代码实现python运行import psutil import time from 上文代码 import spider_logger # 资源阈值配置 CPU_THRESHOLD 85 # CPU使用率阈值 % MEM_THRESHOLD 90 # 内存使用率阈值 % DISK_THRESHOLD 10 # 磁盘剩余空间阈值 % def get_system_resource(): 获取服务器资源信息 # CPU使用率 cpu_percent psutil.cpu_percent(interval1) # 内存信息 mem_info psutil.virtual_memory() mem_percent mem_info.percent # 磁盘信息检测根目录 disk_info psutil.disk_usage(/) disk_free_percent disk_info.free / disk_info.total * 100 return cpu_percent, mem_percent, round(disk_free_percent, 2) def resource_monitor(interval30): 系统资源循环监控默认30秒采集一次 spider_logger.info(服务器资源监控已启动) while True: cpu, mem, disk_free get_system_resource() # 正常状态日志 spider_logger.info(f资源状态 - CPU{cpu}%内存{mem}%磁盘剩余{disk_free}%) # 阈值判断与预警 if cpu CPU_THRESHOLD: spider_logger.warning(fCPU使用率过高当前{cpu}%超出阈值 {CPU_THRESHOLD}%) if mem MEM_THRESHOLD: spider_logger.warning(f内存使用率过高当前{mem}%超出阈值 {MEM_THRESHOLD}%) if disk_free DISK_THRESHOLD: spider_logger.critical(f磁盘空间严重不足剩余空间仅{disk_free}%) time.sleep(interval) if __name__ __main__: resource_monitor()4.3.2 原理详解CPU 采集psutil.cpu_percent(interval1)会采样 1 秒内的 CPU 平均使用率数据更贴近真实运行状态。内存与磁盘采集virtual_memory()获取整机内存使用情况disk_usage()获取指定目录的磁盘总容量、已用容量、剩余容量计算剩余空间占比。阈值分级预警CPU、内存超标输出 WARNING 预警日志磁盘空间严重不足输出 CRITICAL 日志区分风险等级。轮询间隔设置资源监控无需高频采集30 秒至 1 分钟轮询一次即可减少监控本身的资源消耗。4.4 多线程整合监控服务将业务监控、进程监控、资源监控放在独立子线程中运行主线程专注爬虫业务实现监控与业务解耦。python运行import threading from 上文代码 import process_monitor, resource_monitor, demo_spider def start_all_monitor(): 启动所有监控线程 # 进程监控线程 pid_thread threading.Thread(targetprocess_monitor, args(12345,), daemonTrue) # 资源监控线程 res_thread threading.Thread(targetresource_monitor, daemonTrue) pid_thread.start() res_thread.start() spider_logger.info(所有监控线程启动完成) if __name__ __main__: # 启动监控 start_all_monitor() # 主线程运行爬虫业务 while True: demo_spider() time.sleep(60)设置daemonTrue守护线程属性主线程退出时监控线程自动销毁避免残留进程。五、多渠道异常告警推送实现日志与监控只能记录状态无法主动推送消息本节实现邮件告警、Webhook 机器人告警两大主流主动推送方案故障发生时第一时间将异常信息发送给运维人员。5.1 邮件告警实现基于 Python 内置smtplib与email模块实现邮件推送支持发送纯文本告警内容适用于各类服务器告警场景。5.1.1 代码实现python运行import smtplib from email.mime.text import MIMEText from email.header import Header from 上文代码 import spider_logger # 邮件配置信息 MAIL_HOST smtp.qq.com # 邮件服务器 MAIL_PORT 465 # SSL端口 MAIL_SENDER xxxqq.com # 发件邮箱 MAIL_AUTH_CODE 授权码 # 邮箱第三方登录授权码 MAIL_RECEIVER [yyyqq.com] # 收件人列表 def send_email_alarm(title, content): 发送邮件告警 try: # 构造邮件内容 msg MIMEText(content, plain, utf-8) msg[From] Header(f爬虫监控告警{MAIL_SENDER}) msg[To] Header(,.join(MAIL_RECEIVER)) msg[Subject] Header(title, utf-8) # 连接邮件服务器并发送 smtp smtplib.SMTP_SSL(MAIL_HOST, MAIL_PORT) smtp.login(MAIL_SENDER, MAIL_AUTH_CODE) smtp.sendmail(MAIL_SENDER, MAIL_RECEIVER, msg.as_string()) smtp.quit() spider_logger.info(告警邮件发送成功) return True except Exception as e: spider_logger.error(f邮件发送失败{str(e)}) return False # 告警触发示例 if __name__ __main__: alarm_title 爬虫任务运行异常 alarm_content 检测到定时爬虫请求成功率低于90%请及时排查 send_email_alarm(alarm_title, alarm_content)5.1.2 原理与配置说明SMTP 协议原理邮件发送基于 SMTP 邮件传输协议QQ 邮箱、网易邮箱等均提供第三方 SMTP 服务开启 POP3/SMTP 服务并获取授权码后方可使用。端口说明SSL 加密端口 465 为主流配置安全性更高优先使用该端口。调用时机在监控逻辑判断出故障后调用该函数推送告警邮件形成 “发现异常 - 记录日志 - 推送邮件” 的完整流程。5.2 企业微信 / 钉钉 Webhook 机器人告警企业内部运维主流使用即时通讯机器人推送告警响应速度远快于邮件原理为调用平台提供的 Webhook 接口通过requests发送 POST 请求推送消息。5.2.1 代码实现python运行import requests from 上文代码 import spider_logger # 机器人Webhook地址替换为自己的机器人链接 WEBHOOK_URL https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxxxxx def send_webhook_alarm(content): Webhook机器人推送告警 headers {Content-Type: application/json} post_data { msgtype: text, text: { content: f【爬虫监控告警】\n{content} } } try: resp requests.post(WEBHOOK_URL, jsonpost_data, headersheaders, timeout10) if resp.json().get(errcode) 0: spider_logger.info(机器人告警消息推送成功) return True else: spider_logger.warning(f机器人推送失败返回信息{resp.text}) return False except Exception as e: spider_logger.error(f调用Webhook接口异常{str(e)}) return False # 测试调用 if __name__ __main__: alarm_msg 爬虫进程意外退出请立即登录服务器检查 send_webhook_alarm(alarm_msg)5.2.2 原理说明Webhook 工作机制企业微信、钉钉创建群机器人后会生成唯一接口地址按照平台规定的 JSON 格式提交 POST 请求即可在群内推送文本消息。多渠道组合项目中可同时启用邮件 机器人双渠道告警机器人用于紧急故障即时通知邮件用于留存完整告警记录。六、告警规则整合与防骚扰优化6.1 告警规则整合将监控判断逻辑与告警推送逻辑结合形成完整闭环示例如下python运行# 在任务耗时超标时触发告警 if task_cost_time 5: warn_msg f任务执行耗时超标当前耗时{task_cost_time}秒 spider_logger.warning(warn_msg) send_webhook_alarm(warn_msg) send_email_alarm(爬虫耗时告警, warn_msg)6.2 告警防骚扰策略爬虫运行中可能出现瞬时网络波动、临时资源峰值频繁推送告警会造成运维干扰通过以下策略优化连续判定机制同一指标连续 3 次检测异常再触发告警忽略瞬时波动。告警冷却时间同一故障触发告警后设置 15~30 分钟冷却期冷却期内不再重复推送相同告警。分级告警普通预警仅记录日志严重故障才推送消息区分故障等级。