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

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

一、总览

索引	昨日总量	基线/参考	环比（vs 11-03）	判定
youdu_next_log-2026.11.04	12,111,153（仅 CST 08:00–24:00，16h）	黄线 1200 万/天	+6.4%（前值 11,381,354，同为 16h 覆盖）	🟡 首破黄线：20:30 业务 error 突发 147 万条所致（见 A 明细），剔除后常态量级 ~1,064 万
system-log（11.03+11.04 双索引）	11,866,081（完整 24h）	基线 ~1050 万/天；黄线 1200 万	+13.0%（前值 10,499,466）	⚠️ 未触黄线但涨幅明显、逼近 1200 万，主因 dockerd debug 未关（已知待办）

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

指标	数值	环比	判定
总文档数（CST 08:00–24:00）	12,111,153	+6.4%	🟡 超 1200 万黄线，但为一次性突发驱动（见下）
log_type_unmatched	8	↓（前值 20）	✅
parsefail_kitex	11,943	+0.5%（前值 11,880）	⚠️ 观察项（量级不变）
parsefail_nsq	2,880	持平（前值 2,880）	✅
err_unparsed	2,748	+6.1%（前值 2,591）	✅
goapp_dissectfail / caddy_parsefail / ylog_parsefail / _grokparsefailure	均 0（terms 聚合无桶）	持平	✅ remoteAddr[0] 修复持续有效，ylog_parsefail <;5000 无需抽样
hook 刷屏（"can't rename log file"）	0	持平	✅ 无回归（红色项）
Invalid FieldReference	0	持平	✅ 无回归
gin-access 缺 gin_status	12（gin-access 总量 3,308,715）	↓（前值 26）	✅ 占比 0.0004%，可忽略
按小时分布	白天 48–128 万/h（CST 15:00 峰值 128.3 万）；CST 20:00 出现 172.4 万/h 异常尖峰（前后小时 50.6 万 / 23.9 万）	形态异常	🟡 见下方尖峰定位

🟡 20:30 ylog 突发定位

CST 20:30–21:00 半小时 155.2 万条，其中 parsed_ylog 147.1 万（94.7%），来源高度集中：
主机：Windows Server 2016 d032019080022-v（192.168.8.180/114，即夜间触发 Dissector WARN 的同一台主机）
文件：D:\Youdu\Server\10.0.33-202609021431\svc_org\log\ng_org.ylog（svc_org 服务）
样本内容：log_level=error，log_msg="failed to cleanup expired events"，log_caller=biz/biz_startup.go:281——业务 error 刷屏（过期事件清理循环失败后高频重试打日志），并非解析失败/无效数据。
处置建议：排查 svc_org 的 biz_startup.go:281 清理逻辑为何在 20:30 左右进入失败循环（依赖的存储/pebble 状态异常？与该主机夜间 02:00 badger/pebble 栈输出或为同源问题）；日志侧可对该 msg 做限频采样。该主机已是第二次上榜（夜 WARN + 晚突发），建议一并体检。

无效/解析失败类 tag 合计 ≈ 17,579（占 0.145%），绝对量与占比均平稳。

三、B. system-log 明细（完整 CST 24h，双索引求和）

指标	数值	环比	判定
总文档数	11,866,081（11.03 索引 CST 折算 + 11.04 索引）	+13.0%	⚠️ 高于 1050 万基线、逼近 1200 万黄线（dockerd debug 未关为主因）
事件转储回显（`"@version" => "1"` 精确签名）	命中 1,417，其中真实回显 1,086，误报 331（见下）	真实回显 1,086 vs 前值 961（+13.0%，连续第八晚复发且加速）	🔴 红色告警，定位见下
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,306	-1.4%（前值 38,868）	✅ 平稳（99% 来自 LAN_addcn_117，38,011 条）
无效碎片总量（regexp `[0-9]+\.` / "[0]" / "from /"）	1,692,038	+6.9%（前值 1,582,516）	⚠️ 观察项（仍以已知 dockerd/kubelet/haproxy 噪音为主）
按小时分布	CST 全天 43.7–58.5 万/h（CST 09:00 峰值 58.5 万），曲线平滑	平滑	✅ 无尖峰

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

