ES 无效数据日报 2026-11-02

统计窗口：2026-11-02 00:00 – 24:00 CST（UTC 2026-11-01T16:00Z – 2026-11-02T16:00Z）
口径说明（沿用前几日日报）：两索引均按 UTC 滚日。system-log 通过 system-log-2026.11.01,2026.11.02 双索引查询获得完整 CST 24h；youdu_next_log 仅保留 2 天，CST 00:00–08:00 数据不可查，仅覆盖 CST 08:00–24:00（16h），与前几日日报口径一致，环比可比。
上一次日报为 2026-11-01，环比均 vs 11-01。

一、总览

索引	昨日总量	基线/参考	环比（vs 11-01）	判定
youdu_next_log-2026.11.02	10,704,270（仅 CST 08:00–24:00，16h）	黄线 1200 万/天	+260.5%（前值 2,969,280，同为 16h 覆盖）	✅ 11-01 的骤降已回升至常态（与 10-29 的 10,854,012 基本持平，-1.4%），确认前日为单日异常，非采集链路持续故障
system-log-2026.11.01/02	9,857,361（完整 24h）	基线 ~1050 万/天；黄线 1200 万	+3.0%（前值 9,568,027）	✅ 连续第二日低于基线与黄线

二、A. youdu_next_log-2026.11.02 明细（CST 08:00–24:00）

指标	数值	环比	判定
总文档数（CST 08:00–24:00）	10,704,270	+260.5%	✅ 回升至 10-29 量级（10,854,012），11-01 的 -73% 骤降为单日异常，前日黄色预警可关闭
log_type_unmatched	2	持平（前值 4）	✅
parsefail_kitex	11,872	平稳（前值 11,818）	⚠️ 观察项（量级不变）
parsefail_nsq	2,880	持平（前值 2,880）	✅
err_unparsed	2,645	平稳（前值 2,515）	✅
goapp_dissectfail / caddy_parsefail / ylog_parsefail / _grokparsefailure	均 0（terms 聚合无桶；另见 _dissectfailure 1、infra_kitex_dissectfail 1，可忽略）	持平	✅ remoteAddr[0] 修复持续有效，ylog_parsefail <;5000 无需抽样
hook 刷屏（"can't rename log file"）	0	持平	✅ 无回归（红色项）
Invalid FieldReference	0	持平	✅ 无回归
gin-access 缺 gin_status	3	低位（前值 2）	✅
按小时分布	08:00 起量 30.7 万，白天 62–100 万/h（15:00 峰值 100.1 万），晚间回落至 31–38 万/h	曲线形态与 10-29 常态一致	✅ 无异常尖峰

无效/解析失败类 tag 合计 ≈ 17,401（占 0.16%），绝对量与占比均平稳；总量回升伴随解析质量指标零变化，确认前日骤降系上游日志产出/投递单日异常，现已恢复。

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

指标	数值	环比	判定
总文档数	9,857,361	+3.0%	✅ 连续第二日低于基线（~1050 万）
事件转储回显（`"@version" => "1"` 精确签名）	966 🔴	持平（前值 931，连续第六晚复发）	🔴 红色告警，定位见下
syslog_hostname 字面量（%{fields.server_name}）	0	持平	✅ grok 修复无回归
mapper_parsing_exception × infra_day	0	持平	✅
mapper_parsing_exception × apiVersion	0	持平	✅ 组合模板持续生效（09-23 起）
clickhouse-server 日志	0	持平	✅ 无回归（红色项）
_grokparsefailure（tags）	39,029	+0.8%（前值 38,737）	✅ 平稳（pmm-agent 噪音治理后常态量级）
无效碎片总量（regexp `[0-9]+\.` / "[0]" / "from /"）	1,508,923	+4.2%（前值 1,448,570）	⚠️ 观察项（仍以已知 dockerd/kubelet/haproxy 噪音为主）
按小时分布	36.8–50.8 万/h，凌晨 00:00–04:00 略高（cron 任务），全天平滑	平滑	✅ 无尖峰

🔴 事件转储回显定位（红色）

机器	进程	总量	时间分布
LAN_addcn_35	logstash[1214328]	931	11-02 02:00（309）/ 03:00（310）/ 04:00（310）/ 05:00（1）、09:00（1）
LAN_addcn_45	dockerd	35	11-02 10:00（35）

性质判定（沿用 10-27 ~ 11-01 结论）：logstash Dissector WARN「pattern not found」事件转储——youdu pipeline 对 Windows 主机 d032019080022-v 的 ng_kv_err.log（Go panic 栈行 \tC:/Go/src/runtime/panic.go:884 ... 不匹配 infra dissect 模板）执行失败，WARN 日志把含 "@version" => "1" 的事件体打进 /var/log/messages 被 filebeat 重采。并非 stdout rubydebug 回归（本日抽样确认同一签名）。LAN_addcn_35 部分连续第六晚 02:00–04:00 准时复发（约 310 条/h），量级稳定无恶化；LAN_addcn_45 的 dockerd 35 条为新出现的零星回显（10:00 单小时，同样为嵌套事件转储文本）。建议对 Dissector WARN 降噪并排查该 Windows 主机的夜间 panic 定时任务。

无效碎片 Top5 来源

