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

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

一、总览

索引	昨日总量	基线/参考	环比（vs 10-29）	判定
youdu_next_log-2026.11.01	2,969,280（仅 CST 08:00–24:00，16h）	黄线 1200 万/天（全天口径）	-72.7%（前值 10,854,012，同为 16h 覆盖）	🟡 总量大幅回落至黄线以下，但降幅异常大（-73%），需核实是业务日志量真实下降还是采集/投递异常（详见二）
system-log-2026.10.31/01	9,568,027（完整 24h）	基线 ~1050 万/天；黄线 1200 万	-18.2%（前值 11,693,618）	✅ 低于基线与黄线，首次回到 ~950 万量级（10-29 曾剔除 pmm-agent 噪音后仍 ~1129 万，本次 _grokparsefailure 噪音已基本消失）

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

指标	数值	环比	判定
总文档数（CST 08:00–24:00）	2,969,280	-72.7%	🟡 按 16h 外推全天 ≈445 万，远低于 1200 万黄线；但单日 -73% 属异常波动，需与业务方核实日志量是否真实下降（昨日 09:00–17:00 高位时段曾 76–97 万/h，今日同段仅 18–26 万/h）
log_type_unmatched	4	基本为 0	✅
parsefail_kitex	11,818	平稳（前值 11,885）	⚠️ 观察项（量级不变）
parsefail_nsq	2,880	持平（前值 2,880）	✅
err_unparsed	2,515	平稳（前值 2,889）	✅
goapp_dissectfail / caddy_parsefail / ylog_parsefail / _grokparsefailure	均 0（terms 聚合无桶；另见 _dissectfailure 1、infra_kitex_dissectfail 1，可忽略）	持平	✅ remoteAddr[0] 修复持续有效，未出现新的非法键名（<;5000，无需抽样）
hook 刷屏（"can't rename log file"）	0	持平	✅ 无回归（红色项）
Invalid FieldReference	0	持平	✅ 无回归
gin-access 缺 gin_status	2	低位（前值 33）	✅
按小时分布	08:00 起量 17 万，09:00 峰值 25.7 万，白天 18–25 万/h，晚间回落至 13–16 万/h	曲线形态正常、无尖峰；但整体水位仅为 10-29 的 ~25%	🟡 无异常尖峰，量级骤降待核实

无效/解析失败类 tag 合计 ≈ 17,219（占 0.58%），绝对量与占比均平稳；youdu 总量骤降与解析质量无关（各 parsefail 比例稳定），更像上游日志产出量下降或投递链路问题。

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

指标	数值	环比	判定
总文档数	9,568,027	-18.2%	✅ 低于基线（~1050 万）
事件转储回显（`"@version" => "1"` 精确签名）	931 🔴	持平（前值 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）	38,737	-90.4%（前值 405,016）	✅ 10-29 的 LAN_addcn_117 pmm-agent 颜色码噪音（~40.5 万/天）已消失，明显改善
无效碎片总量（regexp `[0-9]+\.` / "[0]" / "from /"）	1,448,570	-13.0%（前值 1,665,310）	⚠️ 观察项（仍以已知 dockerd/kubelet/haproxy 噪音为主）
按小时分布	36.7–48.9 万/h，凌晨 02:00/04:00 略高（cron 任务），全天平滑	平滑	✅ 无尖峰

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

机器	进程	总量	时间分布
LAN_addcn_35	logstash[1214328]	931	11-01 02:00（310）/ 03:00（309）/ 04:00（310）+ 05:00（1）、17:00（1）

性质判定（沿用 10-27 ~ 10-29 结论）：logstash Dissector WARN「pattern not found」事件转储——youdu pipeline 对 Windows 主机 d032019080022-v 的 ng_kv_err.log 执行 infra dissect 失败，WARN 日志把含 "@version" => "1" 的事件体打进 /var/log/messages 被 filebeat 重采。并非 stdout rubydebug 回归。已连续第五晚 02:00–04:00 准时复发（约 310 条/h），量级稳定无恶化；建议对 Dissector WARN 降噪并排查该 Windows 主机的夜间 panic 定时任务。

无效碎片 Top5 来源

机器	总量	主要进程	备注
LAN_addcn_45	467,091	dockerd 458,927、kubelet 5,220、journal 2,847	已知待办（dockerd debug 未关），标注不告警
LAN_addcn_82	297,848	haproxy[124397] 228,182、rpc.mountd[96046] 34,366、filebeat 10,320	⚠️ 持续观察项（较 10-29 的 360,575 略降）
LAN_addcn_26	101,510	automount[1174] 57,482、haproxy[12569] 40,064	观察项
LAN_addcn_22	85,949	kubelet[257775] 80,449、filebeat 2,880	已知（dockerd/kubelet 噪音带；dockerd 部分本日未进前三进程，总量较 10-29 的 231,256 明显下降）
LAN_addcn_185	66,543	kubelet[4102] 56,745、filebeat 2,880	观察项

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

