License Server报警太多？先分清是僵尸会话还是真不够用

干许可管理最怕的不是服务器宕机，是邮箱炸了。

早上打开Outlook，几十条告警邮件堆在那儿：FlexLM报容量不足、ANSYS License Manager提示checkout失败、某个节点的lmgrd进程挂了又重启。你一条条点开看，一半是重复的，三分之一是半夜自动任务触发的误报，剩下几个看着像真的但又不确定优先级。到最后你也麻木了，反正也没人真的用不了，先归档再说。

这就是告警疲劳。告警太多等于没有告警。

先把告警分个类。

不是所有报警都是一个问题。常见的三种：

服务故障类。 lmgrd死了、vendor daemon掉了、端口被占用了、license文件过期了。这类是真的故障，必须马上处理，不然用户确实checkout不到许可。

容量告警类。 并发数达到上限、等待队列排长队、峰值利用率超过阈值。这类不一定真有问题，得看业务场景。仿真任务半夜批量跑，峰值打满是正常的；但白天上班时间也满，那可能真得扩容。

会话异常类。 这就是僵尸会话的大本营。用户电脑休眠了、网络断了、软件崩溃了，但server那边session还挂着，许可没释放。一个用户占着两个许可，另一个人在排队等，实际上第一个人的许可根本没用。

僵尸会话怎么识别？

看checkout时长。正常用CATIA做设计，连续checkout超过八小时的，大概率是僵尸。看进程状态。server显示in use但客户端那边进程已经没了的，铁定是僵尸。看用户反馈。有人排队等许可，但显示占用的人说"我没在用啊"，这也是僵尸。

但别急着kill。

先观察，再提醒，最后再动手。直接kill掉一个正在跑 overnight 仿真任务的session，人家白跑一晚上，第二天找你算账。比较好的做法是：设置一个静默窗口，比如凌晨两点到六点不触发告警；设置一个阈值，checkout超过十二小时自动发邮件给用户确认；确认无人响应后再清理。

几个数要盯着：

有效告警率——你收到的告警里有多少是真的需要处理的，低于30%说明阈值设得太松或者噪声太多；
重复告警数——同一个问题一天报几次，超过三次就该加去重规则了；
平均响应时长——从告警触发到你处理完花了多久，这个数能反映流程顺不顺；
僵尸会话关闭量——每月清理掉多少无效session，这个数能直接换算成释放了多少许可。

说个实际的。

有家做航空结构的，ANSYS Mechanical的并发许可买了四十个，天天报容量不足，业务部门催着要加。IT去看日志，峰值确实四十个全占满了，但仔细一查，其中有七八个session已经连续挂了二十多个小时，用户早就下班了，电脑都关了，许可还占着。加了个脚本，checkout超过十小时且客户端无响应的自动发邮件确认，两小时没回复就释放。跑了一个月，平均每天释放三到五个僵尸许可，白天的等待队列基本没了，扩容的事也就没提了。

这事的关键不是技术，是判断力。告警来了先别慌，先分类，再看数据，最后再动手。别把偶发当趋势，也别把僵尸当真人。