ES 无效数据日报 2026-10-27

报告生成时间：2026-10-28 10:10 CST
统计窗口：2026-10-27 00:00 – 24:00 CST（UTC 2026-10-26T16:00Z – 2026-10-27T16:00Z）
查询方式：只读 ES DSL（es-query skill），时间字段 @timestamp，聚合字段均用 .keyword
口径说明：两个索引均按 UTC 滚日。system-log 通过通配符 system-log-2026.10.2* 查询获得完整 CST 24h；youdu_next_log-2026.10.26 已被删除（实际只保留 2 天），CST 00:00–08:00 数据不可查，仅覆盖 CST 08:00–24:00（16h），与 10-26 日报口径一致，环比可比。

一、总览

索引	昨日总量	基线/参考	环比（vs 10-26 日报）	判定
youdu_next_log-2026.10.27	10,419,940（仅覆盖 CST 08:00–24:00）	治理后常态；黄线 1200 万/天	+18.5%（前值 8,791,883，同为 16h 覆盖）	🟡 按 16h 外推全天约 1563 万，已越过 1200 万黄线（黄色预警，口径见备注）
system-log-2026.10.27	11,825,978（完整 CST 24h）	治理后常态 ~1050 万/天；黄线 1200 万	+3.2%（前值 11,459,508）	✅ 低于黄线，基线区间上沿，持续跟踪

youdu 覆盖口径：16h 实测 1042 万未破阈值，但按小时曲线外推全天 ≈1563 万（前一日外推 ~1300 万），连续两日上行。业务量增长与解析失败需区分，建议核查 parsed_* 各 tag 的增速来源。

二、A. youdu_next_log-2026.10.27 明细

检查项	计数	环比	判定
总文档数（CST 08:00–24:00）	10,419,940	+18.5%	🟡 外推全天 >1200 万，黄色预警
log_type_unmatched	4（前值 274）	-98.5%	✅ 回落至极低位
parsefail_kitex	11,885（前值 19,289）	-38%	✅ 占比 0.11%，改善
parsefail_nsq	2,880（前值 2,880）	持平	✅
err_unparsed	2,592（前值 2,613）	持平	✅
goapp_dissectfail	0	持平	✅
caddy_parsefail	0	持平	✅
ylog_parsefail	0	持平	✅ remoteAddr[0] 修复保持有效，未出现新的非法键名
_grokparsefailure	0	持平	✅
_dissectfailure / infra_kitex_dissectfail	1 / 1	—	✅ 极低位
hook 刷屏（"can't rename log file"）	0	持平	✅ 无回归（红色项）
Invalid FieldReference	0	持平	✅ 无回归
gin-access 缺 gin_status	220（前值 280）	-21%	✅ 量级极小

无效 tag 合计约 17,363 条，占比 0.17%（前值 0.29%），结构健康且继续改善。

小时分布（CST 08:00–24:00，16 桶）：早 08:00 起步 35.7 万 → 09:00 冲高 1,070,578（峰值）→ 白天维持 64–97 万/时 → 晚 21:00 后回落至 23 万/时。曲线与业务作息一致，无孤立异常尖峰。

三、B. system-log-2026.10.27 明细（完整 CST 24h）

检查项	计数	环比	判定
总文档数	11,825,978	+3.2%	✅ 基线上沿
事件转储回显（"@version" => "1" 精确签名）	1,055（前值 1,396）	-24%	🔴 红色告警（连续第二晚复发，见定位）
syslog_hostname 字面量（%{fields.server_name}）	0	持平	✅ 无回归
mapper_parsing_exception + infra_day	0	持平	✅ 无回归
mapper_parsing_exception + apiVersion	0	持平	✅ 组合模板持续生效（自 09-23 起保持为 0）
clickhouse-server 日志	0	持平	✅ 无回归（红色项，正常≈0）
_grokparsefailure	0（前值 336,304）	-100%	✅ LAN_addcn_117 pmm-agent 颜色码噪音已消失（疑似已治理）
无效碎片总量（regexp "[0-9]+\. " / "[0]" / "from /"）	1,744,512（前值 1,824,686）	-4.4%	⚠️ 观察项，来源见下

🔴 红色告警定位：LAN_addcn_35 logstash 事件转储回显（连续第二晚复发）

进程：logstash[1214328]，机器：LAN_addcn_35（2026-09-22 曾修复的同一台）。
时间分布：CST 02:00–04:00 集中（371 / 341 / 341 条），05:00、09:00 各 1 条零星，其余时段为 0。
性质判定（与 09-22 自噬回显不同）：抽样确认这些是 logstash Dissector WARN「pattern not found」事件转储——youdu_next_log pipeline 对 Windows 主机 d032019080022-v 的 D:\Youdu\Server\...\svc_infra\log\ng_kv_err.log（log_type=api-original-log）执行 infra dissect 失败（源消息为 \tpanic: 等短行），WARN 日志把完整事件体（含 "@version"=>"1"）打进 /var/log/messages，被 filebeat 重新采集进 system-log。并非 stdout rubydebug 回归。
与 10-26 日报（1396 条、同为 02:00–05:00）比对：同一模式连续第二晚准时复发，高度怀疑由夜间定时任务（02:00 触发、产生 panic 行写入 ng_kv_err.log）驱动，而非人工改动配置。
建议：① 在 LAN_addcn_35 的 logstash 中给该 Dissector WARN 增加 drop/降噪（或修正 infra pattern 兼容 panic 短行）；② 排查 d032019080022-v 上 02:00 定时任务产生的 panic 根因；③ 确认 stdout rubydebug 确未回归（当前证据不支持回归）。

