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

报告生成时间：2026-10-27 10:10 CST
统计窗口：2026-10-26 00:00 – 24:00 CST（UTC 2026-10-25T16:00Z – 2026-10-26T16:00Z）
查询方式：只读 ES DSL（es-query skill），时间字段 @timestamp，聚合字段均用 .keyword

一、总览

索引	昨日总量	基线/参考	环比（vs 10-25 日报）	判定
youdu_next_log-2026.10.26	8,791,883（仅覆盖 CST 08:00–24:00，见备注①）	治理后常态	+143%（前值 3,619,950，同为 16h 覆盖）	⚠️ 未破 1200 万阈值，但环比大幅增长，需关注
system-log-2026.10.26	11,459,508（完整 CST 24h）	治理后常态 ~1050 万/天；关 dockerd 后目标 ~800 万	+55%（前值 7,386,657）	✅ 低于 1200 万阈值，回到基线区间

① youdu 索引按 UTC 滚日且仅保留 2 天：youdu_next_log-2026.10.25 已被删除，昨日 CST 00:00–08:00 的数据落在该索引中、现已不可查。可比性说明：10-25 日报同样是 16 个 UTC 小时桶（同为部分覆盖），因此环比口径一致；若按 16h 覆盖外推全天约 1300 万，已接近/越过 1200 万黄线，建议持续跟踪。

二、A. youdu_next_log-2026.10.26 明细

检查项	计数	判定
总文档数（CST 08:00–24:00）	8,791,883	⚠️ 环比 +143%，观察项
log_type_unmatched	274（前值 2）	✅ 低位
parsefail_kitex	19,289（前值 11,798）	⚠️ 观察项（占比 0.22%，随总量增长）
parsefail_nsq	2,880（前值 2,880）	✅ 持平
err_unparsed	2,613（前值 2,486）	✅
goapp_dissectfail	0	✅
caddy_parsefail	0	✅
ylog_parsefail	0	✅ remoteAddr[0] 修复保持有效，未再出现非法键名
_grokparsefailure	0	✅
hook 刷屏（"can't rename log file"）	0	✅ 无回归（红色项）
Invalid FieldReference	0	✅ 无回归
gin-access 缺 gin_status	280（前值 0）	✅ 量级极小，观察即可

无效 tag 合计约 25,058 条，占比 0.29%，结构健康。

小时分布（CST 08:00–24:00，16 桶）：25.7 万 → 早高峰爬升至 80.8 万（09:00），峰值 838,703（CST 14:00），晚 21:00 后回落至 22–25 万/时。曲线与业务作息一致，无孤立异常尖峰。

三、B. system-log-2026.10.26 明细

检查项	计数	判定
总文档数	11,459,508	✅ 基线 ~1050 万区间
事件转储回显（"@version" => "1" 精确签名）	1,396	🔴 红色告警（见定位）
syslog_hostname 字面量（%{fields.server_name}）	0	✅ 无回归
mapper_parsing_exception + infra_day	0	✅ 无回归
mapper_parsing_exception + apiVersion	0	✅ 组合模板生效（已核对 `_index_template` 列表存在 `tw-cloudwatch-fix"`，带尾引号不影响功能）
clickhouse-server 日志	0	✅ 无回归（红色项，正常≈0）
_grokparsefailure	336,304（前值 222,474，+51%）	⚠️ 观察项，336,272 来自 LAN_addcn_117（pmm-agent 颜色码日志，与 10-25 结论一致）
无效碎片总量（regexp "[0-9]+\. " / "[0]" / "from /"）	1,824,686（前值 1,220,625，+49%）	⚠️ 观察项，来源见下

🔴 红色告警定位：logstash 事件转储回显回归

进程：logstash[1214328]，机器：LAN_addcn_35（即 2026-09-22 曾修复的 11 个挂 stdout{codec=>rubydebug} pipeline 的同一台机器）。
时间分布：集中在 CST 02:00–05:00（约 464 条/小时 × 3 小时），05:00 后归零（05:00、14:00 各 1 条零星）。样本文档确认 syslog_program=logstash[1214328]、来源 /var/log/messages、filebeat 重新采集，签名与历史自噬回显完全一致。
判断：疑似 10-26 凌晨有人重启/改动过 LAN_addcn_35 的 logstash pipeline，短暂恢复了 stdout rubydebug 输出，约 3 小时后（可能被再次修正或重启）自愈。建议人工核查 LAN_addcn_35 的 logstash 配置变更记录（02:00 前后），确认 11 个 pipeline 的 stdout 输出已全部移除，避免复发。

无效碎片 Top5 来源

