日志平台能力差距清单（LOGGING-GAP）
生成 2026-10-01 ｜ 对象：EFK（Elasticsearch + Kibana + Filebeat，工程 monitoring-p2-20261001）
性质：只读盘点，不含任何变更 ｜ 用途：按优先级逐条推进时的索引
档位：【实测】本轮有实测证据 / 【已知】来自工程档案 / 【推断】未单独验证
关联：docs/MONITORING-ROADMAP.md（建设蓝图与缺口台账 G1–G9）、docs/PROJECT-MAP.md（任务路由）
0. 这份文件怎么用
- 这是能力差距索引，不是操作手册；每项都给出「在哪能拾起」，动手时进对应工程读
SOP.md / RUNBOOK.md。
- 「优先级」按对本环境的影响排，不按行业热度排：★★★ 不做等于日志平台不完整；★★ 值得做；★ 可延后。
- 不要照单全做：第 4 节列出的是本环境不该抄的行业做法，避免为名词付费。
1. 现状（已具备，不用再补）
| 能力 |
状态 |
| 采集覆盖 |
4 个 K8s 节点（DaemonSet）+ 14 台集群外主机（systemd），日志七类 + LSF logdir |
| 日志级别解析 |
主机侧 journald PRIORITY→log.level；K8s 侧 Filebeat 四层规则（JSON→klog→logfmt→行首标记） |
| 索引与保留 |
data stream + ILM efk-14d（rollover 1d / delete 14d）【实测】 |
| 采集面收敛机制 |
模板标记 + ROLE_GATED_BLOCKS 按角色剥离，防 NFS 共享导致的跨主机重复 |
| Kibana 视图 |
7 面板 + 5 控件（主机 / K8s Pod / 级别 / 集群域 / 类别） |
| 采集器自监控 |
主机侧→Prometheus textfile；K8s 侧→ES .monitoring-beats-* |
| 漂移检测 |
main.py drift；幂等复跑零变更 |
| 入口探测 |
blackbox-exporter + Probe CR + 证书到期告警 |
2. 差距清单
2026-10-02 用户决策：以下三类决定不做 —— #8–#11（安全 / 审计）、#6/#7/#12（可靠性）、
13 冷热分层。理由：单 KVM 宿主 + 内网、日志可再生成、容量充裕，收益有限。
条目保留仅作追溯；HANDOFF.md §3.2 为此决策的索引。
一、语义维度（最影响"日常能不能用"）
| # |
能力 |
现状 |
影响 |
优先级 |
在哪能拾起 |
| 1 |
~~服务维度 service.name~~ → 已闭环（2026-10-01） |
✅ 两侧 Filebeat 顶层 processors 加同款 script（7 级优先级：容器名→systemd 单元→syslog 标识→行首进程名→类别兜底→kernel→文件名），稳态覆盖率 0 → 100%；Kibana 已有第 6 个控件「服务」 |
无 |
— |
monitoring-p2-20261001/docs/SOP.md §5 步骤 9.6 |
| 2 |
~~结构化字段抽取（job_id/user/exit_code/node）~~ → 已落地（2026-10-01） |
✅ 主机侧抽出 job.id/job.user/job.node/job.exit_code（仅 Slurm、LSF 调度器日志），Kibana 明细表加两列；两台主机受控样本验证 4/4 通过。⚠ LSF 侧【未验证】：集群无作业、记账文件无新增，待真实作业复核 |
无 |
— |
monitoring-p2-20261001/docs/SOP.md §5 步骤 9.7 |
| 3 |
~~多行合并（Java/Python 堆栈算一条）~~ → 已闭环（2026-10-02） |
✅ K8s 容器 input 改用 parsers: [container, multiline]（pattern ^[[:space:]]）；离线 fixtures 实测三行 at ... 并成一条、log.flags=multiline。⚠ 本环境几乎无堆栈（实测 Traceback 仅 2 条、Java 堆栈 0 条），属补齐能力；主机侧未加（主机日志以单行为主） |
无 |
— |
log-parse-20261002/SOP.md §5 步骤 2 |
| 4 |
~~日志内时间戳~~ → 已闭环（2026-10-02） |
✅ 主机侧 Slurm（[ISO] 与 YYYY-MM-DD HH:MM:SS）与 OpenWrt（ISO+时区）经 script+timestamp 解析，实测 @timestamp = 行内时间（Asia/Shanghai）。⚠ FlexLM（无日期）/ VNC（无时间戳）/ journald（本就真实时间）/ K8s 容器（CRI 前缀已由 container parser 解析）均不适用；audit / LSF epoch 本轮未做 |
无 |
— |
log-parse-20261002/SOP.md §5 步骤 1 |
二、管道可靠性
| # |
能力 |
现状 |
影响 |
优先级 |
在哪能拾起 |
| 5 |
~~投递失败可观测（dropped / failed / parsing error）~~ → 已落地（2026-10-01） |
✅ 自监控由 6 条扩到 18 条指标（含 dropped/failed/dead_letter/toomany/队列水位/积压）；新增 4 条告警规则（FilebeatDeliveryLoss/Backlogged/QueueNearlyFull/ScrapeDown）；14 台指标已到 Prometheus，规则组 filebeat-delivery 已加载。⚠ parsing error 未覆盖（Filebeat /stats 无该计数器）；K8s 侧仍只有 Stack Monitoring |
无 |
— |
monitoring-p2-20261001/docs/SOP.md §5 步骤 9.8 |
| 6 |
持久化缓冲（磁盘队列 / Kafka） |
【已知】内存队列直投 ES |
ES 重启或满盘期间日志永久丢失 |
★★ |
Filebeat queue.* 配置 |
| 7 |
采集端限流 / 背压 |
【已知】无 |
高流量时可能打爆 ES |
★ |
Filebeat output.elasticsearch.* / bulk_max_size |
三、安全与合规
| # |
能力 |
现状 |
影响 |
优先级 |
在哪能拾起 |
| 8 |
传输加密 |
【已知】ES 明文 HTTP（xpack.security.http.ssl=false，保留认证） |
日志内容（含审计、用户行为）内网明文 |
★★★ |
monitoring-p2-20261001/docs/RUNBOOK.md 第九章；HANDOFF 待办 #13 |
| 9 |
细粒度 RBAC + Kibana Spaces |
【实测】仅 elastic 超管 + kibana_system + filebeat_writer_role（写） |
拿到账号即可看全部日志，无法按域/按主机授权 |
★★ |
ES _security/role + Kibana Spaces；modules/k8s_efk.py |
| 10 |
ES 自身审计日志（谁查了什么） |
【已知】未开启 |
等保场景缺「审计的审计」 |
★★ |
ES xpack.security.audit 配置 |
| 11 |
静态加密 |
【推断】未做 |
视合规要求 |
★ |
PVC 层 |
四、容量与留存
| # |
能力 |
现状 |
影响 |
优先级 |
在哪能拾起 |
| 12 |
快照备份 |
【实测】GET /_snapshot/_all 返回 { }，无仓库 |
数据盘损坏即全部日志不可恢复 |
★★★ |
需先有 S3/NFS 仓库；docs/RUNBOOK.md 第 182 行「未配置 ES 快照仓库」 |
| 13 |
冷热分层 |
【实测】efk-14d 只有 hot + delete 两阶段 |
14 天数据全在热层，占用与查询成本都吃亏 |
★★ |
config/default.yaml 的 efk.ilm + modules/k8s_efk.py |
| 14 |
~~容量水位告警~~ → 已闭环（2026-10-03） |
✅ 新增 capacity-watermark-alerts：宿主 dell-r620 的 NFS 后端盘（承载 Prometheus TSDB + ES 全部数据，此前完全无预警——现有 ExternalHostDiskSpace* 的 selector 不含该宿主）+ Prometheus TSDB 接近 retentionSize。⚠ PVC 层不做：实测 nfs-csi 的 kubelet_volume_stats_* 失真（同一后端上所有 PVC 报同一 used、capacity 报后端卷总量 491GiB）。⚠ ES 应用层（分片/集群健康/JVM）仍无指标，需 exporter，属剩余缺口 |
无 |
— |
control-plane-metrics-20261003/docs/SOP.md |
五、告警闭环
| # |
能力 |
现状 |
影响 |
优先级 |
在哪能拾起 |
| 15 |
~~日志内容告警（如"认证失败激增""出现 OOM"）~~ → 已落地（2026-10-01） |
✅ 集群外内容探针（查 ES _count → textfile）+ 5 条规则（认证失败/OOM/存储/崩溃/探针失联），零 Alertmanager 改动复用既有 category×severity 路由；ES 侧新建只读账号 logwatch_reader。⚠ 未用 Watcher（basic license 不含）与 Kibana Alerting（需改 Alertmanager 路由） |
无 |
— |
monitoring-p2-20261001/docs/SOP.md §5 步骤 9.9 |
| 16 |
告警分级 / 路由 / 抑制 |
【已知】Prometheus 侧有 inhibit_rules |
— |
★ |
env-monitor-email-p3 |
六、采集覆盖（本会话结论）
| # |
项 |
现状 |
优先级 |
| 17 |
LSF 集群日志 |
✅ 已纳管（lsf-logdir-20261001/SOP.md，单点采集） |
— |
| 18 |
Lustre |
✅ 无需（服务端无独立日志，其信息走内核日志且已在采） |
— |
| 19 |
EDA 工具作业日志 |
❌ 未立项；位于用户作业目录、量大且属用户数据 |
★★ 须先定采集范围与脱敏策略 |
3. 建议推进顺序
- 先补三个"不做就不合格"的：#1 服务维度（改动小、见效最直接）、#5 投递可观测（防止悄悄丢日志）、#15 日志内容告警。
- 再看 EDA 价值项：#2 作业字段抽取（本环境是 EDA 场景，收益高于通用环境）。
- 安全三条一起做更省事：#8 传输加密、#9 RBAC、#10 审计——它们都动 ES/Kibana 的安全配置，一次窗口改完。
- 容量两条：#12 快照备份需要先解决"存哪里"（S3 或 NFS），#13 冷热分层可与它一起设计。
4. 本清单不包含（对本环境是伪需求）
| 行业常见做法 |
为什么本环境不做 |
| Kafka / Redis 缓冲层 |
日增百万级、单 ES，引入中间件只增加运维面，收益不抵成本 |
| APM / trace 关联 |
环境无微服务调用链，日志与 trace 无从关联 |
| WORM / 防篡改存储 |
日志为可再生成数据（RUNBOOK 已明确），合规上也未被要求 |
| 全量静态加密 |
无合规硬要求前，收益低于运维复杂度 |
| 日志全文脱敏流水线 |
当前采集面不含用户作业输出（EDA 立项时再单议） |
5. 判定依据（可复现）
| 结论 |
证据 |
service.name 相关字段已存在但覆盖 2.6% |
_field_caps + exists 计数：systemd.unit 20,009 / log.syslog.appname 20,509 / log.file.path 749,107 / 总 769,286 |
| 字段取值可达服务粒度 |
log.syslog.appname TOP：slurmdbd 2711、sshd-session 1064、slurmctld 475、slurmd 24；systemd.unit 同步 |
| 无快照仓库 |
GET /_snapshot/_all → { } |
| ILM 仅两阶段 |
GET /_ilm/policy/efk-14d → phases: hot(rollover 1d) + delete(min_age 14d) |
| 无细粒度角色 |
GET /_security/role 非内置仅 filebeat_writer_role 等少量 |
| 无多行/时间戳解析 |
模板 artifacts/filebeat-host.yml.tpl 全文无 multiline / timestamp processor |
来源：/home/rain/Documents/k8s_ins/docs/LOGGING-GAP.md ｜ 最后更新：2026-10-03 01:42（由 build/sync.py 同步，请勿在站点侧修改）