3. 密码改造带来的日志变化
密码改造一上，日志系统首当其冲。很多团队改造前只盯着业务功能，上线后才发现日志量暴涨、格式混乱、告警规则全废。我接手过一个政务云项目，改造完密码策略，日志平台直接撑爆——每秒几万条失败日志涌入，ELK集群挂了两个节点。嗯，教训很深刻。这一章我们就拆开看看：密码强度、登录失败、密码过期、密钥轮换，这四类日志到底变了什么。
3.1 密码强度日志的变化
改造前密码强度日志很简单：通过或者不通过。改造后，强度策略从单一规则变成了多维度组合——长度、字符类型、字典匹配、历史重用、相似度比对，每一个维度都可能产生独立日志。
核心变化点
- 强度等级字段：从布尔值改为枚举（weak/medium/strong/custom）
- 违反项列表：每条日志记录具体违反的策略ID，比如
POL-001代表「长度不足12位」 - 字典命中标记：如果密码命中了常用密码库，会额外记录
dictionary_hit: true
我记得有个客户反馈，改造后密码强度日志量翻了5倍。为什么？因为每个用户改密码时要检查7条策略，每次检查都写一条日志。原来一条「设置成功」了事，现在变成了7条明细。
看个实际格式对比：
| 改造前日志 | 改造后日志 |
|---|---|
password_set: user=zhangsan, result=success |
password_set: user=zhangsan, strength=strong, violations=[], dictionary_check=pass, expiry=90d |
password_set: user=lisi, result=fail |
password_set: user=lisi, strength=weak, violations=["POL-003","POL-005"], dictionary_check=hit, expiry=N/A |
看到没？失败日志里多了 violations 数组，这是我们做告警聚合的关键维度。我建议你在日志采集端直接解析这个字段，拆成多个事件来聚合，而不是把整个数组当字符串存。
3.2 登录失败日志的"变形"
登录失败日志是最容易被忽视的坑。密码改造后，登录失败的"原因码"体系通常会被重构。为什么呢？因为新密码策略引入了临时锁定、图形验证码、二次认证等机制，错误码必须细化。
警告：账号锁定风暴
我曾经遇到过一个问题：密码改造后，所有服务账号的密码过期时间被重置，但运维没及时更新密钥文件。结果凌晨2点，1000多个服务账号同时登录失败，每条失败日志都写"password_expired"，日志平台CPU直接100%。更可怕的是，有些系统配置了"连续失败5次锁定"，导致大量账号被锁，第二天业务全部瘫痪。
登录失败日志的变化主要有三个方向：
- 失败原因码更细：原来就一个
invalid_password，现在可能有password_expired、account_locked、force_change_required、mfa_code_mismatch等 - 重试计数字段：新增
attempt_count记录该用户当前连续失败次数，方便告警判断是否进入锁定倒计时 - 锁定残留日志：账号锁定和解锁事件会生成独立日志类型，不再是登录失败日志的子集
小技巧：把登录失败日志按失败原因码分组，再设置不同的告警阈值。比如 password_expired 的容忍度可以调高（因为可能是批量账号到期），但 account_locked 出现3次就必须人工介入。
3.3 密码过期日志的"生命线"
密码过期日志是改造后最容易"漏告警"的地方。很多系统的密码过期策略分为三个阶段：
- 提前提醒期（比如过期前14天）：日志级别为 INFO，记录
password_will_expire - 过期窗口期（比如过期后3天）：日志级别为 WARN，记录
password_expired_grace - 强制拒绝期：日志级别为 ERROR，记录
password_expired_denied
我见过最离谱的情况是：某团队只对 ERROR 级别的过期日志做了告警，忽略了 WARN 级别的提醒。结果用户密码过期后进入宽限期，系统没告警，等到宽限期结束直接拒绝登录，大量用户同时报障，运维才发现问题。
| 阶段 | 日志类型 | 告警建议 |
|---|---|---|
| 过期前14天 | password_will_expire |
消息通知，无需告警 |
| 过期前3天 | password_urgent_expire |
通知管理员，生成低级别告警 |
| 过期后宽限期内 | password_expired_grace |
中级告警，需要处理 |
| 过期拒绝登录 | password_expired_denied |
高级告警，立即处理 |
关键指标：监控过期前提醒日志的响应率。如果连续3天提醒日志发出后，过期用户的改密率低于50%，说明提醒机制失效了——用户没收到通知，或者通知被当成垃圾邮件。
3.4 密钥轮换日志的"断层"
密钥轮换是密码改造中变化最大的日志类型——很多系统以前根本没有密钥轮换的功能。改造后新增的密钥轮换机制会产生三类核心日志：
- 轮换调度日志：记录轮换任务开始、暂停、完成，包含版本号、目标密钥ID
- 轮换执行日志：记录每个密钥实例的轮换结果，包含签名校验值、生效时间戳
- 轮换失败日志：记录失败原因，比如
key_in_use（密钥正在被引用）、signature_mismatch（签名不符）
实际项目中，密钥轮换日志最容易出问题的点是「版本号断层」。比如密钥从 v5 直接跳到了 v7，中间 v6 的日志去哪了？我排查过一个问题，发现是轮换任务并发执行时，两个实例同时更新了同一条密钥记录，导致版本号被覆盖。解决方案是在密钥元数据中加入乐观锁，每次更新前校验当前版本。
实用技巧：在日志解析阶段就提取 key_version 字段，建立版本号连续性监控。如果发现版本号跳跃超过1，立即生成告警。我曾经靠这个规则发现过一次轮换任务并发 bug，避免了数据解密失败的事故。
3.5 归纳总结：日志变化的应对思路
说了这么多，无非是让你心里有数：密码改造不是只改改登录页面就完事的。日志系统的改造需要同步跟进。总结三条干货：
| 日志类型 | 最大变化 | 应对策略 |
|---|---|---|
| 密码强度 | 单字段变多字段数组 | 解析 violations 数组，按策略ID独立聚合告警 |
| 登录失败 | 原因码细化，新增锁定日志 | 按失败码设置分层阈值，区分用户类角色 |
| 密码过期 | 分阶段日志，宽度期陷阱 | 全阶段监控，WARN 级别不可忽略 |
| 密钥轮换 | 新增轮换日志，版本号管理 | 提取版本号，监控连续性，加乐观锁 |
最后说一句：日志变化带来的第一个冲击往往是「量」，第二个是「字段解析」。建议你在密码改造上线前就做好日志样本采集，跑一遍解析 pipeline，不要等上线后才发现字段没分出来。好了，这部分就到这里——毕竟日志的变化只是告警处置优化的起点，后面才是真正的硬仗。