机器	总量	主要进程	备注
LAN_addcn_45	456,044	dockerd 447,761、kubelet 5,243、journal 2,824	已知待办（dockerd debug 未关），标注不告警
LAN_addcn_82	333,774	haproxy[124397] 262,113、rpc.mountd[96046] 34,526、filebeat 10,032	⚠️ 持续观察项（较 11-01 的 297,848 略升）
LAN_addcn_26	103,484	automount[1174] 57,388、haproxy[12569] 42,144	观察项
LAN_addcn_22	91,163	kubelet[257775] 79,797、filebeat 2,880	已知（kubelet 噪音带）
LAN_addcn_185	73,516	kubelet[4102] 62,510、filebeat 2,880	观察项

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

每节点水位（_cat/allocation）

节点	disk.percent	disk.used	disk.avail	disk.total	分片数	判定
elasticsearch-master-0（10.2.70.159）	71%（最高）	70.1 GB	27.7 GB	97.8 GB	110	✅ <;75% 黄线，但较 11-01 的 66% 上升 5pp，需持续跟踪
elasticsearch-master-1（10.2.200.32）	63%	61.7 GB	36.1 GB	97.8 GB	110	✅
elasticsearch-master-2（10.2.231.216）	52%	51.6 GB	46.2 GB	97.8 GB	110	✅

集群 health：green（165 主分片 / 330 全部分片，unassigned=0），无非 STARTED 分片。
索引总量 178.6 GiB，较 11-01 的 177.2 GiB 微增 1.4 GiB（youdu_next_log 本日量回升 +694 万条所致）；多数家族索引数收敛至 7 个（约 7 天保留）。

索引存储 Top15 家族（合计占比 ~99%）

家族	存储	占比	索引数
system-log	37.1 GiB	20.8%	7
logstash-nginx_access	31.5 GiB	17.6%	7
win_smb_log	26.7 GiB	14.9%	7
k8s-audit	23.9 GiB	13.4%	7
mysql_audit	13.1 GiB	7.3%	7
tw8591-cloudwatch	11.5 GiB	6.4%	7
tw591-cloudwatch	9.8 GiB	5.5%	7
youdu_next_log	7.9 GiB	4.4%	2
.monitoring-es-7	7.4 GiB	4.1%	7
logstash-traefik_access	3.8 GiB	2.1%	7
mysql_error	3.3 GiB	1.8%	7
k8s-log	1.7 GiB	1.0%	7
k8s-event-log	0.5 GiB	0.3%	7
system_secure	0.3 GiB	0.2%	7
elastalert_status_status	0.1 GiB	0.1%	1

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

当前水位最高节点 master-0 为 71%，未触发 75% 黄线，无需紧急清理；但较 11-01（66%）上升 5pp，若按此斜率 1–2 天内可能触线，建议跟踪。
若需腾挪：以 Top 家族日均（总占用/索引数，含副本）估算——
system-log ≈5.3 GiB/天：删最旧 2 天可释放约 11 GB，master-0 水位预计 71%→~67%；
logstash-nginx_access ≈4.5 GiB/天：删最旧 2 天可释放约 9 GB，水位预计降至 ~65%；
二者合计删 2 天约释放 20 GB，水位预计 71%→~63%。
建议：优先为 win_smb_log（26.7 GiB）、k8s-audit（23.9 GiB）配 ILM 统一保留策略；不建议手工单删。

五、告警汇总

🔴 红色告警

事件转储回显 966 条（system-log：LAN_addcn_35 / logstash[1214328] 931 条，连续第六晚 02:00–04:00 定时复发；LAN_addcn_45 / dockerd 35 条零星新增）——根因为 Dissector WARN 事件转储 + Windows 主机 d032019080022-v 夜间 panic 任务，建议尽快处置（WARN 降噪或修复该主机定时任务）。

🟡 黄色预警

master-0 磁盘水位 71%（较 11-01 +5pp）：未触 75% 黄线，但上升斜率偏快（youdu 量回升所致），列为观察项；若明日 ≥75% 触发黄色预警，参考第四节清理建议。
无其他黄色项：syslog_hostname 字面量 0、Invalid FieldReference 0、mapper_parsing_exception（infra_day/apiVersion）均 0，两索引日总量均在黄线以下。

✅ 正常项

hook 刷屏 0；clickhouse-server 0；集群 green；三节点水位 52–71%（<75%）；system-log 总量 986 万（低于 1050 万基线）；youdu 总量回升至常态 1070 万，11-01 的骤降预警解除。

六、总结

2026-11-02 整体需关注：治理基线全部保持有效（hook 刷屏、FieldReference、hostname 字面量、mapper 400、clickhouse 堆栈均零回归），集群 green，system-log 连续第二日低于基线。youdu_next_log 总量回升至 1070 万（+260%），确认 11-01 的骤降为单日异常而非采集链路持续故障，前日预警解除。唯一红色项仍是 LAN_addcn_35 的 logstash 事件转储回显（931 条，连续第六晚 02:00–04:00 定时复发），另有 LAN_addcn_45 dockerd 35 条零星同签名回显，建议尽快对 Dissector WARN 降噪并排查 Windows 主机 d032019080022-v 的夜间 panic 任务。磁盘方面 master-0 水位 71%（+5pp），youdu 量回升推高占用，若继续上行触 75% 黄线则按 Top 家族清理建议（删 2 天约释放 20 GB）处置。

*生成时间：2026-11-03 10:10 CST；数据来源：ES 只读查询（es-query skill）+ _cat 直连只读 GET。*