简介：面向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, community="public"): errorIndication, errorStatus, errorIndex, varBinds = next( getCmd( SnmpEngine(), CommunityData(community, mpModel=1), UdpTransportTarget((ip, 161), timeout=3, retries=1), 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, json=payload, timeout=5) 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代表down；prtGeneralStatus取值中，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 hold，Windows里叫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模板，可以
本文还有配套的精品资源，点击获取
