Logstash 经 Cloudflare 写 OpenSearch，WAF 按内容拦下两批 _bulk，插件对同一批无限重发，背压传回 filebeat，qa 和 stg 的日志停了将近 29 小时。重启只能临时疏通，要在 Cloudflare 加跳过规则。

复制表的每次 INSERT 和 merge 都在 ZooKeeper 的 log/ 下用掉一个 int32 序号。lab 上把计数器推到上限之后，INSERT 全报 Node exists，merge 失败，读照常；照原表建新表、把分区挂过去就能恢复写入。

行数对得上、数字却不对，先查时间轴：UTC 16 点到 24 点之间的时刻，在 UTC 和上海两种列声明下会落进相邻两天的分区。再查 JOIN 有没有在右表重复键上放大，去重计数是不是近似的 uniq，上游有没有改字段名让整列变成默认值。

数据少了不报错，常常很久之后才被发现。排查从上游和 Kafka 开始，再看 connector 的错误处理：默认配置下一条坏记录让 task 停住；配了 DLQ，同批同分区的好记录跟着进 DLQ；只开容错不配 DLQ，整批静默消失。

生产环境单节点 OpenSearch 的 Dashboards 对所有用户返回 401：按 _id 排序分页留下的 12.3 GiB fielddata 占着没有上限的缓存，几个跨月聚合又把堆推过了 parent 断路器上限。文中整理了时间线、原因和防护建议。

开发环境单节点只存 47.5 GB 日志，OpenSearch 却平均占 0.88 核。大头是 ISM 每 5 分钟对 1,388 个索引加锁放锁，锁索引两天多才 flush，软删除攒到 185 万条；在线调参后预计降到 0.2～0.25 核。

ReplicatedMergeTree 默认记住最近 1000 个插入块，重投的那批内容和 token 都没变，本该被认出来。这张表三个副本每秒建 124 个块，1000 个块折合 8 秒，而重投的间隔是 32 到 124 秒。

同一个业务键在 ClickHouse 里出现两行完全一样的数据，写入时间相差 30 秒到两分钟。前一天吞吐掉到常态零头的十几个小时一行重复都没有，出重复的是第二天吞吐看着正常、Keeper 在途请求涨到几千的那三个小时。

两张明细表只共享半个唯一键，同层 JOIN 之后才聚合，分页接口那 40 秒慢查询就出在中间被 DISTINCT 压回去的那些行上；拆成三步后这组参数下结果逐行一致。

压测时副本数在 3 和 5 之间反复抖动，查到是 ArgoCD selfHeal 在和 HPA 抢 spec.replicas。记录这次排查的证据链、修复方式，以及引出的几个扩缩容问题。