4. 健康检查指标：令牌状态、会话数、操作队列长度、响应时间
健康检查到底该查什么？说白了，就是把集群里那些“容易出幺蛾子”的维度抓出来，定期扫描。我个人习惯把指标分成四类：令牌状态、会话数、操作队列长度、响应时间。下面一个个拆开聊，每一条都有真实踩坑记录。
4.1 令牌状态
令牌状态是PKCS 11设备的“命门”。如果令牌失效或未登录，所有密码操作直接就崩了。我记得有一次生产环境，HSM令牌因为证书过期进入了“不可用”状态，负载均衡器还在往那边丢请求，结果一堆签名任务全部超时。排查了两个小时才发现是令牌状态检查没做。
健康检查时我通常关注这些状态值：
- CKR_OK – 正常，可以服务
- CKR__NOT_PRESENT – 令牌不在槽位
- CKR__NOT_RECOGNIZED – 令牌不被识别
- CKR_SESSION_HANDLE_INVALID – 会话句柄失效，也反映令牌问题
C_GetTokenInfo返回的flags字段，确认CKF_USER_PIN_TO_BE_CHANGED位没有被置起。
4.2 会话数
每个HSM或软件令牌能同时打开的会话数是有限的。你以为资源够用，实际上一波并发请求就能把会话池打满。我曾经在一个电子签章平台上线前做压测，发现某个HSM的会话数莫名其妙飙到2000，而官方上限只有1024。结果呢？新会话创建全被拒了，后面请求全部排队。
健康检查时至少要看这几项：
- 当前活跃会话数
- 分槽位会话分布（避免所有会话集中在一个槽位）
- 会话创建失败率（超过0.1%就要告警）
4.3 操作队列长度
当请求抵达速度超过HSM处理能力时，内部操作队列就会开始堆积。这个指标很直观：队列越长，等待时间越久。我见过一个CA系统，私钥签名操作的平均耗时从2ms飙升到200ms，就是因为操作队列长度达到了几千。负载均衡器却毫不知情，继续往那个节点发请求。
如何界定健康？我一般这么处理：
| 队列长度范围 | 健康状态 | 建议动作 |
|---|---|---|
| 0 ~ 10 | 健康 | 正常处理 |
| 11 ~ 50 | 轻微拥塞 | 降低分发权重 |
| 51 ~ 200 | 拥堵 | 停止新请求分配 |
| > 200 | 严重过载 | 立即剔除并告警 |
注意：不同HSM的实现可能有差异，这些数值需要根据你的实际硬件能力调整。
4.4 响应时间
响应时间是最直观的“晴雨表”。但测什么、怎么测，很多人一上来就踩坑。别盯着单次操作的时间，那受网络抖动影响太大。我推荐用滑动窗口统计最近N次（比如100次）操作的平均耗时和中位数耗时（P50、P95）。
典型阈值参考：
- 签名操作： 平均< 10ms 正常，> 50ms 告警
- 解密操作： 平均< 20ms 正常，> 80ms 告警
- 生成密钥： 平均< 100ms 正常，> 300ms 告警
4.5 指标综合与决策
四个指标单独看都不能代表全部。举个例子：令牌状态正常，但会话数满了，队列长度在疯涨 —— 这时候你还觉得它健康吗？我习惯用加权打分的方式来做总体判断。下面这张图可以帮你理清这些指标之间的逻辑关系：
健康评估模块会为四个指标分别打分，然后根据权重（我常用的权重：令牌状态40%、响应时间30%、会话数20%、队列长度10%）计算总分。低于80分就标记为亚健康，低于60分直接剔除节点。
最后提醒一句：不管指标设计得多好，持续更新健康检查策略才是王道。业务增长、硬件老化、软件升级都会让阈值失效。至少每个季度做一次压测复核，调优告警参数。