来源	数量	时间分布	性质判定
LAN_addcn_35 / logstash[1214328]	1,086	CST 11-04 02:00（402）/ 03:00（341）/ 04:00（341）/ 05:00（1），另白天 09:00–21:00 零星 46 条	真实回显：抽样确认为 Dissector WARN「pattern not found」事件转储（youdu_next_log pipeline 对 Windows 主机 `d032019080022-v` 的 `ng_kv_err.log` 输出 pebble WAL 行 `...pebble\\_data\\__pebble_meta__\\004642.log ... replayed 0 keys...` 不匹配 infra dissect 模板 `%{infra_comp} %{log_time} %{log_src}: [%{log_level}] %{log_msg}`，WARN 日志把含 `"@version" => "1"` 的事件体打进 /var/log/messages 被 filebeat 重采）。连续第八晚 02:00–04:00 准时复发，量级 931→961→1,086（+13%，加速上行）。并非 stdout rubydebug 回归。
LAN_addcn_45 / dockerd	331	CST 白天多时段零星	分词误报，非回显：抽样确认为 dockerd build debug 行 `.../v1.41/build?...&version=1` URL 参数，标准分词后 [version, 1] 相邻，与事件转储签名同形。属 dockerd debug 噪音（已知待办），不计入回显告警。

处置建议（沿用并升级紧迫度）：该回显已连续 8 晚复发且增速加快（+3%→+13%），且同主机晚间又出现 147 万条 error 突发——建议尽快：① 对 LAN_addcn_35 的 youdu_next_log pipeline Dissector WARN 降噪（log4j2 logger org.logstash.dissect.Dissector 级别调至 ERROR 或 pipeline log.level 调整）；② 体检 Windows 主机 d032019080022-v（pebble/svc_org 存储状态 + 02:00 / 20:30 两个定时行为）。dockerd debug 关闭（LAN_addcn_45/22）仍在待办，关闭后 system-log 预计回落至 ~800–950 万。

无效碎片 Top5 来源

机器	总量	主要进程	备注
LAN_addcn_45	492,305	dockerd 482,814、kubelet 5,195、journal 2,832	已知待办（dockerd debug 未关），标注不告警
LAN_addcn_82	355,336	haproxy[124397] 282,191、rpc.mountd[96046] 34,389、filebeat 9,881	⚠️ 持续观察项（333.8k→349k→355k，连续三日上行）
LAN_addcn_22	234,605	kubelet[257775] 224,245、gitlab-runner 2,599	已知（kubelet 噪音带）
LAN_addcn_117	（本轮 Top5 未入碎片榜，但 grok 失败 38,011 集中于此）	pmm-agent 类	✅ 平稳
其余	分散	—	无新增异常来源

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

每节点水位（_cat/allocation）

节点	disk.percent	disk.used	disk.avail	分片数	判定
elasticsearch-master-0	77%（最高）	75.5 GB	22.3 GB	110	🟡 触 75% 黄线（前值 73%，+4pp，三连升 71→73→77）
elasticsearch-master-1	62%	60.9 GB	36.9 GB	110	✅（前值 65%，回落）
elasticsearch-master-2	55%	53.9 GB	43.9 GB	110	✅（前值 49%）

集群 health：green（unassigned_shards=0），无非 STARTED 分片。
索引总量 183.1 GiB，较 11-03 的 178.7 GiB +4.4 GiB；多数家族索引数收敛至 7 个（约 7 天保留）。youdu_next_log 仅 2 索引（8.2 GiB，1,529 万条）。

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

