影刀RPA店群自动化运维实战：日志监控与自愈系统设计

影刀RPA店群自动化运维实战：日志监控与自愈系统设计

流程跑通了，只是自动化工程的开始。

能自己发现故障，自己修复，才算是把运维闭环了。

在店群自动化项目跑起来的前三个月，我们团队几乎每天都要手动重启几次执行机。
浏览器卡死、代理掉线、影刀流程偶发异常、窗口焦点丢失……这些问题单个拎出来都不致命，但叠在一起就变成了运维黑洞。

店铺数量突破50以后，人工盯着已经不现实了。
于是我们花了两周，搭建了一套以Python为核心的日志监控与自愈系统。
这篇文章就是对这套系统的完整复盘。

一、监控先行：别等用户告诉你系统坏了

做自动化的工程师往往有一个思维惯性：只要流程能跑，就认为系统正常。
但实际运行中，大量异常是“静默”的。

比如：

• 页面加载超时，影刀内部重试了三次，最终放弃，但主流程没有抛错
• • 浏览器内存泄漏，进程还在，但页面响应已经非常慢
• • 消息队列积压，任务排队超过30分钟还没执行
    这些情况，如果没有主动监控，运维根本无从知晓。
    

直到运营同事跑来问：“为什么今天这个店没上货？”才开始排查，业务影响已经造成。

所以我们的第一条原则：所有关键环节必须有显性指标暴露。

二、日志体系设计：结构化、可检索、轻量级

在这里插入图片描述

2.1 为什么不用影刀自带日志

影刀RPA本身有执行日志，但它是面向流程调试的，不是面向运维的。
存储在本地文件，格式不统一，多台执行机之间日志完全割裂。

要做集中监控，必须让所有节点产出统一格式的结构化日志，并汇入一个可检索的中心。

我们选型如下：

• 日志格式：JSON，一行一条
• • 日志采集：每个Worker节点安装Filebeat，监听影刀日志目录和Python调度代理日志
• • 日志存储：Elasticsearch
• • 日志可视化：Kibana + Grafana
    每条日志强制包含字段：