无效碎片 Top5 来源（完整 24h）

机器	进程	计数	备注
LAN_addcn_45	dockerd	454,165	已知待办（debug 未关），不告警；较前值 47.0 万略降
LAN_addcn_82	haproxy[124397]	363,218	观察项（-16%）；另 rpc.mountd 34,474、filebeat 9,744
LAN_addcn_22	kubelet[257775]	217,620	观察项（与前值 21.6 万持平）
LAN_addcn_26	automount[1174] / haproxy[12569]	57,413 / 44,700	观察项
LAN_addcn_185 / 137	kubelet	48,677 / 44,087	观察项

小时分布（完整 CST 24h）：44.5 万–57.0 万/时，凌晨略高、午后回落，平稳无尖峰（02:00–04:00 的回显 ~1000 条在小时量级上不可见）。

四、C. 集群磁盘水位巡检

节点	disk.percent	disk.used	disk.avail	disk.total	判定
elasticsearch-master-1	76%（最高，前值 75%）	74.3gb	23.4gb	97.8gb	🟡 黄色预警（>75%），连续第二日为最高水位节点
elasticsearch-master-0	66%（前值 74%）	65.0gb	32.8gb	97.8gb	✅ 水位明显回落（分片再平衡生效）
elasticsearch-master-2	51%（前值 45%）	49.9gb	47.8gb	97.8gb	✅

集群 health：green（326 分片全部 STARTED，0 unassigned / relocating，无 yellow/red）。
索引总存储 184.6 GiB（前值 188.6 GiB，净降 4 GiB，期间自然滚动清理大于新增）。

索引存储 Top 家族：

家族	存储	占比	索引数	日均/索引
system-log	40.5 GiB	22.0%	7	~5.8 GiB
k8s-audit	35.0 GiB	19.0%	7	~5.0 GiB
logstash-nginx_access	30.3 GiB	16.4%	7	~4.3 GiB
win_smb_log	19.1 GiB	10.3%	7	~2.7 GiB
tw8591-cloudwatch	12.2 GiB	6.6%	7	~1.7 GiB
mysql_audit	11.2 GiB	6.1%	7	~1.6 GiB
tw591-cloudwatch	8.4 GiB	4.5%	7	~1.2 GiB
youdu_next_log	7.7 GiB	4.2%	2	~3.8 GiB（隐性 2 天保留）
.monitoring-es-7 / mysql_error	7.2 / 7.0 GiB	3.9% / 3.8%	7 / 7	~1.0 GiB
其余（logstash-traefik_access 3.6G、k8s-log 1.5G 等）	~6.9 GiB	3.7%	—	—

可释放估算（仅建议，不执行任何删除）：

删除 system-log + k8s-audit 各最旧 3 天：约 (5.8+5.0)×3 ≈ 32 GiB，总存储 184.6→~153 GiB；master-1 预计 76%→约 65%，脱离黄色区间。
进一步处理 logstash-nginx_access / win_smb_log 各最旧 3 天（约 21 GiB），水位可降至 ~57%。
重申 10-26 建议：尽快为 system-log、k8s-audit 等大族配置 ILM（保留 7 天自动删除）；youdu_next_log 实际仅保留 2 天属隐性清理，建议显式化为 ILM 并确认保留期符合业务需求。

五、告警汇总

🔴 红色告警 ×1：LAN_addcn_35 logstash[1214328] 事件转储回显 1055 条——02:00–04:00 集中，连续第二晚复发；实为 Dissector WARN 事件转储（源 d032019080022-v 的 ng_kv_err.log panic 行），非 stdout rubydebug 回归，但需按上述建议处置（WARN 降噪 + 排查 panic 定时任务）。
🟡 黄色预警 ×2：

master-1 磁盘水位 76%（>75%），距 85% 红线 9 个百分点、88% 只读线 12 个百分点；落实 system-log/k8s-audit 清理或 ILM 后可回落至 ~65%。
youdu 日总量外推 ~1563 万（>1200 万）：16h 实测 1042 万（+18.5%），连续两日上行，建议区分业务增长与解析失败来源。

⚠️ 观察项（不告警）：system-log 无效碎片 174 万/天（-4%，dockerd debug 45 万/天为已知待办）；LAN_addcn_82 haproxy 36 万/天。
✅ 好消息：_grokparsefailure 从 33.6 万/天降至 0（LAN_addcn_117 pmm-agent 颜色码噪音消失）；youdu 无效 tag 占比降至 0.17%；log_type_unmatched 回落至 4。

六、当日结论

昨日（2026-10-27）为需处置日：唯一红色项仍是 LAN_addcn_35 的事件转储回显（1055 条），已连续两晚在 02:00–04:00 准时复发，本次定性为 Dissector WARN 事件转储而非 rubydebug 自噬回归，处置方向是 WARN 降噪加排查 d032019080022-v 夜间 panic 定时任务。磁盘 master-1 水位 76% 触发黄色且连续两日为最高节点，建议尽快执行 system-log/k8s-audit 旧索引清理或落地 ILM（删 3 天约释放 32 GiB、水位降至 ~65%）。youdu 总量连续两日上行（16h 1042 万，外推全天 ~1563 万越黄线），需区分业务增长因素。其余历史治理项（hook 刷屏、Invalid FieldReference、ylog_parsefail、hostname 字面量、infra_day/apiVersion mapper 400、clickhouse-server 堆栈）全部零回归；_grokparsefailure 归零、无效 tag 占比降至 0.17%，整体无效数据结构持续改善。