家族	存储	占比	索引数	文档数
system-log	36.7 GiB	20.1%	7	6,474 万
logstash-nginx_access	32.4 GiB	17.7%	7	3,702 万
k8s-audit	27.1 GiB	14.8%	7	1,069 万
win_smb_log	26.2 GiB	14.3%	7	1,807 万
mysql_audit	12.9 GiB	7.1%	7	1,819 万
tw8591-cloudwatch	12.7 GiB	6.9%	7	511 万
tw591-cloudwatch	11.0 GiB	6.0%	7	522 万
youdu_next_log	8.2 GiB	4.5%	2	1,529 万
.monitoring-es-7	7.4 GiB	4.0%	7	764 万
logstash-traefik_access	4.8 GiB	2.6%	7	630 万
k8s-log	1.7 GiB	0.9%	7	284 万
mysql_error	1.0 GiB	0.6%	7	497 万
k8s-event-log	0.4 GiB	0.2%	7	26 万
system_secure	0.3 GiB	0.2%	7	38 万
elastalert_status_status	0.1 GiB	0.1%	1	63 万

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

master-0 已触 77%（黄线 75%），若维持 +2~4pp/天斜率，2–4 天内可能逼近 85% 红线，建议尽快安排清理。
以 Top 家族日均（总占用/索引数，含副本）估算：
system-log ≈5.2 GiB/天：删最旧 2 天可释放约 10.5 GB，master-0 水位预计 77%→~74%（退出黄线）；
logstash-nginx_access ≈4.6 GiB/天：删最旧 2 天可释放约 9 GB，叠加后水位预计降至 ~71%；
win_smb_log（3.7 GiB/天）与 k8s-audit（3.9 GiB/天）各删最旧 2 天再释放约 15 GB，四项合计约 34.5 GB，水位预计 77%→~65%。
建议：优先为 win_smb_log、k8s-audit 配 ILM 统一保留策略（人工删旧天索引 + ILM 均可）；不建议手工单删未评估的索引。日报只做水位跟踪，不执行删除。

五、告警汇总

🔴 红色告警

事件转储回显（真实）1,086 条（system-log：LAN_addcn_35 / logstash[1214328]，连续第八晚 CST 02:00–04:00 定时复发，931→961→1,086，本日 +13% 加速上行）——根因为 Dissector WARN 事件转储 + Windows 主机 d032019080022-v 夜间 pebble WAL 输出任务。签名另命中 dockerd 331 条，抽样确认为 build URL version=1 分词误报，不计入。

🟡 黄色预警

master-0 磁盘水位 77%（触 75% 黄线；71→73→77 三连升）：建议按第四节清理方案处置（删 system-log + nginx_access 最旧 2 天约释放 19.5 GB，可退回 ~71%）。
youdu 日总量 12,111,153 超 1200 万黄线（16h 口径）：由 CST 20:30 svc_org「failed to cleanup expired events」error 突发 147 万条驱动，剔除后 ~1,064 万属常态；需业务侧排查该主机清理循环，若复发将持续触线。
⚠️ 观察项（未触线）：system-log 总量 11,866,081（+13%，逼近 1200 万，dockerd debug 未关为主因）；LAN_addcn_82 haproxy 碎片连续三日上行。

✅ 正常项

hook 刷屏 0；clickhouse-server 0；syslog_hostname 字面量 0；Invalid FieldReference 0；mapper_parsing_exception（infra_day/apiVersion）0；ylog_parsefail / caddy_parsefail / _grokparsefailure（youdu）均 0；治理基线（2026-08-20 / 09-22 各项）零回归；集群 green。

六、总结

2026-11-04 整体需处置：治理基线零回归（hook、FieldReference、hostname 字面量、mapper 400、clickhouse 均为 0），集群 green，但两项问题升温。其一，LAN_addcn_35 事件转储回显连续第八晚复发且加速（1,086 条，+13%），同源 Windows 主机 d032019080022-v 又在 20:30 打出 147 万条 svc_org「failed to cleanup expired events」error 突发，把 youdu 日总量顶破 1200 万黄线，建议尽快对该 pipeline 的 Dissector WARN 降噪并体检该主机。其二，master-0 磁盘 77% 触黄线（三连升），按第四节估算删 Top 家族最旧 2 天可释放约 19.5–34.5 GB、退回 71–65%。system-log 总量 +13% 逼近黄线，主因仍是待办的 dockerd debug；LAN_addcn_82 haproxy 碎片连续三日上行，继续观察。