机器	进程	计数	备注
LAN_addcn_45	dockerd	470,301	已知待办（debug 未关），不告警；较 10-25 的 32.3 万回升
LAN_addcn_82	haproxy[124397]	433,820	观察项（+52%），另 rpc.mountd 34,398
LAN_addcn_22	kubelet[257775]	216,459	观察项（+47%）
LAN_addcn_26	automount[1174] / haproxy[12569]	57,448 / 49,788	观察项
LAN_addcn_185	kubelet[4102]	46,433	观察项
其余（长尾）	—	~950,000	含 sum_other 未展开部分

小时分布（完整 CST 24h）：44.6 万–55.3 万/时，平稳无尖峰（凌晨 02:00–04:00 的回显仅 ~1400 条，在小时量级上不可见）。

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

节点	disk.percent	disk.used	disk.avail	disk.total	判定
elasticsearch-master-1	75%（最高）	74.3gb	23.5gb	97.8gb	🟡 已达 75% 黄色临界（最高水位节点由 master-0 切换为 master-1）
elasticsearch-master-0	74%（前值 73%）	73.1gb	24.7gb	97.8gb	🟡 黄色边缘
elasticsearch-master-2	45%（前值 50%）	44.5gb	53.2gb	97.8gb	✅

集群 health：green（0 unassigned；检测时 tw591-cloudwatch-20261021 副本、win_smb_log-2026.10.27 副本处于 RELOCATING，属正常分片迁移，非异常）。
索引总存储 188.6 GiB（前值 186.3 GiB，缓涨）。youdu_next_log 旧索引删除（10.25 已不存在）是期间主要清理动作。

索引存储 Top 家族：

家族	存储	占比	索引数	日均/索引
system-log	40.4 GiB	21.4%	7	~5.8 GiB
k8s-audit	35.9 GiB	19.0%	7	~5.1 GiB
logstash-nginx_access	30.3 GiB	16.1%	7	~4.3 GiB
win_smb_log	21.9 GiB	11.6%	7	~3.1 GiB
tw8591-cloudwatch	12.6 GiB	6.7%	7	~1.8 GiB
mysql_audit	11.4 GiB	6.1%	7	~1.6 GiB
其余（tw591-cloudwatch 9.1G、.monitoring-es-7 7.3G、mysql_error 7.2G、youdu_next_log 6.6G 等）	~35.1 GiB	18.6%	—	—

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

删除 system-log + k8s-audit 各最旧 3 天：约 (5.8+5.1)×3 ≈ 33 GiB，总存储 188.6→~156 GiB；master-1（最高水位）预计 75%→约 64%，脱离黄色临界。
进一步处理 logstash-nginx_access / win_smb_log 各最旧 3 天（约 22 GiB），水位可降至 ~56%。
强烈建议尽快为 system-log、k8s-audit 等大族配置 ILM（保留 7 天自动删除）；youdu_next_log 目前实际只保留 2 天，属隐性清理，建议显式化为 ILM 策略并确认保留期是否符合业务需求。

五、告警汇总

🔴 红色告警 ×1：logstash 事件转储回显回归——1396 条，LAN_addcn_35 logstash[1214328]，CST 02:00–05:00 突发后自愈，需人工核查该机 pipeline 配置变更。
🟡 黄色预警 ×1：master-1 磁盘水位 75%，恰达黄色阈值线（判定规则 >75%，按临界处理）；距 88% 只读线尚有余量，但需落实清理/ILM。
⚠️ 观察项（不告警）：youdu 总量环比 +143%（16h 覆盖 879 万，外推全天 ~1300 万逼近黄线）；system-log 无效碎片 182 万/天（+49%）；_grokparsefailure 33.6 万/天（LAN_addcn_117 pmm-agent）；dockerd debug 噪音回升至 47 万/天（已知待办）。

六、当日结论

昨日（2026-10-26）为需处置日：LAN_addcn_35 的 logstash 事件转储回显在 09-22 修复后首次回归（1396 条，02:00–05:00 突发后自愈），虽量级远小于历史 ~280 万/天，但需人工核查该机 02:00 前后的 pipeline 配置变更，确认 stdout rubydebug 未被重新引入。集群磁盘最高水位升至 75%（master-1，已切换为最高节点），已达黄色临界，建议尽快执行 system-log/k8s-audit 旧索引清理或落地 ILM（删 3 天约释放 33 GiB、水位降至 ~64%）。其余历史治理项（hook 刷屏、Invalid FieldReference、ylog_parsefail、syslog_hostname 字面量、infra_day/apiVersion mapper 400、clickhouse-server 堆栈）全部零回归；apiVersion 保持 0 且组合模板在位。另需关注 youdu 日总量环比翻倍以上增长及 system-log 无效碎片回升至 182 万/天，建议下阶段纳入清洗计划（LAN_addcn_117 pmm-agent 颜色码、LAN_addcn_82 haproxy、dockerd debug 待办）。