{"timestamp":"2026-06-02T08:15:22","level":"ERROR","worker_id":"node03","shop_id":"pdd_1032","task_id":"upload_20260602_001","component":"browser","message":"Page.crashed event received","extra":{"url":"...","retry_count":3}}```Python调度代理中，日志记录用标准库封装：```pythonimportloggingimportjson from datetimeimportdatetimeclassJsonLogger:def__init__(self,worker_id):self.worker_id=worker_id self.logger=logging.getLogger("agent")def_emit(self,level,message,**kwargs):record={"timestamp":datetime.utcnow().isoformat(),"level":level,"worker_id":self.worker_id,"message":message,**kwargs}self.logger.log(getattr(logging,level),json.dumps(record,default=str))deftask_event(self,task_id,shop_id,event,extra=None):self._emit("INFO",event,task_id=task_id,shop_id=shop_id,extra=extra or{})```所有业务行为全部走这个通道，确保日志可机读。 --- ## 三、健康检查模块：从被动等待到主动探测 仅仅收集日志还不够，很多异常根本不会产生日志。 比如执行机CPU被其他进程吃满，系统整体变慢，但没报错。 我们设计了一组主动健康探测器，每30秒运行一次，涵盖几个层面： | 探测项 | 方式 | 异常阈值 | |---|---|---| | 浏览器进程存活 | 检查chrome.exe进程是否存在 | 消失即异常 | | CDP协议响应 | 发送`Page.navigate`空请求 | 超时5秒 | | 磁盘空间 |`psutil.disk_usage`| 剩余<5GB | | 内存可用 |`psutil.virtual_memory`| 可用<2GB | | 代理连通性 | 通过代理访问检查URL | 超时3秒 |```pythonclassHealthChecker:def__init__(self,browser_pool,config):self.browser_pool=browser_pool self.config=config defrun_checks(self):results={}results['browser']=self._check_browsers()results['disk']=self._check_disk()results['memory']=self._check_memory()results['proxy']=self._check_proxy()returnresults def_check_browsers(self):dead_shops=[]forshop_id,instanceinself.browser_pool.get_all_instances().items():ifnot instance.is_alive():dead_shops.append(shop_id)returndead_shops def_check_memory(self):mem=psutil.virtual_memory()returnmem.available<self.config['memory_threshold_bytes']```探测结果统一写入Redis，并被监控看板实时读取。 **这个机制上线后，我们至少提前发现过十几次代理大规模掉线，避免了业务事故。** --- ## 四、自愈系统设计：能自动修的绝不人工碰 ### 4.1 自愈策略的定义 并不是所有异常都能自愈，但有很多可以。 我们梳理了常见的可自愈场景： - 浏览器实例假死 → 重启实例，从快照恢复环境 - - 代理IP失效 → 自动切换到备用代理 - - 单个任务偶发失败 → 重试（最多3次） - - Worker负载过高 → 暂停接收新任务，等待现有任务完成 - - 消息队列积压 → 触发动态扩容，启动预备Worker 这些策略被统一封装成“自愈规则”，由Python自愈引擎驱动。```pythonclassSelfHealingEngine:def__init__(self,worker_id,browser_pool,task_queue):self.worker_id=worker_id self.browser_pool=browser_pool self.task_queue=task_queue defevaluate(self,health_report):actions=[]# 规则1：浏览器假死forshop_idinhealth_report['browser']['dead']:actions.append(('restart_browser',shop_id))# 规则2：内存不足ifhealth_report['memory']:actions.append(('pause_task_accept',self.worker_id))returnactions defexecute(self,actions):foraction,targetinactions:ifaction=='restart_browser':self.browser_pool.restart_instance(target)logger.info(f"Self-healing: restart browser for {target}")elif action=='pause_task_accept':self.task_queue.pause_worker(self.worker_id)logger.warning(f"Worker {self.worker_id} paused due to low memory")```### 4.2 自愈的边界 自愈不能替代根因分析。 如果一个店铺连续触发三次浏览器重启，说明很可能不是浏览器问题，而是指纹环境或者平台改版。 此时自愈引擎会停止自动操作，升级为人工介入。 防止陷入“无限重启循环”。 > 这个边界很重要。我们在早期版本里没做次数限制，结果一个节点一晚上重启了同一个店铺的浏览器20次，第二天看日志才发现。 --- ## 五、告警系统：把信息推给对的人 自愈能解决一部分问题，但总有一些异常需要人类介入。 我们设计了一套分级告警机制。 **告警级别：** - **P0（紧急）**：Worker离线、数据库连接断开、全部代理失效 → 电话+企业微信 - - **P1（严重）**：单个店铺连续失败5次、队列积压超过20条 → 企业微信通知 - - **P2（警告）**：内存可用低于阈值、磁盘空间不足 → 邮件通知 - - **P3（信息）**：自愈操作记录、配置变更 → 日志存档，不通知 告警分发基于事件类型动态路由，避免告警风暴。```pythonclassAlertManager:defsend_alert(self,level,title,message,tags):iflevel=='P0':self._phone_call(title)self._wechat(title,message)elif level=='P1':self._wechat(title,message)elif level=='P2':self._email(title,message)#P3只记录```我们还加了一条人性化的规则：同一个店铺同一个错误类型，10分钟内只告警一次。 防止故障恢复期间重复轰炸。 --- ## 六、分布式监控与Master视角 多节点执行机下，每个Worker都运行着自己的监控Agent，但这只能看到局部。 我们需要一个Master节点，汇聚所有Worker的健康数据，做出全局决策。 Master上运行一个汇总服务，每10秒扫描Redis中Worker的心跳和健康报告。 一旦某个Worker心跳丢失超过2分钟，Master执行： 1. 将该Worker标记为`offline`2.2.重新调度它未完成的任务到其他Worker3.3.触发P0告警 全局视图也用于容量规划： 如果所有Worker的平均负载长期超过70%，Master会建议扩容。---## 七、Grafana看板：让状态一目了然 我们搭建了两个Grafana看板：-**运维看板**：展示所有Worker资源使用、浏览器实例状态、任务队列长度、今日自愈次数--**业务看板**：展示每个店铺今日任务成功/失败数、上货数量、异常日志 看板数据源来自Elasticsearch和Prometheus（通过Windows Exporter采集系统指标）。 这些看板让非技术同事也能看懂自动化系统当前是否健康，而不再需要跑来问“系统正常吗”。---## 八、写在最后 自动化系统的成熟度，不体现在它正常运行时多么顺滑。 而在于出现异常时，它能不能自己扛住，能不能第一时间让人知道。 日志、监控、自愈、告警，这四个环节环环相扣。 缺了任何一个，自动化规模越大，运维压力反而越大。>我们做自动化，终极目标不是替代人，而是把人从重复劳动和疲于救火中解放出来。>>一套好的运维体系，就是这目标最坚实的底座。---*作者：林焱*