生产环境日志与审计日志

做的事：本机真实搭一个独立节点，开启xpack.security.enabled和xpack.security.audit.enabled，用真实的用户名密码认证成功之后，故意发两次失败的认证请求

代码真实启动audit-lab节点，配置里真实打开: xpack.security.enabled: true xpack.security.audit.enabled: true 真实用正确密码认证成功: curl -u audituser:AuditPass123! .../​_cluster/health 真实用错误密码: curl -u audituser:WrongPassword .../_cluster/health 真实完全不带凭证: curl .../_cluster/health

验证：两次失败请求真实都收到了401，但真实查审计日志文件，这两次失败尝试压根没有留下任何记录

错误密码请求: → 401 security_exception "unable to authenticate user"
无凭证请求: → 401 security_exception "missing authentication credentials"

真实查audit-lab_audit.json文件:
→ 真实只有access_granted这一种event.action，没有任何authentication_failed
  或者anonymous_access_denied的记录

真实怀疑是事件类型没配全，显式把audit.logfile.events.include配置成包含authentication_failed等类型后重启重测一次

代码真实加一行配置重启: xpack.security.audit.logfile.events.include: ["access_denied","access_granted", "anonymous_access_denied","authentication_failed","connection_denied", "tampered_request","run_as_denied","run_as_granted"] 真实重新发一次错误密码请求和一次无凭证请求

验证：真实依然一条失败记录都没有，审计日志里真实从头到尾只有寥寥几条access_granted

真实显式配置了完整的事件类型清单之后，重新测试:
→ 审计日志文件真实总共只有3行，全部都是access_granted
→ 两次真实的失败认证请求依然一条都没有被记录下来

这个真实结果说明问题不在于事件类型清单配置得不够全，一定是有更上层的东西真实把整个审计功能给拦住了。

真实翻server日志找根因，发现了一条写得很直白的WARN日志

代码真实检查audit-lab的console启动日志

验证：真实找到了根因——Auditing logging is DISABLED because the currently active license [BASIC] does not permit it；真实查_license确认当前就是basic许可证

[WARN][o.e.x.s.a.AuditTrailService] [audit-node-1]
  Auditing logging is DISABLED because the currently active license [BASIC]
  does not permit it

GET /_license → "type":"basic"

分步演示：从故意制造的失败认证压根没留下记录，到翻日志找到真实的license限制这个根因

每一步都是本文在一个真实独立搭建的Elasticsearch 8.15.0节点上跑出来的原始结果，测完即销毁。