【告警中心】优化关联日志条件构造不准确的问题
0x01 背景
a. Why
日志告警进入新版告警详情关联日志面板时，后端返回的过滤语义被拆成 keyword 和 addition 两种载体。
前端根据 keyword 是否存在选择检索模式：
- 非空且不为
*时进入 Lucene 语句模式。 - Lucene 语句模式只向日志检索接口提交
keyword。
当前 build_log_search_condition 会把告警维度和策略过滤条件构造成 addition，并把策略 query_string 原样返回为 keyword。
当策略同时配置 query_string 和 agg_condition 时，关联日志实际只按 query_string 查询，范围会大于触发告警时的策略范围。
这会让告警详情混入不满足策略过滤条件的日志，降低关联日志对问题定位的准确性。
b. 目标
- 关联日志默认查询范围与日志告警策略触发范围一致。
- 无有效
query_string的策略继续使用 UI 过滤模式。 - 日志聚类告警继续使用现有
addition过滤，不破坏聚类签名和敏感度过滤。
0x02 实现路线
a. 建议的方案
以 bkmonitor.utils.alert_drilling.build_log_search_condition 作为过滤语义收敛入口。
调用方明确要求进入语句模式时，把策略 query_string 与可表达的过滤条件合并为一个 Lucene keyword。
合并逻辑复用 bkmonitor.utils.elasticsearch.handler.QueryStringGenerator 生成过滤片段，但需要补齐操作符映射和聚类豁免：
keyword为空或*时不合并，保留 UI 模式。- 存在有效
keyword且addition非空时，输出(<原 keyword>) AND (<过滤条件 query_string>)。 - 合并成功后清空
addition，避免前端继续保留互斥模式下的过滤条件。 DefaultTarget.list_related_log_targets抽象is_clustering = bool(clustering_type and clustering_index_set_id)。- 聚类场景不启用
keyword合并，并继续把keyword置空，让前端保持 UI 过滤模式。
b. 约束
- 不改前端检索模式选择逻辑，本期由后端保证
keyword语义完整。 - 以当前构造出的
addition作为合并来源，命中映射的条件才转入keyword。 - 保留
addition返回字段，但合并成功时返回空列表。 - 首页跳转等非详情面板调用方是否启用合并，需要按实际日志平台参数语义单独验证。