基于FlexLM日志与Grafana的开源SolidWorks授权监控看板搭建指南

做企业CAD/PLM管理的朋友肯定都有过这个尴尬时刻老板站在工位旁边问“今年SolidWorks的授权到底够不够用明年要不要增购能不能把闲置的许可收回来”你打开SolidNetWork License Manager对着一堆FlexLM日志憋了半天只能回一句“等我统计一下”。隔天你勉强数出某一天的最大在线人数老板又追问“这是全年峰值吗哪个部门用的有多少人占着许可不用”——那一刻你比谁都清楚缺的不是license而是一块能把授权使用情况讲清楚的看板。这篇博文就是分享我怎么用纯开源工具搭出一套企业级SolidWorks license监控看板。核心信源是FlexLM/SNL服务产生的日志和lmstat输出采集层用Python脚本存储层用InfluxDB展示与告警交给Grafana。整个过程不修改SolidWorks任何程序文件、不碰授权文件完全走“读日志、做统计”的合规路线。适合制造型企业的IT工程师、PLM管理员、研发设备负责人尤其是正被“授权够不够用”反复追问的人。文章会从原理、选型、实操到踩坑逐层展开尽量做到看完就能照着搭。1. 为什么需要自建license监控看板1.1 企业SolidWorks授权的真实痛点企业采购SolidWorks常见的形式是SolidNetWork LicenseSNL。简单说公司买了一批“同时在线”的授权名额员工电脑装SolidWorks客户端使用时向公司内部的License服务器申请一个名额。这个机制本身没什么问题真正麻烦的是管理侧几乎处于“盲飞”状态。举几个我见过的高频场景研发团队进入新品试制阶段上午十点一到几十号人同时打开SolidWorks授权瞬间被打满后排的人不断收到“无法获取许可证”的弹窗只能停下手里的活等同事关闭软件。另一边却有几个人开着SolidWorks一整天就为了看一眼模型授权一直被占着。再比如SolidWorks的授权往往按模块拆开管理建模是SW2024仿真是Simulation可视化是Visualize每个模块都有独立数量。某个模块的license被占满时弹窗提示也各不相同用户只会觉得“公司软件不行”IT部门却说不清到底是总量不够还是模块分配不合理。更难受的是当领导问“我们到底有没有必要增购”时你拿不出连续的数据。偶尔用lmstat命令看一眼当时的在线人数那只是一个时间切片既证明不了峰值也解释不了趋势。等到年底做预算采购部要依据财务部要数据你只能靠Excel手工日报凑数既费时间又不准确。这些痛点归结起来就是三件事一是看不到实时占用情况二是说不清历史峰值和趋势三是没有自动告警能力等问题炸了才知道。自建一个license监控看板就是要同时解决这三件事。1.2 自建开源看板能带来什么用开源工具自建看板本质上是在FlexLM日志之上做一层“翻译”。日志本来就把每一次授权申请、成功发放、拒绝记录、释放记录都写得清清楚楚但我们不能靠肉眼去读。看板做的就是把日志翻译成曲线、表格、排名和告警。具体能拿到这些能力实时掌握每个SolidWorks模块当前被占用几个、剩余几个、使用率百分比自动统计历史并发峰值能精确到某天某个小时的最高占用按用户名、主机名、模块维度统计谁在用、用了多久、是不是占着不用一查便知当某个模块使用率超过设定阈值自动把告警推送到企业微信/钉钉群看板权限可控管理层看汇总IT管理员看明细各取所需。这些能力如果用商业License管理软件也不是买不到但一套动辄好几万配置还重。开源自建的核心成本是时间和技术人力对已经有基础IT运维能力的公司来说性价比高得不是一点半点。我最初是在两台测试机上搞的数据采集器跑了一个月非常可靠后来才逐步扩大到生产环境的多台License服务器。如果你所在的公司也有类似需求这套思路基本可以直接照搬。2. 看懂FlexLM日志就拿到了监控的钥匙2.1 SNL后台的工作机制SolidWorks网络版License依赖的是FlexLM也叫FlexNet Publisher这套老牌授权管理框架。License服务器上跑着两个核心进程一个是主服务lmgrd负责整体调度另一个是SolidWorks自己的vendor daemon进程名一般是snl负责处理SolidWorks各个模块的授权请求。当员工电脑上的SolidWorks启动客户端会向License服务器发起请求snl收到后判断当前某个模块还剩多少可用名额够就放行不够就拒绝。这个过程snl会一行一行写进日志文件。所以日志里天然包含了全部授权的“生老病死”信息。一条典型的日志长这样16:32:11 (snl) IN SW2024 user zhangsan host CNC-A06 handle 88412 16:32:15 (snl) DENIED SW Visualize user lisi host CNC-B21 (Only 2 licenses for feature) 17:11:42 (snl) OUT SW2024 user zhangsan host CNC-A06 handle 88412不同SolidWorks版本的日志格式略有差异有的写IN有的写CHECKOUT有的字段顺序也不一样。但核心信息是一致的发生时间、操作类型、授权模块、用户名、主机名、会话句柄。把这几个字段拆开看含义很清晰字段含义监控用途时间事件发生时刻统计并发曲线、峰值时段操作类型IN / OUT / DENIED / EXPIRE区分授权分配、释放、拒绝、到期Feature授权模块名分模块统计使用率用户申请授权的Windows用户名统计个人占用、排行榜主机名用户电脑名追踪是哪台设备占用的Handle会话句柄关联IN和OUT算单次会话时长把这个模型想清楚后面解析脚本怎么写就顺理成章了。日志里的每一次IN代表一个授权被消耗每一次OUT代表一个授权被释放DENIED则代表有用户申请被拒这是最需要关注的告警事件。2.2 日志增量解析与快照采集两条路线拿到日志之后怎么变成指标我试过两条路线各有适用场景。第一条叫事件解析法。写脚本实时增量读取日志识别IN、OUT、DENIED等事件并落库。优点是可以精确还原每个用户的会话时长能回答“谁占用了多久”“哪些模块在几点出现拒绝”这类审计级问题。缺点是脚本要有状态比如采集进程重启时会丢失正在进行的会话信息需要额外的恢复逻辑。第二条叫快照轮询法。定时执行lmstat -a命令把当前每个模块的占用数、总授权数、用户列表抓回来。优点是实现极其简单不需要解析日志格式适合快速出第一版缺点是lmstat只是一个时间点的快照短会话可能漏掉而且高频轮询对License服务器本身也有一定压力。我的建议是两条路线结合日常主数据用日志事件解析保证完整每天早上或采集脚本重启后跑一次lmstat -a做快照校准把存量占用捞回来。这样的双保险在实操中非常顶用。我在后面第4节给的落地方案就是按这个思路设计的。3. 开源方案选型不迷信“大而全”按企业规模来3.1 三套主流组合横向对比网上聊开源监控动辄就是全套云原生栈。但license监控这件事数据量远没有互联网应用那么夸张选型应当按企业实际规模来。我梳理了三套经过验证的组合各有侧重。方案核心组件优点缺点适合场景轻量报表型Python脚本 SQLite ECharts网页部署最简单依赖少单机就能跑没有统一告警体系权限管理要自己写一至两台License服务器只看日报周报时间序列型Python采集 InfluxDB Grafana指标存储天然匹配看板、告警、权限开箱即用需要维护InfluxDB和Grafana两个服务多台License服务器需要实时曲线和告警日志平台型Logstash Elasticsearch Kibana日志检索能力强能和其他日志系统统一组件重吃内存运维成本高公司已有ELK体系希望复用平台我最早用的是第一套SQLite里存几张大表再用Flask写个页面放ECharts功能是够但每次加指标都要改代码告警只能脚本发邮件有点原始。后来切到第二套Grafana把大部分展示和告警工作都接管了整个人轻松不少。3.2 我的落地建议对大多数中型制造企业我最推荐的是“Python InfluxDB Grafana”这套组合。理由有三点。第一InfluxDB是时间序列数据库专门为“每隔几分钟写一条指标、按时间范围查询曲线”这类场景设计。license使用率天然是时间序列数据存进去无论是按小时聚合还是按天对比都非常顺手。第二Grafana本身是开源看板工具的天花板之一不需要自己写前端。它自带InfluxDB数据源插件、丰富的面板类型、告警规则和用户权限体系。从原始日志到生产看板的距离被压缩得极短。第三Python写日志解析最顺手。正则匹配FlexLM日志里的各种格式变体做增量读取、去重、状态维护生态里都有现成的库。而且Python脚本方便后续扩展比如接一个Webhook把分析结果推给其他系统。如果你公司规模特别小、License服务器就一台那直接用SQLite存结果每周跑个脚本出报表也行不需要上全套。反过来如果公司已经有Elasticsearch集群IT团队也用得熟练那用Logstash消费日志、Kibana出看板不额外引入新组件也完全成立。选型的核心原则只有一个别为了追技术热点把简单问题复杂化。4. 动手搭建从日志解析到可视看板4.1 监控服务器的安装准备我以一台Ubuntu 22.04 LTS服务器为例。内存建议不低于4G磁盘根据历史日志量来InfluxDB加Grafana初期给50G就非常宽裕了。先安装InfluxDB 1.8系列这个版本成熟Grafana用InfluxQL查询最顺手。wget https://dl.influxdata.com/influxdb/releases/influxdb_1.8.10_amd64.deb sudo dpkg -i influxdb_1.8.10_amd64.deb sudo systemctl enable influxd --now再安装Grafana直接下载deb包wget https://dl.grafana.com/oss/release/grafana_11.1.0_amd64.deb sudo dpkg -i grafana_11.1.0_amd64.deb sudo systemctl enable grafana-server --now装完先别急着开面板把InfluxDB的库建好。我用命令行执行curl -XPOST http://localhost:8086/query --data-urlencode qCREATE DATABASE license_monitor接下来是网络和数据准备。License服务器有的在Windows上有的在Linux上。不管哪种采集脚本需要能读到FlexLM日志。常见做法是Windows的License服务器开一个只读共享目录监控服务器用SMB挂载Linux服务器则用rsync或SFTP定时把增量日志拉到本地。注意权限给“只读”就够了千万别让监控端有写权限避免误操作污染原始日志。4.2 日志解析脚本核心实现日志解析是整个看板的地基。我先把脚本拆成三块增量读取、事件解析、快照写入。增量读取的核心思路是记录上一次读到的文件偏移量。每次运行脚本从偏移量往后读新产生的行。如果文件变小了说明发生了日志轮转就把偏移量归零重读。下面是核心代码框架import os import re from collections import Counter from datetime import datetime, timezone from influxdb import InfluxDBClient LOG_PATH /data/flexlm/snl.log OFFSET_PATH /data/flexlm/snl.offset client InfluxDBClient(localhost, 8086, databaselicense_monitor) PATTERN re.compile( r(?Phms\d{2}:\d{2}:\d{2})\s\(snl\)\s r(?PactionIN|OUT|DENIED|EXPIRE)\s(?Pfeature[^])\s ruser\s(?Puser[^])\shost\s(?Phost[^]) ) def read_incremental(): offset 0 if os.path.exists(OFFSET_PATH): offset int(open(OFFSET_PATH).read().strip()) current_size os.path.getsize(LOG_PATH) if current_size offset: offset 0 # 日志被轮转或清空重新读整份 with open(LOG_PATH, r, encodingutf-8, errorsignore) as f: f.seek(offset) for line in f: yield line.strip() new_offset f.tell() with open(OFFSET_PATH, w) as f: f.write(str(new_offset))事件解析时要考虑日志格式变体。有的行没有user/host关键字有的动作叫CHECKOUT而不是IN。所以我在正则之外再加一层宽松的后备解析只要行里有(snl)、动作关键字和引号包起来的feature名就先收进来字段缺失的置空。def parse_line(line): m PATTERN.search(line) if not m: return None return m.groupdict() def persist_event(event): json_body [{ measurement: license_events, tags: { server: SNL-01, feature: event[feature], action: event[action], user: event.get(user, ), host: event.get(host, ), }, fields: {value: 1}, time: datetime.now(timezone.utc).isoformat(), }] client.write_points(json_body)快照写入是看板的另一个关键。事件表只在发生IN/OUT/DENIED时插入一条直接查事件表画不出“当前使用率曲线”。我让脚本每5分钟扫描一次内存中的活动会话表统计各模块当前占用数然后写一条快照FEATURE_TOTAL { SW2024: 50, SW Simulation: 10, SW Visualize: 3, } def write_snapshot(active_sessions): used_by_feature Counter() for session in active_sessions: used_by_feature[session[feature]] 1 for feature, total in FEATURE_TOTAL.items(): used used_by_feature.get(feature, 0) rate round(used / total * 100, 2) if total else 0 point { measurement: license_usage, tags: {server: SNL-01, feature: feature}, fields: {used: used, total: total, usage_rate: rate}, } client.write_points([point])写脚本时容易忽略一件事活动会话状态存在内存里脚本一重启就丢。解决方案是启动时先执行一次lmstat -a并解析输出把所有正在占用的会话预填进活动表再开始增量读日志。这样即使服务重启过快照也不会出现大缺口。4.3 Grafana数据源与看板配置进入Grafana后先添加数据源类型选InfluxDBURL填http://localhost:8086数据库名填license_monitor。保存后新建Dashboard开始加Panel。我建议第一版至少放这几个面板总授权使用率趋势。查询license_usage表中最近一段时间的usage_rate按feature分组用面积图展示。这一块能直接回答“当前总体压力大不大”。各模块实时占用柱状图。查询last(used) GROUP BY feature一眼看出哪个模块最紧张。DENIED事件计数。查询license_events表中action DENIED的数量按天或按小时聚合。DENIED是用户真正感受到“卡住”的时刻必须单独盯。当前在线用户排行榜。统计license_events中当前活跃会话按用户分组结合会话时长找出“占着用不上”的典型用户。InfluxQL示例长这样可以直接贴在Grafana的Query编辑器里SELECT last(usage_rate) AS usage_rate FROM license_usage WHERE $timeFilter GROUP BY time($__interval), feature fill(null)这个查询会自动适配你在Grafana左上角选的时间范围刷新频率建议设成5分钟跟快照写入周期保持一致。面板布局上我会把总览类面板放最上面DENIED告警列表放中间用户排行榜放最下面。再配置一个Dashboard变量feature这样管理层点开下拉框就能只看某个具体模块不会淹没在一堆曲线里。配置完面板记得导出Dashboard的JSON文件存到团队共享目录。将来新开一个环境导入JSON就能复刻整套看板不用从头拖拽。4.4 告警规则与群推送看板搭好下一步是把“人盯屏幕”变成“系统盯屏幕”。Grafana的Alerting模块可以基于面板查询创建告警规则。我的做法是两个固定规则阈值告警当某个feature的usage_rate超过95%持续5分钟触发Critical级别告警。这个意思是授权即将耗尽应当排查闲置占用或准备增购。事件告警当1小时窗口内DENIED事件数量超过3条时触发Warning级别告警。DENIED一出现说明已经有人在弹窗确认了必须立即处理。告警通知渠道用Webhook把消息推到企业微信群或钉钉群。以企业微信机器人为例先在群里添加机器人拿到Webhook地址然后在Grafana的Contact Points里配置{ msgtype: text, text: { content: [License告警] featureSW2024 usage_rate98% 持续5分钟超过95%请及时关注授权占用情况 } }钉钉的格式略有差异以钉钉公开文档里的机器人消息结构为准。Webhook地址属于敏感信息保存到Grafana时注意别随手贴到公共仓库。告警规则里还有两个经验值一是加冷却时间至少15分钟否则反复升降阈值会把群消息刷爆二是设置生效时间把工作日上午九点到晚上六点设为告警窗口非工作时间只记录不推送让值班的人真正被叫醒的都是大事。5. 常见问题与排查技巧实录5.1 日志读不到、路径不对怎么办snl守护进程的日志路径是由SolidNetWork License Manager配置决定的不一定在默认安装目录。登录License服务器打开License管理器在配置界面里找到“Debug Log”或类似选项那里显示的路径才是采集脚本要读的真身。Windows服务器上还要检查共享权限。日志文件如果被另外进程占用SMB读取可能遇到文件被锁的问题。我遇到过一次最后把FlexLM日志目录从默认安装路径换到了一个普通磁盘目录重启License服务后顺利解决。Linux服务器之间拉取日志也有坑。用rsync拉增量时如果License服务器和监控服务器时间不同步日志行里的时间戳会对不上。建议在两台服务器上都配置NTP时间同步这是所有日志监控类项目的第一课。5.2 时间与时区错乱FlexLM日志有个奇怪的设计日志行只记录时分秒不记录日期。跨午夜的时候光靠日志本身是分不清“16:32”是哪一天的。我的处理方式是在解析脚本里维护一个“当前日志日期”上下文。当检测到时间从23:59跳回00:01就把日期加一天。同时日志记录的是License服务器的本地时间如果服务器部署在异地机房还要记录时区偏移。入库环节我一律转成UTC存储Grafana展示时再按查看者的本地时区做偏移。这么做的好处是不同服务器的时间做对比时不会出现时区错位。踩过一次坑后我很确定任何跨系统的日志采集先统一时区再谈分析。5.3 日志轮转导致漏记或重记License服务器的日志会按大小或天数做轮转不处理的话采集脚本可能出现两类问题一类是轮转后文件变小偏移量比文件还大脚本一只读到行尾新日志一条都进不来另一类是轮转后从头重读旧日志导致IN事件重复统计。应对办法前面代码里已经写了每次读之前比较当前文件大小和偏移量如果文件变小就归零重读。同时对每条解析后的事件生成一个基于“时间动作featureuserhosthandle”的哈希值写进一个去重集合里防止同一行被处理两次。另外建议保留原始日志的备份。可以每天凌晨把前一天的日志压缩到备份目录保留90天。将来要做年度分析或数据回溯原始日志就是最可靠的底稿。5.4 多台License服务器怎么汇总大企业经常有多台License服务器比如设计部门一台、仿真部门一台各管各的授权。这时候看板不能只盯一台机器。我的做法是给每台采集器配一个server标签比如SNL-01、SNL-02日志事件和快照写入时都带上这个标签。Grafana里的所有面板都增加一个server变量。默认选择All下拉切换就能单看某一台。还要注意跨服务器的会话问题。有些企业会把同一批授权拆到两台服务器上客户端在申请时会按列表挨个尝试。如果一台满了、另一台还有用户是能拿到授权的。这种场景下按服务器分开看还不行要把两台服务器的数据汇总成“全局视图”。快照写入时让脚本把同一feature的used/total合并后再写一条不带server标签的总指标专门给管理层大屏用。5.5 采集脚本重启后会话快照丢失脚本正常持续运行活动会话表是准的。可一旦脚本崩溃或重启内存里的会话记录全没了license_usage表里会出现一个“对勾形”的凹陷看板曲线莫名其妙掉下去实际上授权并没有释放。重启恢复的思路是让脚本启动时先用lmstat -a扫描当前状态。注意lmstat -a的输出格式和日志格式是两套得单独写一个解析函数。扫一遍后把所有已占用的会话写进活动表再继续按偏移量读日志。这样重启造成的缺口最多就几十秒。如果License服务器不允许频繁执行lmstat -a也可以退一步在InfluxDB里存一张“依赖事件推导”的活动表。启动时回放最近2小时的IN/OUT事件重建会话状态。这个方法不依赖外部命令但代码复杂度高一些。我没在生产环境用这个因为它要处理启动前已经开始、启动后才结束的会话边界情况太磨人。5.6 告警风暴怎么压告警规则配得太灵敏群消息每分钟刷一条管理员很快就麻木了真出事反而不看。这是所有监控项目的通病。我压告警风暴的经验是三板斧。第一板斧是“持续时长”比如使用率超过95%并持续5分钟才触发短时间的抖动直接放过去。第二板斧是“冷却时间”同一规则触发后至少静默15分钟再次触发才重新告警。第三板斧是“分级处理”95%提醒、99%才拉群中间档走邮件。被DENIED直接影响到了用户工作直接走最高优先级入群。告警内容里还要带上可操作的信息不能只是“SW2024使用率98%”。如果脚本能额外查出现在占用最多用户名列表一并拼在告警消息里群里的同事就能立刻知道该联系谁释放授权。这个细节让告警从“叫我起床”升级成“告诉我怎么处理”价值完全不同。6. 数据安全、权限合规与正版底线6.1 看板权限要分级Grafana的用户权限体系可以很好满足License看板的多角色需求。IT管理员赋予Admin权限能看原始明细、改告警规则研发主管给Viewer权限只能看汇总面板普通员工连看板入口都不开放。我见过一些公司把“用户占用排行榜”直接公示给全员结果引发部门之间互相猜忌。License授权使用情况虽然不是机密但涉及具体员工的使用时长还是收敛一点好。默认原则是汇总指标广开明细数据窄授。6.2 只做资源监控不做个人行为画像这一点想单独拎出来说。License监控的正当目标是搞清楚授权资源是否被有效利用用于采购决策和IT规划。它不是用于记录员工几点开软件、几点关软件的考勤工具。因此入库的事件数据建议做最小化处理。用户名和主机名仅在排查问题时需要还原日常看板尽量用汇总指标。如果公司有个人信息保护要求采集脚本里可以对用户名做不可逆哈希比如SHA-256这样依旧能统计单个账号的占用时长但无法直接映射到真人。处罚团队需要还原时再用原始日志反查。6.3 正版授权路线最后说一个必须摆在前面的话。搭建license监控看板目的是让公司正版授权的使用变得透明、可度量、可规划绝不是为了绕过或破解授权。网上能找到各种不合规来源的安装包和授权方式那条路不仅违反软件许可协议还容易引入不可控的安全风险企业一旦面临软件合规审计问题只多不少。这块看板真正解决的事情是让你把已经付费的授权用得更充分让增购决策有数据支撑。比如Visualize模块反复出现DENIED说明它确实有需求缺口拿着三个月的数据曲线去申请增购比任何口头汇报都有力。我个人实际操作中的体会是看板跑起来之后最有价值的产出并不是那几张漂亮的曲线图而是它改变了License讨论的语境。以前是“我觉得不够”“我猜够用”现在变成了“统计显示过去一个月Q3末尾有连续三天达到峰值DENIED事件七次”。采购部门听到这个描述预算审批的效率完全不一样。最后再分享一个小技巧旧日志别急着删。每季度末导出一次Dashboard快照连同原始日志一起归档年底复盘全公司各软件授权利用率时这批数据就是最扎实的依据。采集脚本本身也建议用systemd托管配上开机自启和异常重启策略让它安安静静在后台跑着你只需要在群里等告警就好。