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

生成时间：2026-10-26 10:10 CST ｜统计窗口：2026-10-25 00:00–24:00 CST（UTC 2026-10-24T16:00Z – 2026-10-25T16:00Z）

一、总览

索引	昨日总量	基线/参考	判定
youdu_next_log-2026.10.25	3,619,950	治理后常态（无刷屏）	✅ 正常
system-log-2026.10.25	7,386,657	治理后常态 ~1050 万/天；关 dockerd 后目标 ~800 万	✅ 正常（低于基线，见备注）

双索引日总量均 < 1200 万黄色阈值，无总量预警。
system-log 实测 739 万/天，明显低于 09-23 后基线 ~1050 万：dockerd debug 噪音已从 ~250 万/天降至 ~32.3 万/天（LAN_addcn_45），推测 debug 级别已部分关闭或日志量自然回落，可关注是否稳定。
环比：outputs/ 下无更早的 es-invalid-data-report-*.md，本篇为首份日报，无环比基准。

二、youdu_next_log-2026.10.25 无效数据分类

检查项	计数	判定
总文档数	3,619,950	✅
log_type_unmatched	2	✅
parsefail_kitex	11,798	观察项（占比 0.33%，常态量级）
parsefail_nsq	2,880	✅
err_unparsed	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	0	✅

无效 tag 合计约 17,166 条，占总量 0.47%，处于低位。

小时分布：16 个 UTC 小时桶（对应 CST 全天 24h）总量 361.99 万，峰值 319,633（CST 18:00-19:00），谷值 163,174（CST 22:00-23:00），曲线平稳，无异常尖峰。

三、system-log-2026.10.25 无效数据分类

检查项	计数	判定
总文档数	7,386,657	✅
事件转储回显（"@version" => "1"）	0	✅ 无回归（红色项）
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	222,474	⚠️ 观察项，全部来自 LAN_addcn_117
无效碎片总量（regexp/match 组合）	1,220,625	观察项，来源见下

_grokparsefailure 定位：222,474 条全部来自 LAN_addcn_117 的 pmm-agent（syslog_program 为空，message 含 ANSI 颜色码 #033[36m...，pmm-agent VictoriaMetrics 的 INFO 级刷屏日志带颜色码导致 grok 解析失败）。约 22 万条/天，建议后续在采集侧（filebeat 或 logstash ruby 清洗 ANSI 码）处理，属新噪音源，非历史修复回归。

无效碎片 Top 来源（machine × program）：

机器	进程	计数	备注
LAN_addcn_45	dockerd	323,109	已知待办（debug 未关），不告警；量已较 ~250 万/天大幅回落
LAN_addcn_82	haproxy[124397]	285,543	观察项
LAN_addcn_22	kubelet[257775]	147,092	观察项
LAN_addcn_26	haproxy[12569] / automount[1174]	39,638 / 38,251	观察项
LAN_addcn_185	kubelet[4102]	30,566	观察项
其余	—	287,992	长尾

小时分布：各小时 45.1 万–47.9 万条，曲线极平稳（峰值/谷值比 1.06），无尖峰。

四、集群磁盘水位巡检

节点	disk.percent	disk.used	disk.avail	disk.total
elasticsearch-master-0	73%（最高）	71.9gb	25.9gb	97.8gb
elasticsearch-master-1	71%	70.2gb	27.6gb	97.8gb
elasticsearch-master-2	50%	49.5gb	48.2gb	97.8gb

集群 health：green（3 节点，328 分片全部 STARTED，0 unassigned），panabit_log 旧副本 ALLOCATION_FAILED 问题已不存在。
索引总存储 186.3 GiB（较 2026-09-22 实测 214GB 下降约 28GB，说明期间已有清理/收缩，或 ILM 生效）。
水位：最高 73%（master-0），未达 75% 黄色线，无预警，但距黄色阈值仅 2 个百分点，建议持续跟踪。

索引存储 Top 家族：

家族	存储	占比	索引数	日均/索引
system-log	40.3 GiB	21.7%	7	~5.8 GiB
k8s-audit	35.0 GiB	18.8%	7	~5.0 GiB
logstash-nginx_access	30.8 GiB	16.6%	7	~4.4 GiB
win_smb_log	22.3 GiB	12.0%	7	~3.2 GiB
tw8591-cloudwatch	12.6 GiB	6.8%	7	~1.8 GiB
mysql_audit	11.3 GiB	6.0%	7	~1.6 GiB
其余（含 tw591-cloudwatch 9.8G、youdu_next_log 3.4G 等）	34.0 GiB	18.2%	—	—

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

若删除 system-log + k8s-audit 各最旧 3 天索引：可释放约 (5.8+5.0)×3 ≈ 32 GiB，集群索引存储 186.3→~154 GiB；按三节点均摊，master-0 磁盘占用约降 10-11 GiB，水位预计 73%→约 62%，脱离 75% 预警区间。
若进一步处理 logstash-nginx_access / win_smb_log 各最旧 3 天（约 23 GiB），水位可降至 ~55%。
建议优先为 system-log、k8s-audit 配置 ILM（如保留 7 天自动删除），一劳永逸控制水位。

五、告警汇总

🔴 红色告警：无（hook 刷屏 0、事件转储回显 0、clickhouse-server 0）
🟡 黄色预警：无（双索引总量均 <1200 万；syslog_hostname 字面量 0；Invalid FieldReference 0；mapper 400 双项 0；磁盘最高 73% <75%；health green）

六、当日结论

昨日（2026-10-25）ES 两索引数据质量整体正常，历史治理项（hook 刷屏、事件转储回显、syslog_hostname 字面量、Invalid FieldReference、infra_day/apiVersion mapper 400、clickhouse-server 堆栈）零回归，全部失效检测项为 0。system-log 日总量 739 万，低于 ~1050 万基线，其中已知待办的 dockerd debug 噪音已从 ~250 万/天回落至 ~32 万/天。需关注两个新噪音源：LAN_addcn_117 的 pmm-agent 颜色码日志导致每日 ~22 万条 grok 解析失败，以及 LAN_addcn_82 haproxy / LAN_addcn_22 kubelet 的碎片日志（合计 ~43 万/天），建议列入下阶段清洗计划。集群磁盘最高水位 73%（master-0），距 75% 黄色线仅一步之遥，建议尽快落实 system-log/k8s-audit 旧索引清理或 ILM 策略（删 3 天约可释放 32 GiB、水位降至 ~62%）。总体无需紧急处置，以持续观察与预防性清理为主。