去年接手公司CAD设计团队的软件运维时，最头疼的一件事就是SolidWorks的许可证。公司买了40个浮动授权，但几乎每天都有设计师在群里喊“连不上许可”“明明还有空位为什么我登不上去”“谁把我的许可挤掉了”。这些争执背后其实是同一个问题：大家根本不知道SolidWorks的授权被谁占着、用了多久、是哪些模块吃掉了大头、有没有人占着不用。后来我用开源工具搭起了一套SolidWorks license监控看板，才把这个问题真正理顺。这篇文章就把我的完整方案、踩过的坑和可以直接复用的代码逻辑都写出来，给被浮动许可折磨的同行一个参考。
1. 先想清楚：这个看板到底要解决什么问题
1.1 浮动许可证的痛点远比想象中多
SolidWorks采用的浮动授权（Network License）机制，本质上是设计师的电脑通过局域网向一台许可服务器“借用”某个功能模块的授权，关闭SolidWorks后归还。这套机制本身很稳定，但它是一个天然的黑盒：只有服务器知道谁借了哪个授权，业务侧完全看不见。
于是日常就会出现几种情况：有人上班打开SolidWorks挂机一天，实际画图不到一小时；某个模块的授权被几个老项目占满，新项目组干等；个别同事把许可勾选了“借用”（Borrow）到笔记本上，几天不回位；最要命的是，你问工厂买了多少授权、够不够用，能不能支撑明年再招一批工程师——没有任何数据能回答。
这种状态持续久了，IT和设计团队之间就是无尽的扯皮。做看板的第一目标不是“监控”，而是把黑盒变成白盒，让每个人都看到真实的许可占用情况。
1.2 看板要回答的六个关键问题
我在设计指标体系前，跟设计部门的主管聊了几轮，把需求收敛成六个问题，看板所有功能都围绕这六个问题展开：
- 当前还剩多少许可：距离总量还剩多少，哪些模块已经耗尽。
- 谁在用、用了多久：定位单个用户、单台机器的占用时长，方便找“占着不用”的人。
- 使用时段分布：团队集中在几点开始用、几点下班收尾，判断是否需要错峰或加购。
- 哪些功能模块占用最高：SolidWorks的建模、仿真、PDM等不同Feature消耗分布。
- 有没有异常占用：比如同一用户开多会话、深夜仍有长时间占用、借用超期不还。
- 历史趋势：过去6个月的峰值并发，作为下一周期预算和采购的依据。
看板不需要做得花哨，能把这些问题回答清楚，就是合格的企业级看板。
1.3 为什么选择开源路线
市面上其实有现成的商业许可证管理工具，比如OpenLM，功能很完整，自带报表和告警。但我看过报价之后，发现按授权数量和功能模块收费，每年维护成本不低，而且数据模型相对固定，想接入公司内部的企业微信告警和人名映射表，还得看厂商支不支持。
开源路线的优势在于：数据完全掌握在自己手里，采集逻辑可以针对SolidWorks的版本和Feature名做定制，告警能复用已有的通知体系，报表能深度嵌入现有的内部运维平台。技术上就是Python脚本加时序数据库加Grafana，整套东西在社区里都有文档，并不需要发明轮子。
2. 整体架构与数据链路设计
2.1 四层结构：采集、存储、计算、展示
许可监控看板的整体架构可以分成四层，每层职责单一，后续扩容也方便：
采集层部署一台独立的小型服务器或容器，运行Python定时脚本，通过调用许可服务器上的FlexNet命令拿到授权快照，同时增量读取FlexNet的运行日志。存储层使用PostgreSQL保存原始快照和聚合统计。计算层由Grafana的告警引擎和SQL视图完成，比如计算日均峰值、整理Top用户排行。展示层是Grafana仪表盘，再叠加一个面向设计师的极简查询页面，让他们只看“现在有没有空余授权”。
这里有个关键设计：采集脚本和展示层分离。脚本只管把数据稳定地写入数据库，展示层只管查询和展示，互不干扰。如果Grafana挂了，不影响采集；如果采集脚本出了问题，看板也只是缺一段数据，不会连累生产服务器。
2.2 为什么不能用现成的监控系统直接替代
运维圈常用的Prometheus、Zabbix、Telegraf这套组合，对服务器CPU、内存、网络这些基础设施监控很在行，但拿它们直接监控FlexNet是行不通的。FlexNet的授权状态不是标准协议，不会主动暴露Metrics给监控系统，必须自己通过lmstat命令或日志解析才能拿到Feature级别的数据。
Telegraf虽然有exec输入插件，能执行外部命令，但lmstat的输出是文本，需要写解析器。与其绕一圈用Telegraf加自定义脚本，不如直接把采集逻辑放在一个Python脚本里，逻辑更清晰，调试也方便。对于我们要解决的“Feature谁在用”这个问题，自研采集层几乎是必经之路。
2.3 一次完整的监控闭环
以每60秒一个周期为例，整体闭环是这样的：Python脚本执行lmstat -a命令，拿到当前所有Feature的授权占用快照；脚本解析出“Feature名、用户名、主机名、开始占用时间”等字段，写入PostgreSQL；Grafana每60秒刷新一次仪表盘，展示最新状态；如果占用率超过预设阈值，Grafana触发告警规则，把消息推送到企业微信或邮件；恢复后自动发送恢复通知。
这个闭环里没有哪个环节特别复杂，难的是细节——解析正确、字段完整、告警不重复、数据不膨胀。后面几节我会逐个展开。
3. 核心数据源：读懂FlexLM许可证服务器
3.1 先学会看lmstat的输出
SolidWorks的浮动授权基于FlexNet（也叫FlexLM），许可证服务器上通常会安装SolidNetWork License Manager。想拿到授权状态，最通用的方式就是在服务器上执行lmstat命令：
lmstat -a -c 27000@sld-lic-srv-c参数指定许可证服务器地址，格式是端口@主机名。执行后输出大致分三个部分：License server status（服务器状态）、Vendor daemon status（守护进程状态）、Feature usage info（授权使用明细）。我们需要重点关注的是第三部分，它的每一行都对应一个Feature的使用记录：
users of solidworks: (Total of 10 licenses issued; Total of 7 licenses in use) "designer_zhang" USER_MACHINE v2024 (v2024.0) START 12:01, Thu 6/14 "modeler_li" USER_MACHINE v2024 (v2024.0) START 13:22, Thu 6/14这段输出明确告诉我们：solidworks这个Feature一共授权了10个，当前有7个在用；再往下是具体谁占用、从几点开始用。这就是看板最核心的原始数据。
不同版本的SolidWorks，Feature名会有差异，有的叫solidworks，有的带版本后缀或模块名。第一次对接时，把服务器上实际的Feature列表打出来，逐个记录映射关系，后面统一归一化处理。
3.2 日志增量：还原占用时长和归还记录
lmstat是一条命令的快照，能看到当前占用，但看不到历史。想要精确统计某个用户平均占用多久，得看FlexNet的debug log。默认情况下，日志里会记录每次授权借出和归还的事件：
14:29:01 (solidworks) OUT: "solidworks" designer_zhang@USER_MACHINE 15:02:44 (solidworks) IN: "solidworks" designer_zhang@USER_MACHINEOUT行表示借出一个授权，IN行表示归还。把这两行按用户名配对，就能算出这个用户这次用了多长时间。这个信息非常有用：平均占用时长、超长占用名单、模块使用频率全靠它。
日志也会带来麻烦：文件会不断轮转（Rolling），如果采集脚本只追新不记旧，轮转期间的记录会丢失。我的做法是每天凌晨记录日志文件的inode和当前读到的字节偏移量，第二天从偏移处继续读，同时处理轮转后新文件的变化，保证不丢事件。
3.3 采集脚本的边界控制
写采集脚本时，有一个容易被忽略的问题：lmstat本身有执行开销。如果每隔30秒就执行一次，对许可证服务器会有无谓的负载。我实测下来60秒间隔已经能满足“分钟级”的看板要求，高并发环境建议放到90秒或120秒。
脚本还要处理超时、乱码、命令找不到三种情况。lmstat在Windows服务器上执行时，输出编码可能是GBK或UTF-8，解析前先统一转码，否则中文用户名会变成乱码。命令超时要用subprocess的timeout参数兜底，不能让脚本卡死在服务器上；命令找不到时，要能自动搜索常见的SolidWorks安装路径，而不是直接抛异常。这些边界处理看似琐碎，但缺一个，看板就会出现空洞。
下面是我采集脚本的核心骨架，实际使用中再配一个Systemd定时器或Windows计划任务即可：
import subprocess import datetime import psycopg2 import re LMSTAT_PATH = r"C:\Program Files\SOLIDWORKS Corp\SolidNetWork License Manager\lmstat.exe" LIC_SERVER = "27000@sld-lic-srv" def run_lmstat(): cmd = [LMSTAT_PATH, "-a", "-c", LIC_SERVER] proc = subprocess.run( cmd, capture_output=True, text=True, timeout=30, encoding="gbk", errors="replace" ) return proc.stdout def parse_usage(text): records = [] # 按Feature段切分，提取用户名、主机名、Feature名 for line in text.splitlines(): m = re.search(r'users of (\S+):', line) if m: current_feature = m.group(1) continue m = re.search(r'^ "(\S+)"\s+(\S+).*START (\S+)', line) if m and current_feature: records.append({ "feature": current_feature, "user": m.group(1), "host": m.group(2), "time": datetime.datetime.now(), }) return records if __name__ == "__main__": output = run_lmstat() rows = parse_usage(output) # 写入PostgreSQL，注意使用批量插入 insert_rows(rows)这里有一个细节：lmstat输出里的用户名可能带引号，主机名后面还会跟版本信息，正则匹配时最好先做样例验证。我建议先在服务器上把lmstat输出保存成文本，拿真实数据来调正则，比凭空猜格式靠谱得多。
4. 数据清洗与指标建模
4.1 Feature名归一化和用户映射
原始采集数据里，Feature名可能五花八门：solidworks、solidworks_premium、sldworks、simulation……如果不做归一化，报表会散成一团。我的做法是在数据库里建一张映射表，把原始Feature名映射到统一的业务分类：三维建模、仿真分析、PDM模块等。
用户名的映射同样重要。许可证服务器上的用户名是AD账号（比如zhangs），而看板面向业务时最好显示中文姓名和部门。这就需要从公司AD或HR系统同步用户信息，建一张用户维表。每次展示时做一次JOIN，把zhangs翻译成“张三·设计二部”，业务主管一看就明白。
4.2 核心指标口径
指标口径不统一，看板等于白做。我用的几个核心指标定义如下：
- 并发占用率 = 当前同时在用授权数 / 该Feature授权总量。
- 日峰值并发 = 一天内lmstat快照中“在用授权数”的最大值，这是判断是否加购的最关键数字。
- 平均占用时长 = 某Feature所有IN/OUT事件对的时长平均值，只看成功配对的记录。
- 授权利用率 = 日峰值并发 / 授权总量，反映每天最紧张的时段用了多少比例。
有一个容易踩的坑：并发占用率用“当前值”还是“5分钟均值”。如果只看当前值，午休时间大家都关掉SolidWorks，数字掉到10%，会被误判为“授权大量空闲”。我建议默认展示5分钟或10分钟粒度的滚动均值，同时保留原始快照，告警规则也基于滚动均值触发，避免单点波动造成误报。
4.3 空闲检测与“占着不用”的判断
这是业务最关心的功能，也是最难做准确的功能之一。设计师开着SolidWorks但超过半小时没有任何建模操作，从许可证服务器层面是看不到“他到底在不在干活”的。我给出的方案是启发式判断：结合两个信号，一是SolidWorks前台窗口的活动状态，二是用户电脑的操作系统空闲时间。通过每台设计师电脑上的轻量Agent回传这两个指标，判断用户是否离开。
实现上不一定需要自研Agent，很多公司已经有终端管理软件，能通过接口查询用户空闲状态。拿到“用户空闲超过15分钟且仍然占用授权”的记录后，看板自动给这个用户推送一条提醒，不直接释放授权，避免误伤正在思考方案的设计师。这条规则上线一个月后，授权归还率明显提升，被占着不用的授权数量降了三成左右。
5. 看板落地：从Grafana到自制页面的选择
5.1 最短路径是PostgreSQL+Grafana
展示层我选了Grafana，原因很直接：成熟、免费、PostgreSQL数据源支持好，而且不用额外的前端开发。把PostgreSQL接进来之后，用SQL就能画出大部分图表。
第一个仪表盘是“许可总览”，包含三行面板：第一行放两个Stat面板，显示当前最紧张的Feature占用数和今日峰值；第二行放时间序列，展示最近24小时的各Feature并发曲线；第三行放Table，列出当前所有在用的用户、主机、Feature、开始时间，支持按Feature过滤。这套布局信息密度高，运维和设计主管一眼就能定位问题。
Grafana的刷新频率我设置为60秒。太频繁数据库查询压力大，而且lmstat采集本身也是60秒一次，更快的刷新没有意义。
下面是一个最常用的SQL面板，查最近24小时的solidworks Feature占用曲线：
SELECT time_bucket('5 minutes', ts) AS bucket, count(*) AS in_use FROM license_usage WHERE feature = 'solidworks' AND ts >= now() - interval '24 hours' GROUP BY bucket ORDER BY bucket;time_bucket函数来自TimescaleDB扩展，如果用的是原生PostgreSQL，也可以用date_trunc换成5分钟粒度，效果一样。
5.2 图表怎么设计才不流于形式
做看板很容易陷入“堆图表”的误区，满屏都是曲线，但没人知道该看哪里。我的经验是，每个面板都要对应一个业务问题，放上去之前问一问：“这个图能让人做决策吗？”
时间序列图回答“趋势”——什么时候紧张、什么时候空闲；Stat面板回答“此刻”——现在还剩几个授权；表格回答“谁”——具体是谁在占用。三种图表类型各司其职，不要混用。颜色使用也要克制，只在告警阈值线上用红色虚线标出85%和100%两条线，让超标状态一目了然。
另外，看板不要只给IT看。我单独做了一个“极简状态页”，放在团队内部网站上，只显示一句话：当前可用授权：13/40。设计团队上班打开这个页面就知道要不要排队，再也不用在群里问IT。这就是监控看板真正的价值——消灭信息不对称。
5.3 自制页面的扩展场景
如果公司内部已经有统一 portal，Grafana可以直接嵌入iframe；如果对UI有更高要求，也可以只把Grafana当数据源，用前后端分离的框架自研独立页面，通过Grafana HTTP API拉数据。我更推荐先用Grafana把流程跑通，等有了真实的业务反馈，再决定要不要自研。大部分公司到Grafana这一步就够用了。
6. 告警规则与通知闭环
6.1 阈值规则别设得太“灵敏”
告警最怕两件事：不发和乱发。不发等于形同虚设；乱发则会被同事直接屏蔽。我的规则设计原则是：告警必须“持续”才触发，而不是“瞬时”就触发。
占用率告警按三级设计：85%为预警，持续10分钟触发，通知IT负责人；95%为紧急，持续5分钟触发，通知IT和设计主管；100%为耗尽，1分钟内触发，通知所有人，并附带当前占用用户名单。这个分级既给了管理员处理时间，也不会让设计师一天收到十几条相同的“许可证满了”。
最终在Grafana的告警规则里，只需要把Alert conditions设为“持续5分钟/10分钟”，再配上对应的告警通道即可。
6.2 通知渠道和去重策略
公司内部日常用的是企业微信，Grafana可以通过Webhook直接推送到企业微信群机器人。配置方法是在Grafana的Notification policies里新增一个Webhook类型联系点，URL填群机器人的Webhook地址，消息模板用默认的即可。
Webhook通知有个天然问题：只要条件持续满足，Grafana会定期重新发送告警。必须勾选“Only send one alert when the condition lasts”或者配置分组规则，把同一告警规则在持续时间内只发一次。恢复通知也必须有，不然管理者不知道问题已经解决。我的经验是，持续类告警的重复间隔设为1小时比较合适，既不会刷屏，也不会漏掉“超时仍在占用”的长期状态。
还有一个实用的告警类型是“异常归还”：凌晨1点还有人归还授权，说明有人加班到很晚，这类告警自动进入运维工作台，不打扰业务侧。
7. 实操中常见的坑与排查实录
7.1 时间不同步是万恶之源
我第一次搭看板时，所有历史记录的时间串乱了，原因很简单：许可证服务器、采集服务器、Grafana所在机器之间的系统时间差了将近20分钟。这直接导致日志配对错位，IN/OUT匹配不上，平均占用时长算出来全是负数。
排查思路不复杂，逐台机器执行date命令对比一下就能发现。解决方法是让所有相关服务器统一走公司内网的NTP时间源，并在采集脚本里把时间转换为UTC存储，展示时再按用户时区转换。这样即使个别机器时间跳变，也不会污染历史数据。
7.2 采集脚本别影响在线业务
许可证服务器不只是一台跑服务的机器，它还承担着授权校验。如果采集脚本执行频率过高，或者用了不必要的重命令，可能对在线授权造成影响。我遇到过一次情况：脚本里误加了-c参数再叠加递归扫描目录，导致lmstat进程卡住，占用了一个系统会话，虽然最终没有影响授权，但排查浪费了半天。
经验有两点：第一，采集脚本单独跑在一台低负载的机器上，不要放在许可证服务器本机；第二，无论脚本执行什么，都要有严格的超时控制和错误处理，避免进程堆积。脚本运行时间的日志也要保留，方便后续排查。
7.3 许可证服务重启后的数据自愈
FlexNet服务偶尔会因为Windows更新或误操作重启。重启期间，lmstat命令会输出Cannot connect to license server之类的报错，如果脚本没做特殊处理，看板会出现一段“空窗期”，历史曲线看起来像业务突然停止。
应对方法是把采集结果分为“有效数据”和“无效快照”两种状态。连接失败时，往数据库里写入一条状态记录，标记为unavailable，看板上的面板用浅灰显示“采集失败”，而不是显示值为0。这样，图纸上不会出现能误导人的“零占用”曲线，业务主管看到灰色段也能明白是监控系统问题，不是人员停止工作。故障恢复后，脚本可以自动补采一小段快照，减少数据缺口。
7.4 账号、权限和数据安全
企业级看板涉及真实用户名和主机名，属于敏感数据。Grafana的数据库账号必须用只读权限，而且不要给普通设计师开放查看明细的权限，他们只需要看“剩多少许可”。我建议权限模型分三级：IT管理员可看全部明细和告警配置；设计主管可看本部门的使用统计；普通设计师只能看极简状态页。
采集脚本连接许可证服务器的凭据用专用服务账号，不要使用域管理员账号。数据库里如果存储了过于敏感的主机名，也可以做匿名化或脱敏处理，展示层按需还原。这套权限模型看起来多花了一点时间，但能避免很多管理上的麻烦。
7.5 SolidWorks环境本身的兼容性问题
在部署过程中，我还遇到过几类跟SolidWorks环境相关的坑，顺手提一下给读者避雷。比如有些设计师机器上安装了不同版本的SolidWorks，旧版本的许可证Feature名和新的不兼容，导致部分机器指向旧服务器，看板统计出现偏差——这种情况下，需要对照Feature映射表，把所有版本的数据都归一进去。再比如SolidWorks安装组件里的CEF（Chromium Embedded Framework）偶尔报错，虽然这类报错更多是插件冲突导致，但采集脚本如果恰好在这个时段启动，会被误认为是“脚本导致崩溃”，处理方式是区分系统日志和软件运行日志，不要凭感觉排查。
这些事跟监控本身无关，但运维SolidWorks环境就是这样，你得学会把技术问题和环境问题区分开，不然排查方向偏了，浪费的是整个团队的工期。
8. 做完整套系统后的个人体会
整套系统上线后，最大的变化不是“IT不再挨骂”，而是设计团队自己会主动看状态页，自己协调高峰期的使用顺序。许可证从“神秘黑盒”变成了“公共资源池”，管理者能看到真实的并发峰值，年底要不要续费加购，终于有了数据而不是靠猜。
我个人比较推荐两步走：先用一个简单的Python脚本加PostgreSQL和Grafana，把核心链路跑通；等领导和团队都习惯了看数据，再逐步叠加空闲检测、周报和自助查询页面。一开始就上大而全的功能，很容易半途而废。
最后分享一个小技巧：每周一早上用定时任务生成一封“许可使用周报”，内容包括上周峰值并发、平均占用时长、Top 5长时占用用户、本周预测峰值。这封邮件发出去之后，很多原本需要IT逐条解释的问题，自己就消失了。数据只有流动起来，才真正有价值。
