基于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 License（SNL）。简单说，公司买了一批“同时在线”的授权名额，员工电脑装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则代表有用户申请被拒，这是最需要关注的告警事件。

2.2 日志增量解析与快照采集两条路线

拿到日志之后，怎么变成指标？我试过两条路线，各有适用场景。

第一条叫事件解析法。写脚本实时增量读取日志，识别IN、OUT、DENIED等事件，并落库。优点是可以精确还原每个用户的会话时长，能回答“谁占用了多久”“哪些模块在几点出现拒绝”这类审计级问题。缺点是脚本要有状态，比如采集进程重启时会丢失正在进行的会话信息，需要额外的恢复逻辑。

第二条叫快照轮询法。定时执行lmstat -a命令，把当前每个模块的占用数、总授权数、用户列表抓回来。优点是实现极其简单，不需要解析日志格式，适合快速出第一版；缺点是lmstat只是一个时间点的快照，短会话可能漏掉，而且高频轮询对License服务器本身也有一定压力。

我的建议是两条路线结合：日常主数据用日志事件解析，保证完整；每天早上或采集脚本重启后，跑一次lmstat -a做快照校准，把存量占用捞回来。这样的双保险在实操中非常顶用。我在后面第4节给的落地方案，就是按这个思路设计的。

3. 开源方案选型：不迷信“大而全”，按企业规模来

3.1 三套主流组合横向对比

网上聊开源监控，动辄就是全套云原生栈。但license监控这件事，数据量远没有互联网应用那么夸张，选型应当按企业实际规模来。我梳理了三套经过验证的组合，各有侧重。

我最早用的是第一套，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 "q=CREATE 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, database="license_monitor") PATTERN = re.compile( r'(?P<hms>\d{2}:\d{2}:\d{2})\s+\(snl\)\s+' r'(?P<action>IN|OUT|DENIED|EXPIRE)\s+"(?P<feature>[^"]+)"\s+' r'user\s+"(?P<user>[^"]+)"\s+host\s+"(?P<host>[^"]+)"' ) 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", encoding="utf-8", errors="ignore") 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后，先添加数据源，类型选InfluxDB，URL填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告警] feature=SW2024 usage_rate=98% 持续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事件重复统计。

应对办法前面代码里已经写了：每次读之前比较当前文件大小和偏移量，如果文件变小就归零重读。同时，对每条解析后的事件生成一个基于“时间+动作+feature+user+host+handle”的哈希值，写进一个去重集合里，防止同一行被处理两次。

另外，建议保留原始日志的备份。可以每天凌晨把前一天的日志压缩到备份目录，保留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托管，配上开机自启和异常重启策略，让它安安静静在后台跑着，你只需要在群里等告警就好。