简介面向IT运维与办公管理人员的打印机实时监控资源包围绕打印状态监测、耗材余量、打印队列、文档名称与份数统计等核心环节整理了实用的监控知识点与工具选型思路可帮助企业优化打印成本、减少设备故障停机。整套资源共106个文件以82个JSON文件和16个HTML文件为主辅以少量ZIP压缩包及版本发布元数据整体大小约2.25MB目录结构清晰适合按需查阅。目前已有2281人学习下载适合需要快速了解打印机监控方案或优化打印环境的读者。内容涵盖SNMP与WMI等远程监控技术、PaperCut等主流软件的功能对比以及故障预警、报表分析与隐私保护等实践要点能够为实际部署提供可直接参考的知识框架。 做“实时监控打印机状态”这个项目起因很朴素打印机平时不响一响就出事。我在的办公室打印机分布在好几层楼十几个工位隔三差五就有同事在群里喊“打印机连不上了”“又卡纸了”“打出来全是白的”。最开始我只能从座位上爬起来跑过去按面板、看指示灯、翻纸盒折腾半天才判断出缺纸、没粉还是网络断了。跑的次数多了我就想如果有双眼睛能7×24小时盯着每台打印机的状态在用户发现之前就报警那该多好。“实时监控打印机状态”并不是什么高深技术本质是把你办公环境里的网络打印机当成一台支持SNMP协议的网络设备来对待。任务拆开以后其实就三件事把每台打印机的状态读出来把状态变化和异常判断出来再把告警在第一时间推到该看的人手里。做完之后我能随时知道打印机是否在线、是空闲还是正在处理任务、有没有卡纸缺纸、墨粉余量还剩多少。这篇内容适合被打印问题反复折腾的IT运维也适合手里管着一堆设备、天天被同事拉着报修的行政或后勤同学。我会把取数思路、脚本和踩过的坑都写清楚你可以照着落地。1. 先从报修需求反推该监控什么、状态从哪来1.1 人肉巡检为什么必失败在动手写监控之前我其实先试过排班巡检每周拿一张Excel表去每台打印机前按一遍在“正常/异常”上打勾。结果发现效果很差。打印机很擅长“装死”白天一切正常晚上进入休眠第二天早晨第一波打印任务压过来时才出问题或者某个纸盒偶尔卡一次纸等值班同事走过去卡纸已经被下一个任务带走了。这类间歇性故障靠人肉巡检根本抓不到因为巡检是低频、点状的而异常往往发生在没人注意的瞬间。所以要监控第一件事不是选工具而是明确到底要抓哪些信号。我统计了办公室一个季度的打印报修记录把问题归了类基本都逃不出下面四类设备在线状态、引擎状态、耗材状态、打印队列状态。做了这个梳理之后后面选型、写脚本都变得非常清晰每一条告警都能对应到一类真实发生的用户故障。1.2 四类关键状态一张表说清楚我习惯把监控指标收敛成一张表每条指标回答一个问题指标类别典型指标对应故障在线状态设备是否可ping通、SNMP是否响应、Web端口是否开放断网、休眠、设备关机引擎状态卡纸、缺纸、前盖打开、定影故障设备报错、无法打印耗材状态墨粉余量、硒鼓寿命、废粉仓容量打印变淡、全白、无法继续队列状态作业数、当前作业状态、页数是否增长任务堆积、假死“正在打印”最初我只想做前三类觉得把设备本身盯住就够了。后来发现用户说“打不出来”的时候打印机面板可能显示一切正常但打印服务器的队列里卡了一个损坏的任务后面所有作业都堵着不动。所以队列状态必须纳入。倒过来说队列正常但设备离线也說明问题出在网络或设备本身。两类数据互相补充才能把一张完整的故障图拼出来。1.3 三条取数路线SNMP、队列、厂商接口取数路线我实际对比过三条。第一条是SNMP这是网络打印机的通用协议几乎所有带网卡的打印机都内置了SNMP代理。它的优势是标准统一你不用关心打印机是什么品牌通过标准OID就能读到设备状态、作业状态、耗材余量这些信息适合做跨品牌统一监控。缺点是不同厂商对部分OID的返回格式经常有“自由发挥”后面我会详细讲。第二条是打印服务器队列。Windows环境用PowerShell的Get-Printer、Get-PrintJob就能读队列和作业状态Linux环境则是lpstat -p -t。队列状态的优点是接近用户感受能不能打印看队列最直观缺点是不包含具体故障原因比如同样显示“打印出错”你没法从队列判断是卡纸还是没粉。第三条是厂商自己的接口或云平台比如惠普的企业管理平台、爱普生的云服务功能很全但基本只能管本品牌设备还要额外维护一套账号系统。在多品牌混用的办公室这条路线只适合做补充。1.4 我的组合方案SNMP为主队列兜底我的最终方案是“SNMP为主队列兜底”。正常情况下每30秒通过SNMP读一次设备状态和耗材信息把它当作第一判断依据一旦SNMP读到设备离线或异常立刻再查一次队列和网络连通性避免误判。如果办公室里有打印服务器比如Windows打印服务器或者Linux CUPS服务器我还会把队列里的作业数、当前作业状态一起抓进来。这套组合跑下来覆盖了用户能感知到的绝大多数打印故障而且没有依赖任何厂商云平台数据都在自己手里。组合方案看起来比单用一种方式复杂但实际落地并不难。核心就是写好一个采集脚本先从SNMP拿“设备怎么想”再从队列拿“用户看到什么”两边一交叉告警的准确率会高很多。这也是后面整套代码的骨架。2. 一套能直接复用的打印状态采集告警脚本2.1 先定采集口径轮询周期、重试策略、冷却时间动手写脚本前先把采集口径定下来。轮询周期我设成30秒因为打印机的状态变化属于慢变量卡纸、缺粉不会在几秒内发生30秒足够覆盖绝大多数异常又不会给打印机造成太大负担。SNMP请求的超时设为3秒重试1次这样单台设备最多耗时6秒左右几十台设备也能在一个轮询周期内跑完。另一个容易被忽略的问题是告警冷却。如果不做冷却一台卡纸的打印机会在每次30秒轮询时都触发出告警一个晚上就能把群聊刷爆。我的办法是同一台设备、同一类故障15分钟内不重复发告警只有状态恢复正常后才发送一条恢复通知之后下一次异常才能再次触发。这个“冷却恢复”的机制直接决定了监控脚本能不能真正用起来。2.2 核心代码读状态、判故障、发告警下面这套代码是从我实际运行版本里精简出来的核心逻辑是读取SNMP状态判断是否异常推送群机器人。依赖只有pysnmp和requests装好后即可运行。import time import requests from pysnmp.hlapi import * PRINTERS [ {name: 前台黑白, ip: 192.168.1.20, community: public}, {name: 财务室彩色, ip: 192.168.1.21, community: public}, ] WEBHOOK https://open.feishu.cn/open-apis/bot/v2/hook/your_webhook_id # Printer MIB 和 HOST-RESOURCES MIB 里的关键 OID HR_STATE_OID 1.3.6.1.2.1.25.3.2.1.5 # hrDeviceStatus PRT_STATE_OID 1.3.6.1.2.1.43.16.5.1.2.1.1 # prtGeneralStatus SUPPLY_OID 1.3.6.1.2.1.43.11.1.1.9.1 # prtMarkerSuppliesLevel def snmp_get(ip, oid, communitypublic): errorIndication, errorStatus, errorIndex, varBinds next( getCmd( SnmpEngine(), CommunityData(community, mpModel1), UdpTransportTarget((ip, 161), timeout3, retries1), ContextData(), ObjectType(ObjectIdentity(oid)), ) ) if errorIndication or errorStatus: return None return varBinds[0][1].prettyPrint() def send_alert(name, message): payload {msg_type: text, content: {text: f打印机告警: {name} {message}}} requests.post(WEBHOOK, jsonpayload, timeout5) last_alert_time {} def alert_once(name, message): now time.time() if now - last_alert_time.get(name, 0) 900: # 15分钟冷却 send_alert(name, message) last_alert_time[name] now while True: for p in PRINTERS: # 设备状态3 running 表示正常6 down 表示离线 hr_state snmp_get(p[ip], HR_STATE_OID .1, p[community]) # 打印机引擎状态3 空闲4 打印中5 停止/报错 prt_state snmp_get(p[ip], PRT_STATE_OID .1.1, p[community]) try: engine_state int(prt_state) except (TypeError, ValueError): engine_state None if hr_state is None: alert_once(p[name], SNMP无响应设备可能离线或休眠) elif engine_state 5: alert_once(p[name], 引擎处于停止状态请检查卡纸/缺纸/前盖) elif engine_state 4: pass # 打印中正常 time.sleep(30)这段代码的核心点是把状态值先转成数字再根据打印机MIB的定义判断。hrDeviceStatus取值中3代表running、6代表downprtGeneralStatus取值中3代表空闲、4代表处理中、5代表停止。需要提醒的是OID末尾的索引不一定固定为.1或.1.1不同品牌型号可能不同上线前先用snmpwalk -On把设备返回的真实OID列表导出来核对一遍再固化到脚本里。2.3 告警通道群机器人和邮件怎么接告警推送通道我首选飞书或钉钉的群机器人因为办公室同事都集中在群里一条消息能同时被行政、IT和维护人员看到。以飞书为例JSON格式是{msg_type: text, content: {text: ...}}代码里已经写好了。企业微信机器人格式略有不同需要把文本内容放在{msgtype: text, text: {content: ...}}里。如果办公室没有企业IM也可以用SMTP发邮件Python标准库smtplib就够但邮件的及时性不如群消息适合做每日汇总而不是实时告警。接群机器人时有个小坑Webhook地址本身是敏感信息不要直接写死在代码里再传到网上去建议用环境变量或单独的配置文件加载。另外第一次接入后先在命令行手工调用一次send_alert确认消息能真正发出来再挂到主循环里否则排错会和打印故障混在一起很难定位。2.4 部署时容易被忽略的三个点第一脚本必须跑在一台长期开机的稳定机器上别放在某台员工的办公电脑里更不要放在要监控的打印机旁边否则打印机断电的时候监控也跟着断了。建议放到一台内网Linux虚机或旧电脑上用systemd或supervisor守护进程管起来。第二日志要落盘并轮转脚本里加上logging模块记录每次采集的状态、告警事件后面排查问题才有的放矢。第三监控机不要和打印机接在同一个二层广播域里倒是没有强制要求只要路由能通、SNMP端口能访问就行但一定要单独记录异常避免网络抖动时监控自身也跟着“假死”。3. 监控跑起来之后最容易翻车的五个细节3.1 打印机休眠SNMP无响应不等于离线这是上线后第一个大坑。打印机为了环保默认会在一段时间无操作后进入省电模式网卡也可能暂停SNMP响应。脚本一开始只是发现SNMP超时就判定离线结果每天早上都会收到一堆“离线”告警。实际跑过去看打印机面板是暗的但按一下任意键就能立刻唤醒。这个问题不能靠提高重试次数解决因为打印机在深睡模式下可能压根不响应UDP包。后来的处理是把超时放宽到3秒、重试2次并且在SNMP超时时额外探测一次打印机的Web管理端口比如常见的9100打印端口或HTTP管理页面。如果Web端口能通就判定为“休眠而非离线”只记录日志不告警。另外我在代码里把SNMP超时导致连续2次无响应才判定离线单独一次超时只算“可疑”这个策略让误报率下降了很多。3.2 厂商对标准OID的“自由发挥”SNMP标准MIB虽然统一但具体厂商实现时总会有点“私货”。就拿耗材余量prtMarkerSuppliesLevel来说有的品牌直接返回0到100的百分比有的返回-2表示低、-3表示空还有的返回剩余page数。更麻烦的是同一台打印机有多个耗材对象黑色硒鼓、彩色硒鼓、废粉盒各有不同的索引索引顺序还不一定固定。如果脚本按固定OID硬编码很快就会遇到“这台读到了、那台读不到”的情况。最好用的办法是先做一次设备体检用snmpwalk把每台打印机的相关OID全量导出来存成快照。然后对照快照确认第一MIB实现是否符合标准定义第二耗材索引具体是多少第三返回值的单位是什么。把这些差异固化到配置里脚本才能跨品牌稳定运行。我最后维护了一个model_oids.json里面记录每个型号的OID差异新增设备时先查一遍比每次现场排查快得多。3.3 队列显示“正在打印”设备却已卡死SNMP和队列数据交叉时会出现一种很迷惑的情况设备状态看起来正常队列里有一个作业一直显示“正在打印”但打印机的页面计数器已经几分钟没动了。这种假死的原因通常是打印任务进入了不可中断状态Linux里叫job holdWindows里叫deleting后端渲染或者驱动异常导致作业卡住。我的判断逻辑是连续两次采集之间打印机的总页数prtMarkerCounterLifeCount或厂商MIB里的累计页数没有任何增长且队列里存在“正在打印”状态的作业超过3分钟就判定为“打印假死”。这时候告警比单纯看设备状态准得多。恢复操作是重启打印服务Windows下重启Spooler服务Linux CUPS下用cupsdisable和cupsenable组合但操作前一定要确认没有正在打印的真实作业否则会误杀。3.4 告警风暴和抖动少发比多发更有效告警冷却机制虽然能避免刷屏但还有一个“抖动”问题。打印机卡纸被取走后设备状态从“停止”恢复到“空闲”紧接着又卡了一次纸这时候如果冷却时间已过又会发一条告警。用户可能正心烦连收两条同样的卡纸消息维护人员也容易麻木。后来我把判定改成“异常状态连续出现3次且持续超过1分钟才正式告警”也就是30秒轮询需要3个连续周期都异常才认定是稳定故障。这个“连续N次”的机制会让告警延迟一到两分钟但换来的准确率非常值得。另一个处理是恢复通知。设备恢复后给群里发一条“XX打印机已恢复正常打印”的消息既告诉大家不用再重复报修也让值班同事确认这台设备真的处理完了。恢复通知和告警通知一样也要走冷却和连续判定逻辑否则设备偶尔抖动一下群里同样会被刷屏。3.5 别忘了先梳理网络和SNMP配置很多打印机拿到手以后网络安全策略默认不允许别的终端直接访问或者把打印机划分到了独立的VLAN里。监控机如果和打印机不在同一网络段又没开路由策略SNMP请求根本发不过去。还有一部分打印机出厂时SNMP community是public但管理员因为安全要求改成了别的值如果脚本里没有同步修改采集就会失败。我建设监控第一周就遇到过某栋楼的打印机全部无法采集。排查后发现是那栋楼新换了交换机设备被隔离在办公VLAN里监控机所在的运维VLAN没有访问权限。所以上线前必须做两件事把监控机和所有打印机之间的网络连通性测一遍整理一份SNMP community清单。内网环境下用SNMP v2c的public其实很常见但如果公司安全要求高建议开启SNMP v3用认证加密保护数据。4. 从“看到异常”到“尽量自愈”监控体系的进阶4.1 告警分级把不同消息送到不同渠道当监控设备超过十几台之后所有告警都往一个群里发维护人员很快会失去耐心。我的做法是把告警分为三级。P3是低优先级比如墨粉余量低于15%、硒鼓快到寿命这种问题可以提前规划采购每天汇总一次推送就行。P2是中优先级比如卡纸、缺纸、前盖打开这类问题需要尽快处理推送到运维群并值班同事。P1是高优先级比如设备离线、打印服务崩溃、队列假死超过阈值这种直接影响业务要立即处理可以额外通过短信或电话接口转给值班人。分级不是简单加个字段而是把告警触发逻辑重新设计了一遍。同一台打印机连续卡纸三次每一条都推P2会打扰人所以我在P2上加了频率限制比如1小时内只推一次。P1可以适当允许重复但也要有上限避免真的故障起来后变成“告警轰炸”。4.2 自动恢复要克制加一个“人工复核”按钮监控做到后期大家自然想省事让系统自动处理简单故障。比如检测到Spooler卡死后自动执行Restart-Service Spooler -Force检测到CUPS队列异常自动执行cupsenable printername。这些操作在80%的场景下有效但剩下的20%可能会导致更严重的后果比如正在打印的真实作业被强行终止或者打印机正在校准固件时被重启。所以我给自动恢复做了一个折中只对“可逆问题”自动处理比如重启打印服务、发送唤醒包、清空假死作业对“不可逆问题”一律只告警不处理比如卡纸、硬件故障、墨盒耗尽。自动操作执行前必须检查最近10分钟内是否有新作业到达、当前作业是否为空。而且每次自动操作后要把操作记录写进日志后续复盘时能看到它做了什么、为什么做。给系统加一个“人工复核”开关打开后自动操作只生成建议文案由值班人点击执行虽然多一步但安全得多。4.3 监控数据的二次价值故障统计与耗材预测状态数据只要落库价值就远不止实时告警。我把每天的采集数据存进InfluxDB再用Grafana做了一些简单的统计面板发现两件有意思的事某型号打印机卡纸率明显高于其他型号后来查出是纸盒搓纸轮老化问题很集中另外通过每晚记录的墨粉余量可以拟合出每台打印机的墨粉消耗速度提前一两周知道哪天需要换粉采购计划好做了很多。这些数据还能反过来修正监控阈值。比如某台打印机的墨粉余量长期在10%附近波动但实际还能打很多天初始设置的15%阈值就会频繁告警。有了历史数据后我可以把阈值改成“余量低于10%且下降速度超过每天2%”才告警告警数量大大减少准确率反而更高。数据沉淀是监控系统最容易被忽视的价值它让“监控”从被动响应变成了主动预防。5. 到底要不要上重型平台我的选型建议5.1 小规模场景脚本就够别自找麻烦如果你的办公室只有三五台打印机人也很少我建议直接用上面这套脚本加群机器人不用引入任何商业监控软件。理由很简单打印机数量少的时候脚本的维护成本极低新增一台设备只要往列表里加一行而重型平台光安装、调模板、学操作就要花掉大半天遇到问题还要查文档性价比非常低。脚本的缺陷是没有历史报表和自动化拓扑发现但小场景下这些功能根本用不上。这里也提醒一点即便是脚本也要考虑“留一手”。我一开始只把打印机IP硬编码在列表里后来打印机换网段、换IP改起来很麻烦。后来我改成了配置文件或数据库保存设备清单并加了资产编号、品牌型号、所在位置这些字段。后续不管是用脚本还是迁移到平台这些资产数据都能直接复用不用重新录入。5.2 中大规模场景成熟平台更省力打印机超过几十台或者有多地点、多部门的集中管理需求时脚本会越写越重这时候就该考虑Zabbix、PRTG、Nagios这类通用监控平台。它们自带SNMP模板可以本文还有配套的精品资源点击获取 用SNMP实现打印机实时状态监控与自动告警的实战指南
简介面向IT运维与办公管理人员的打印机实时监控资源包围绕打印状态监测、耗材余量、打印队列、文档名称与份数统计等核心环节整理了实用的监控知识点与工具选型思路可帮助企业优化打印成本、减少设备故障停机。整套资源共106个文件以82个JSON文件和16个HTML文件为主辅以少量ZIP压缩包及版本发布元数据整体大小约2.25MB目录结构清晰适合按需查阅。目前已有2281人学习下载适合需要快速了解打印机监控方案或优化打印环境的读者。内容涵盖SNMP与WMI等远程监控技术、PaperCut等主流软件的功能对比以及故障预警、报表分析与隐私保护等实践要点能够为实际部署提供可直接参考的知识框架。 做“实时监控打印机状态”这个项目起因很朴素打印机平时不响一响就出事。我在的办公室打印机分布在好几层楼十几个工位隔三差五就有同事在群里喊“打印机连不上了”“又卡纸了”“打出来全是白的”。最开始我只能从座位上爬起来跑过去按面板、看指示灯、翻纸盒折腾半天才判断出缺纸、没粉还是网络断了。跑的次数多了我就想如果有双眼睛能7×24小时盯着每台打印机的状态在用户发现之前就报警那该多好。“实时监控打印机状态”并不是什么高深技术本质是把你办公环境里的网络打印机当成一台支持SNMP协议的网络设备来对待。任务拆开以后其实就三件事把每台打印机的状态读出来把状态变化和异常判断出来再把告警在第一时间推到该看的人手里。做完之后我能随时知道打印机是否在线、是空闲还是正在处理任务、有没有卡纸缺纸、墨粉余量还剩多少。这篇内容适合被打印问题反复折腾的IT运维也适合手里管着一堆设备、天天被同事拉着报修的行政或后勤同学。我会把取数思路、脚本和踩过的坑都写清楚你可以照着落地。1. 先从报修需求反推该监控什么、状态从哪来1.1 人肉巡检为什么必失败在动手写监控之前我其实先试过排班巡检每周拿一张Excel表去每台打印机前按一遍在“正常/异常”上打勾。结果发现效果很差。打印机很擅长“装死”白天一切正常晚上进入休眠第二天早晨第一波打印任务压过来时才出问题或者某个纸盒偶尔卡一次纸等值班同事走过去卡纸已经被下一个任务带走了。这类间歇性故障靠人肉巡检根本抓不到因为巡检是低频、点状的而异常往往发生在没人注意的瞬间。所以要监控第一件事不是选工具而是明确到底要抓哪些信号。我统计了办公室一个季度的打印报修记录把问题归了类基本都逃不出下面四类设备在线状态、引擎状态、耗材状态、打印队列状态。做了这个梳理之后后面选型、写脚本都变得非常清晰每一条告警都能对应到一类真实发生的用户故障。1.2 四类关键状态一张表说清楚我习惯把监控指标收敛成一张表每条指标回答一个问题指标类别典型指标对应故障在线状态设备是否可ping通、SNMP是否响应、Web端口是否开放断网、休眠、设备关机引擎状态卡纸、缺纸、前盖打开、定影故障设备报错、无法打印耗材状态墨粉余量、硒鼓寿命、废粉仓容量打印变淡、全白、无法继续队列状态作业数、当前作业状态、页数是否增长任务堆积、假死“正在打印”最初我只想做前三类觉得把设备本身盯住就够了。后来发现用户说“打不出来”的时候打印机面板可能显示一切正常但打印服务器的队列里卡了一个损坏的任务后面所有作业都堵着不动。所以队列状态必须纳入。倒过来说队列正常但设备离线也說明问题出在网络或设备本身。两类数据互相补充才能把一张完整的故障图拼出来。1.3 三条取数路线SNMP、队列、厂商接口取数路线我实际对比过三条。第一条是SNMP这是网络打印机的通用协议几乎所有带网卡的打印机都内置了SNMP代理。它的优势是标准统一你不用关心打印机是什么品牌通过标准OID就能读到设备状态、作业状态、耗材余量这些信息适合做跨品牌统一监控。缺点是不同厂商对部分OID的返回格式经常有“自由发挥”后面我会详细讲。第二条是打印服务器队列。Windows环境用PowerShell的Get-Printer、Get-PrintJob就能读队列和作业状态Linux环境则是lpstat -p -t。队列状态的优点是接近用户感受能不能打印看队列最直观缺点是不包含具体故障原因比如同样显示“打印出错”你没法从队列判断是卡纸还是没粉。第三条是厂商自己的接口或云平台比如惠普的企业管理平台、爱普生的云服务功能很全但基本只能管本品牌设备还要额外维护一套账号系统。在多品牌混用的办公室这条路线只适合做补充。1.4 我的组合方案SNMP为主队列兜底我的最终方案是“SNMP为主队列兜底”。正常情况下每30秒通过SNMP读一次设备状态和耗材信息把它当作第一判断依据一旦SNMP读到设备离线或异常立刻再查一次队列和网络连通性避免误判。如果办公室里有打印服务器比如Windows打印服务器或者Linux CUPS服务器我还会把队列里的作业数、当前作业状态一起抓进来。这套组合跑下来覆盖了用户能感知到的绝大多数打印故障而且没有依赖任何厂商云平台数据都在自己手里。组合方案看起来比单用一种方式复杂但实际落地并不难。核心就是写好一个采集脚本先从SNMP拿“设备怎么想”再从队列拿“用户看到什么”两边一交叉告警的准确率会高很多。这也是后面整套代码的骨架。2. 一套能直接复用的打印状态采集告警脚本2.1 先定采集口径轮询周期、重试策略、冷却时间动手写脚本前先把采集口径定下来。轮询周期我设成30秒因为打印机的状态变化属于慢变量卡纸、缺粉不会在几秒内发生30秒足够覆盖绝大多数异常又不会给打印机造成太大负担。SNMP请求的超时设为3秒重试1次这样单台设备最多耗时6秒左右几十台设备也能在一个轮询周期内跑完。另一个容易被忽略的问题是告警冷却。如果不做冷却一台卡纸的打印机会在每次30秒轮询时都触发出告警一个晚上就能把群聊刷爆。我的办法是同一台设备、同一类故障15分钟内不重复发告警只有状态恢复正常后才发送一条恢复通知之后下一次异常才能再次触发。这个“冷却恢复”的机制直接决定了监控脚本能不能真正用起来。2.2 核心代码读状态、判故障、发告警下面这套代码是从我实际运行版本里精简出来的核心逻辑是读取SNMP状态判断是否异常推送群机器人。依赖只有pysnmp和requests装好后即可运行。import time import requests from pysnmp.hlapi import * PRINTERS [ {name: 前台黑白, ip: 192.168.1.20, community: public}, {name: 财务室彩色, ip: 192.168.1.21, community: public}, ] WEBHOOK https://open.feishu.cn/open-apis/bot/v2/hook/your_webhook_id # Printer MIB 和 HOST-RESOURCES MIB 里的关键 OID HR_STATE_OID 1.3.6.1.2.1.25.3.2.1.5 # hrDeviceStatus PRT_STATE_OID 1.3.6.1.2.1.43.16.5.1.2.1.1 # prtGeneralStatus SUPPLY_OID 1.3.6.1.2.1.43.11.1.1.9.1 # prtMarkerSuppliesLevel def snmp_get(ip, oid, communitypublic): errorIndication, errorStatus, errorIndex, varBinds next( getCmd( SnmpEngine(), CommunityData(community, mpModel1), UdpTransportTarget((ip, 161), timeout3, retries1), ContextData(), ObjectType(ObjectIdentity(oid)), ) ) if errorIndication or errorStatus: return None return varBinds[0][1].prettyPrint() def send_alert(name, message): payload {msg_type: text, content: {text: f打印机告警: {name} {message}}} requests.post(WEBHOOK, jsonpayload, timeout5) last_alert_time {} def alert_once(name, message): now time.time() if now - last_alert_time.get(name, 0) 900: # 15分钟冷却 send_alert(name, message) last_alert_time[name] now while True: for p in PRINTERS: # 设备状态3 running 表示正常6 down 表示离线 hr_state snmp_get(p[ip], HR_STATE_OID .1, p[community]) # 打印机引擎状态3 空闲4 打印中5 停止/报错 prt_state snmp_get(p[ip], PRT_STATE_OID .1.1, p[community]) try: engine_state int(prt_state) except (TypeError, ValueError): engine_state None if hr_state is None: alert_once(p[name], SNMP无响应设备可能离线或休眠) elif engine_state 5: alert_once(p[name], 引擎处于停止状态请检查卡纸/缺纸/前盖) elif engine_state 4: pass # 打印中正常 time.sleep(30)这段代码的核心点是把状态值先转成数字再根据打印机MIB的定义判断。hrDeviceStatus取值中3代表running、6代表downprtGeneralStatus取值中3代表空闲、4代表处理中、5代表停止。需要提醒的是OID末尾的索引不一定固定为.1或.1.1不同品牌型号可能不同上线前先用snmpwalk -On把设备返回的真实OID列表导出来核对一遍再固化到脚本里。2.3 告警通道群机器人和邮件怎么接告警推送通道我首选飞书或钉钉的群机器人因为办公室同事都集中在群里一条消息能同时被行政、IT和维护人员看到。以飞书为例JSON格式是{msg_type: text, content: {text: ...}}代码里已经写好了。企业微信机器人格式略有不同需要把文本内容放在{msgtype: text, text: {content: ...}}里。如果办公室没有企业IM也可以用SMTP发邮件Python标准库smtplib就够但邮件的及时性不如群消息适合做每日汇总而不是实时告警。接群机器人时有个小坑Webhook地址本身是敏感信息不要直接写死在代码里再传到网上去建议用环境变量或单独的配置文件加载。另外第一次接入后先在命令行手工调用一次send_alert确认消息能真正发出来再挂到主循环里否则排错会和打印故障混在一起很难定位。2.4 部署时容易被忽略的三个点第一脚本必须跑在一台长期开机的稳定机器上别放在某台员工的办公电脑里更不要放在要监控的打印机旁边否则打印机断电的时候监控也跟着断了。建议放到一台内网Linux虚机或旧电脑上用systemd或supervisor守护进程管起来。第二日志要落盘并轮转脚本里加上logging模块记录每次采集的状态、告警事件后面排查问题才有的放矢。第三监控机不要和打印机接在同一个二层广播域里倒是没有强制要求只要路由能通、SNMP端口能访问就行但一定要单独记录异常避免网络抖动时监控自身也跟着“假死”。3. 监控跑起来之后最容易翻车的五个细节3.1 打印机休眠SNMP无响应不等于离线这是上线后第一个大坑。打印机为了环保默认会在一段时间无操作后进入省电模式网卡也可能暂停SNMP响应。脚本一开始只是发现SNMP超时就判定离线结果每天早上都会收到一堆“离线”告警。实际跑过去看打印机面板是暗的但按一下任意键就能立刻唤醒。这个问题不能靠提高重试次数解决因为打印机在深睡模式下可能压根不响应UDP包。后来的处理是把超时放宽到3秒、重试2次并且在SNMP超时时额外探测一次打印机的Web管理端口比如常见的9100打印端口或HTTP管理页面。如果Web端口能通就判定为“休眠而非离线”只记录日志不告警。另外我在代码里把SNMP超时导致连续2次无响应才判定离线单独一次超时只算“可疑”这个策略让误报率下降了很多。3.2 厂商对标准OID的“自由发挥”SNMP标准MIB虽然统一但具体厂商实现时总会有点“私货”。就拿耗材余量prtMarkerSuppliesLevel来说有的品牌直接返回0到100的百分比有的返回-2表示低、-3表示空还有的返回剩余page数。更麻烦的是同一台打印机有多个耗材对象黑色硒鼓、彩色硒鼓、废粉盒各有不同的索引索引顺序还不一定固定。如果脚本按固定OID硬编码很快就会遇到“这台读到了、那台读不到”的情况。最好用的办法是先做一次设备体检用snmpwalk把每台打印机的相关OID全量导出来存成快照。然后对照快照确认第一MIB实现是否符合标准定义第二耗材索引具体是多少第三返回值的单位是什么。把这些差异固化到配置里脚本才能跨品牌稳定运行。我最后维护了一个model_oids.json里面记录每个型号的OID差异新增设备时先查一遍比每次现场排查快得多。3.3 队列显示“正在打印”设备却已卡死SNMP和队列数据交叉时会出现一种很迷惑的情况设备状态看起来正常队列里有一个作业一直显示“正在打印”但打印机的页面计数器已经几分钟没动了。这种假死的原因通常是打印任务进入了不可中断状态Linux里叫job holdWindows里叫deleting后端渲染或者驱动异常导致作业卡住。我的判断逻辑是连续两次采集之间打印机的总页数prtMarkerCounterLifeCount或厂商MIB里的累计页数没有任何增长且队列里存在“正在打印”状态的作业超过3分钟就判定为“打印假死”。这时候告警比单纯看设备状态准得多。恢复操作是重启打印服务Windows下重启Spooler服务Linux CUPS下用cupsdisable和cupsenable组合但操作前一定要确认没有正在打印的真实作业否则会误杀。3.4 告警风暴和抖动少发比多发更有效告警冷却机制虽然能避免刷屏但还有一个“抖动”问题。打印机卡纸被取走后设备状态从“停止”恢复到“空闲”紧接着又卡了一次纸这时候如果冷却时间已过又会发一条告警。用户可能正心烦连收两条同样的卡纸消息维护人员也容易麻木。后来我把判定改成“异常状态连续出现3次且持续超过1分钟才正式告警”也就是30秒轮询需要3个连续周期都异常才认定是稳定故障。这个“连续N次”的机制会让告警延迟一到两分钟但换来的准确率非常值得。另一个处理是恢复通知。设备恢复后给群里发一条“XX打印机已恢复正常打印”的消息既告诉大家不用再重复报修也让值班同事确认这台设备真的处理完了。恢复通知和告警通知一样也要走冷却和连续判定逻辑否则设备偶尔抖动一下群里同样会被刷屏。3.5 别忘了先梳理网络和SNMP配置很多打印机拿到手以后网络安全策略默认不允许别的终端直接访问或者把打印机划分到了独立的VLAN里。监控机如果和打印机不在同一网络段又没开路由策略SNMP请求根本发不过去。还有一部分打印机出厂时SNMP community是public但管理员因为安全要求改成了别的值如果脚本里没有同步修改采集就会失败。我建设监控第一周就遇到过某栋楼的打印机全部无法采集。排查后发现是那栋楼新换了交换机设备被隔离在办公VLAN里监控机所在的运维VLAN没有访问权限。所以上线前必须做两件事把监控机和所有打印机之间的网络连通性测一遍整理一份SNMP community清单。内网环境下用SNMP v2c的public其实很常见但如果公司安全要求高建议开启SNMP v3用认证加密保护数据。4. 从“看到异常”到“尽量自愈”监控体系的进阶4.1 告警分级把不同消息送到不同渠道当监控设备超过十几台之后所有告警都往一个群里发维护人员很快会失去耐心。我的做法是把告警分为三级。P3是低优先级比如墨粉余量低于15%、硒鼓快到寿命这种问题可以提前规划采购每天汇总一次推送就行。P2是中优先级比如卡纸、缺纸、前盖打开这类问题需要尽快处理推送到运维群并值班同事。P1是高优先级比如设备离线、打印服务崩溃、队列假死超过阈值这种直接影响业务要立即处理可以额外通过短信或电话接口转给值班人。分级不是简单加个字段而是把告警触发逻辑重新设计了一遍。同一台打印机连续卡纸三次每一条都推P2会打扰人所以我在P2上加了频率限制比如1小时内只推一次。P1可以适当允许重复但也要有上限避免真的故障起来后变成“告警轰炸”。4.2 自动恢复要克制加一个“人工复核”按钮监控做到后期大家自然想省事让系统自动处理简单故障。比如检测到Spooler卡死后自动执行Restart-Service Spooler -Force检测到CUPS队列异常自动执行cupsenable printername。这些操作在80%的场景下有效但剩下的20%可能会导致更严重的后果比如正在打印的真实作业被强行终止或者打印机正在校准固件时被重启。所以我给自动恢复做了一个折中只对“可逆问题”自动处理比如重启打印服务、发送唤醒包、清空假死作业对“不可逆问题”一律只告警不处理比如卡纸、硬件故障、墨盒耗尽。自动操作执行前必须检查最近10分钟内是否有新作业到达、当前作业是否为空。而且每次自动操作后要把操作记录写进日志后续复盘时能看到它做了什么、为什么做。给系统加一个“人工复核”开关打开后自动操作只生成建议文案由值班人点击执行虽然多一步但安全得多。4.3 监控数据的二次价值故障统计与耗材预测状态数据只要落库价值就远不止实时告警。我把每天的采集数据存进InfluxDB再用Grafana做了一些简单的统计面板发现两件有意思的事某型号打印机卡纸率明显高于其他型号后来查出是纸盒搓纸轮老化问题很集中另外通过每晚记录的墨粉余量可以拟合出每台打印机的墨粉消耗速度提前一两周知道哪天需要换粉采购计划好做了很多。这些数据还能反过来修正监控阈值。比如某台打印机的墨粉余量长期在10%附近波动但实际还能打很多天初始设置的15%阈值就会频繁告警。有了历史数据后我可以把阈值改成“余量低于10%且下降速度超过每天2%”才告警告警数量大大减少准确率反而更高。数据沉淀是监控系统最容易被忽视的价值它让“监控”从被动响应变成了主动预防。5. 到底要不要上重型平台我的选型建议5.1 小规模场景脚本就够别自找麻烦如果你的办公室只有三五台打印机人也很少我建议直接用上面这套脚本加群机器人不用引入任何商业监控软件。理由很简单打印机数量少的时候脚本的维护成本极低新增一台设备只要往列表里加一行而重型平台光安装、调模板、学操作就要花掉大半天遇到问题还要查文档性价比非常低。脚本的缺陷是没有历史报表和自动化拓扑发现但小场景下这些功能根本用不上。这里也提醒一点即便是脚本也要考虑“留一手”。我一开始只把打印机IP硬编码在列表里后来打印机换网段、换IP改起来很麻烦。后来我改成了配置文件或数据库保存设备清单并加了资产编号、品牌型号、所在位置这些字段。后续不管是用脚本还是迁移到平台这些资产数据都能直接复用不用重新录入。5.2 中大规模场景成熟平台更省力打印机超过几十台或者有多地点、多部门的集中管理需求时脚本会越写越重这时候就该考虑Zabbix、PRTG、Nagios这类通用监控平台。它们自带SNMP模板可以本文还有配套的精品资源点击获取