“许可不足”弹窗砸脸上，先别喊加购——九成问题不在容量上

工程师早上一启动 Catia，“All licenses are currently in use”。工单飞过来，老板抄送采购：“赶紧买十个！”——先等等。这句报错翻译过来是“此刻没抢到”，至于为什么没抢到，容量不足只占其中一小半。网络抖了、daemon 挂了、模块配错了、僵尸会话占着茅坑，弹出来的都是同一句话。

不把根因拆开就掏钱，是许可管理里最冤的一种花法。

先懂原理，报错才有得聊

浮动许可的逻辑就三步：客户端向 port@host 发 checkout 请求 → vendor daemon（ansyslmd、cdslmd 这些）在 feature 池里找空位 → 找到就发句柄，找不到就回错误码。弹窗文案是给用户看的，错误码才是给你看的。所以排查第一步永远是拿错误码，不是看弹窗。

常见几类，FlexNet 为例：

• -4：feature 池真满了。这才是容量问题。
• -5 / -16：feature 名不对或版本不匹配，客户端请求的模块服务器上压根没配，跟容量一毛钱关系没有。
• -15：连不上服务器。端口被防火墙挡了、lmgrd 没起、DNS 解析挂了——这是网络和服务问题。
• -97：vendor daemon 没起来。lmgrd 活着但 ansyslmd 死了，池子整个不可用，用户看到的是“满”，实际是“瘫”。

SolidWorks 的 SNL 报错 “-8, -97” 也是同款逻辑。“满”和“瘫”在用户眼里长一样，在日志里是两码事。

排查三件事，顺序别乱

第一，把报错钉死。 谁、哪台机器、什么时间、哪个模块、错误码多少。缺一样，后面全靠猜。做一张排查登记表，别让用户截个图就完事。

第二，看服务器状态和日志。

• lmutil lmstat -a -c 27000@lic-server 一把梭：lmgrd 活没活、vendor daemon 起没起、各 feature 占用多少、谁占的、从几点占的，全在这一屏里。
• debug.log 里 grep 带时间点的 DENIED 记录，报错时段有没有对应的拒绝记录——有，是真抢不到；没有，问题多半在客户端到服务器这段路上（防火墙、hosts、VPN）。
• DSLS 的 dslsadmin / usage log 同理。

第三，三个数放一起看：峰值并发、拒绝次数、空闲会话占比。峰值没满但拒绝一堆 → 服务或配置问题；峰值满了且空闲超 30 分钟的会话一大片 → 假性短缺；峰值真满、拒绝集中在固定时段 → 这才轮到容量话题。

核查结果压成四栏：事实、缺口、影响、责任人。拿这张表去开会，比甩一句“服务器满了”有说服力得多。

分流处理，各回各家

• 服务/网络类：先恢复服务再谈别的。lmgrd 崩了先 reread/restart，日志打包留底——恢复动作本身要有记录，别恢复完就当无事发生。恢复时长要统计，这是你的 SLA 底数。
• 配置类：feature 拼错、版本没升级、PACK 组合没激活，改配置、验证、记录变更理由。这类问题修一次少一次。
• 空闲占用类：双因子判定（键鼠静默 + 无活跃命令）+ TIMEOUT + 回收前通知，白名单保护 solver 和跑大任务的会话。先观察、再提醒、后执行，留人工恢复入口——误杀一次被投诉三天的教训，不用自己再踩一遍。
• 真容量类：跑满一个完整业务周期（项目型团队必须覆盖节点冲峰），峰值持续满载、治理手段全上完了还满，才上采购议程。

告警和工具

• 服务器侧先布基础告警：vendor daemon 掉线、license 使用率超 90%、debug.log 出现连续 DENIED。就这三条，能拦下大半夜没人知道的宕机。
• 规模小，lmstat + 定时脚本 + Excel 顶得住。多软件、多 server、多园区了，原生方案没有统一面板、没有跨 vendor 空闲判断、没有历史留痕，这时候再上许可优化类工具做集中监控和任务闭环。工具是把排查从救火变成常态运营的载体，不是替你判断的。

验收看什么

• 许可拒绝率：分模块分时段，公式写死。
• 故障恢复时长：从报错到恢复，按部门下钻。
• 峰值并发：跟项目节点关联着看，别裸看。
• 空闲会话比例：分子分母异常样本都留，抽样回读源记录。

四个数都能下钻到具体账号、设备、模块，才算数。指标异常先查口径变了没，再怀疑业务。

别踩这几个坑

• 单日一次报错就上报扩容——先看是 -4 还是 -15。
• 没分流就先采购或强回收——方向反了两头亏。
• 安装量、授权量、登录数、并发量混着算——账都算不平。
• 改进没责任人、没截止时间、没回读验证——人一走全归零。

一个真实案例

苏州一家做精密模架的，Creo 30 席，一个季度里“许可不足”工单 40 多张，老板批了加购 10 席的预算，还没走完流程。新来的运维主管接手，先按错误码分流：40 张工单里，-15（连不上）12 张——全部来自新装修的二号楼，防火墙策略变更后 27000 端口出方向没放行；-4（真满）14 张，且集中在周一下午；剩下的是配置错 feature 名的一次性事故。

处理：防火墙策略当天修复，12 张工单的根因直接清零；debug.log 里 grep 周一下午的 DENIED，发现 6 个会话单次占用超 6 小时且无操作——设了 20 分钟双因子闲置回收，跑 solver 的机器加白名单；周一下午是周例会后的建模高峰，跟各部门约好错峰半小时开 Creo。

跑了一个月：-4 类拒绝从日均 5 次降到 0.3 次，空闲占用比例从 34% 压到 9%。加购预算冻结，最后只补了 2 席。老板原话：“早知道先把端口查了。”

这事就一句话——报错背后有四种病，药不一样。先诊断，再开方，最后才花钱买补品。顺序反了，病没好，钱没了。