去年接手公司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名、用户名、主机名、开始占用时间”等字段写入PostgreSQLGrafana每60秒刷新一次仪表盘展示最新状态如果占用率超过预设阈值Grafana触发告警规则把消息推送到企业微信或邮件恢复后自动发送恢复通知。这个闭环里没有哪个环节特别复杂难的是细节——解析正确、字段完整、告警不重复、数据不膨胀。后面几节我会逐个展开。3. 核心数据源读懂FlexLM许可证服务器3.1 先学会看lmstat的输出SolidWorks的浮动授权基于FlexNet也叫FlexLM许可证服务器上通常会安装SolidNetWork License Manager。想拿到授权状态最通用的方式就是在服务器上执行lmstat命令lmstat -a -c 27000sld-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个在用再往下是具体谁占用、从几点开始用。这就是看板最核心的原始数据。不同版本的SolidWorksFeature名会有差异有的叫solidworks有的带版本后缀或模块名。第一次对接时把服务器上实际的Feature列表打出来逐个记录映射关系后面统一归一化处理。3.2 日志增量还原占用时长和归还记录lmstat是一条命令的快照能看到当前占用但看不到历史。想要精确统计某个用户平均占用多久得看FlexNet的debug log。默认情况下日志里会记录每次授权借出和归还的事件14:29:01 (solidworks) OUT: solidworks designer_zhangUSER_MACHINE 15:02:44 (solidworks) IN: solidworks designer_zhangUSER_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 rC:\Program Files\SOLIDWORKS Corp\SolidNetWork License Manager\lmstat.exe LIC_SERVER 27000sld-lic-srv def run_lmstat(): cmd [LMSTAT_PATH, -a, -c, LIC_SERVER] proc subprocess.run( cmd, capture_outputTrue, textTrue, timeout30, encodinggbk, errorsreplace ) return proc.stdout def parse_usage(text): records [] # 按Feature段切分提取用户名、主机名、Feature名 for line in text.splitlines(): m re.search(rusers 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 最短路径是PostgreSQLGrafana展示层我选了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 自制页面的扩展场景如果公司内部已经有统一 portalGrafana可以直接嵌入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安装组件里的CEFChromium Embedded Framework偶尔报错虽然这类报错更多是插件冲突导致但采集脚本如果恰好在这个时段启动会被误认为是“脚本导致崩溃”处理方式是区分系统日志和软件运行日志不要凭感觉排查。这些事跟监控本身无关但运维SolidWorks环境就是这样你得学会把技术问题和环境问题区分开不然排查方向偏了浪费的是整个团队的工期。8. 做完整套系统后的个人体会整套系统上线后最大的变化不是“IT不再挨骂”而是设计团队自己会主动看状态页自己协调高峰期的使用顺序。许可证从“神秘黑盒”变成了“公共资源池”管理者能看到真实的并发峰值年底要不要续费加购终于有了数据而不是靠猜。我个人比较推荐两步走先用一个简单的Python脚本加PostgreSQL和Grafana把核心链路跑通等领导和团队都习惯了看数据再逐步叠加空闲检测、周报和自助查询页面。一开始就上大而全的功能很容易半途而废。最后分享一个小技巧每周一早上用定时任务生成一封“许可使用周报”内容包括上周峰值并发、平均占用时长、Top 5长时占用用户、本周预测峰值。这封邮件发出去之后很多原本需要IT逐条解释的问题自己就消失了。数据只有流动起来才真正有价值。