每节点水位（_cat/allocation）

节点	disk.percent	disk.used	disk.avail	disk.total	分片数	判定
elasticsearch-master-0（10.2.70.159）	66%（最高）	65.1 GB	32.6 GB	97.8 GB	109	✅ <;75% 黄线
elasticsearch-master-1（10.2.200.32）	61%	60.5 GB	37.3 GB	97.8 GB	109	✅
elasticsearch-master-2（10.2.231.216）	58%	57.3 GB	40.5 GB	97.8 GB	110	✅

集群 health：green（164 主分片 / 328 全部分片，unassigned=0），无非 STARTED 分片。
索引总量 177.2 GiB，较 10-29 的 184.8 GiB 下降 7.6 GiB；多数家族索引数已收敛至 7 个（约 7 天保留），说明有定期清理/ILM 在生效（youdu_next_log 仅 2 天）。

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

家族	存储	占比	索引数	文档数
system-log	38.2 GiB	21.6%	7	66,791,197
logstash-nginx_access	32.2 GiB	18.2%	7	35,953,930
win_smb_log	26.4 GiB	14.9%	7	18,314,304
k8s-audit	25.6 GiB	14.4%	7	10,200,517
mysql_audit	12.5 GiB	7.1%	7	17,066,676
tw8591-cloudwatch	11.3 GiB	6.4%	7	4,463,960
tw591-cloudwatch	9.1 GiB	5.1%	7	4,292,094
.monitoring-es-7	7.3 GiB	4.1%	7	7,618,821
mysql_error	4.5 GiB	2.5%	7	22,466,518
logstash-traefik_access	4.3 GiB	2.4%	7	5,360,345
youdu_next_log	3.1 GiB	1.7%	2	5,306,541
k8s-log	1.7 GiB	1.0%	7	2,884,092
k8s-event-log	0.5 GiB	0.3%	7	326,055
system_secure	0.3 GiB	0.2%	7	384,396
elastalert_status_status	0.1 GiB	0.1%	1	628,094

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

当前水位最高节点 66%，未触发 75% 黄线，无需紧急清理；且家族保留已收敛至 ~7 天，总量呈下降趋势（184.8 → 177.2 GiB）。
若需进一步腾挪：以 Top 家族日均（总占用/索引数，含副本）估算——
system-log ≈5.5 GiB/天：删最旧 2 天可释放约 11 GB，master-0 disk.indices 63.2→~58.3 GB，水位预计 66%→~62%；
logstash-nginx_access ≈4.6 GiB/天：删最旧 2 天可释放约 9 GB，水位预计降至 ~60%；
二者合计删 2 天约释放 20 GB，水位预计 66%→~59%。
建议：保留现状观察即可；如要执行，优先走 ILM 统一保留策略（当前约 7 天已较合理），不建议手工单删。

五、告警汇总

🔴 红色告警

事件转储回显 931 条（system-log，LAN_addcn_35 / logstash[1214328]，02:00–05:00 定时复发）——连续第五晚，量级稳定；根因为 Dissector WARN 事件转储 + Windows 主机 d032019080022-v 夜间 panic 任务，建议本周内处置（WARN 降噪或修复该主机定时任务）。

🟡 黄色预警

youdu_next_log 日总量骤降 -72.7%（16h 口径 10,854,012 → 2,969,280）：解析质量指标全部正常，骤降更像上游业务日志产出下降或采集/投递链路异常，建议核实 filebeat/logstash 投递与业务侧发布记录（10-30、10-31 无日报，骤降发生区间无法精确界定）。
无其他黄色项：syslog_hostname 字面量 0、Invalid FieldReference 0、mapper_parsing_exception（infra_day/apiVersion）均 0。

✅ 正常项

hook 刷屏 0；clickhouse-server 0；集群 green；三节点水位 58–66%（<75%）；system-log 总量 957 万（首次低于 1050 万基线）；_grokparsefailure 38,737（-90%，pmm-agent 噪音消失）。

六、总结

2026-11-01 整体需关注：治理基线全部保持有效（hook 刷屏、FieldReference、hostname 字面量、mapper 400、clickhouse 堆栈均零回归），集群 green、水位回落至 58–66%，system-log 总量首次降至基线以下且 pmm-agent grok 噪音消失，态势向好。唯一红色项是 LAN_addcn_35 的 logstash 事件转储回显（931 条，连续第五晚 02:00–04:00 定时复发），建议尽快对 Dissector WARN 降噪并排查 Windows 主机夜间任务。另需重点核实 youdu_next_log 单日 -73% 的量级骤降是业务真实下降还是采集链路异常——这是本日最大的不确定性。

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