如何实现Elasticsearch近实时查询统计分析与Kibana看板搭建

你不用手写规则解析Elasticsearch原始日志，这套方案新手2小时内就能搭完，完全覆盖你列出的所有需求，运维成本极低。
优先选零业务侵入的官方组件采集方案，不用改业务代码，直接避开日志解析复杂度高的坑：通过调整ES慢日志阈值全量记录查询请求，搭配Filebeat官方ES模块做结构化解析，输出到独立统计索引后再做Kibana可视化即可。如果你的业务迭代自由度高，也可以选客户端拦截器方案，数据精准度更高。
两种方案适用场景：

• 方案A（零代码，新手首选）：ES慢日志+Filebeat官方模块，适合不想改业务代码、快速上线的场景，日志解析规则由官方维护，不用自己写Grok正则踩坑。
• 方案B（高精准）：业务侧ES客户端统一拦截上报，适合对数据字段灵活度要求高、不想额外占用ES日志存储开销的场景，直接在查询执行完成后把需要的字段写入统计索引，完全没有解析成本。

第一步：配置ES全量记录搜索请求 #

直接通过动态参数调整目标业务索引的慢日志阈值，不需要重启节点，对线上业务无影响，将阈值设为0即可记录所有搜索请求：

PUT /你的业务索引名/_settings
{
  "index.search.slowlog.threshold.query.info": "0s",
  "index.search.slowlog.threshold.fetch.info": "0s",
  "index.search.slowlog.level": "info"
}

注意：生产环境如果单节点查询QPS超过1万，不建议长期全量采集所有查询，可以在Filebeat端配置10%-30%的采样率，统计误差完全在可接受范围内，能大幅降低存储和性能开销。

第二步：配置结构化解析与入库规则 #

直接开启Filebeat自带的Elasticsearch模块，模块已经预定义了所有版本ES慢日志的解析规则，会自动把原始日志拆成查询耗时、命中数、完整查询DSL、索引名等结构化字段，不用自己写解析规则。
额外加一个轻量的ES Ingest Pipeline，在数据入库时自动派生你需要的统计字段，避免后续查询时重复计算：

PUT _ingest/pipeline/search_log_pipeline
{
  "processors": [
    {
      "script": {
        "source": """
          // 提取查询命中的总文档数
          ctx.total_hits = ctx.slowlog?.hits?.total?.value != null ? ctx.slowlog.hits.total.value : 0;
          // 标记是否为无结果查询
          ctx.is_zero_hits = ctx.total_hits == 0;
          // 提取常见查询中的搜索词，可根据自己的业务查询结构扩展规则
          if (ctx.slowlog?.query?.match != null) {
            def firstMatchField = ctx.slowlog.query.match.keySet().iterator().next();
            ctx.search_term = ctx.slowlog.query.match[firstMatchField].query.toString();
          }
          if (ctx.slowlog?.query?.query_string != null) {
            ctx.search_term = ctx.slowlog.query.query_string.query.toString();
          }
        """
      }
    }
  ]
}

第三步：提前创建统计索引的Mapping #

不要用动态生成的Mapping，提前给独立统计索引（比如命名为search_query_logs）指定字段类型，避免聚合不准、查询慢的问题：

PUT /search_query_logs
{
  "mappings": {
    "properties": {
      "@timestamp": {"type": "date"},
      "search_term": {"type": "keyword", "ignore_above": 256},
      "total_hits": {"type": "integer"},
      "is_zero_hits": {"type": "boolean"},
      "query_dsl": {"type": "text", "index": false},
      "queried_index": {"type": "keyword"},
      "cost_ms": {"type": "integer"}
    }
  }
}

配置Filebeat的ES模块输出到这个索引，并且指定写入时走上面创建的search_log_pipeline即可。

所有需求都不需要写自定义代码，用Kibana自带的Lens、Data Table、Metric可视化就能实现：

• 统计用户查询总次数：用Metric可视化，对search_query_logs索引做文档计数，搭配时间筛选器即可查看任意时段的总查询量，还能拆分维度看不同索引的查询量。
• 统计无返回结果的查询次数：在Metric可视化中增加筛选条件is_zero_hits: true做计数，还可以额外计算无结果查询占总查询的比例。
• 全量记录搜索词日志：在Kibana Discover页面选择search_query_logs索引，即可查看全量查询日志，支持按时间、搜索词、是否命中结果等维度筛选检索。
• 按搜索词频次排序全量/无结果查询：用Terms聚合，按search_term字段分桶，按文档数降序排序即可得到频次排名；无结果查询的排名只需要在聚合前增加筛选条件is_zero_hits: true。
• Top高频查询视图：用Data Table或Lens表格组件，Terms聚合按search_term分桶，列配置为搜索词、出现次数、关联的完整query_dsl、平均耗时，默认按出现次数降序排列，取前20条就是高频查询视图。
• Top高频无结果查询视图：复用上面的高频查询视图配置，全局增加筛选条件is_zero_hits: true，即可得到高频未命中搜索词、对应完整查询语句的视图。

• 不要上来就自己写Grok正则解析ES原始日志，大概率会踩多行日志截断、不同ES版本日志格式变动、特殊字符解析失败的坑，官方模块已经把这些问题都处理好了。
• 给统计索引配置ILM生命周期策略，比如热节点存7天高频查询数据，温节点存3个月历史数据，到期自动删除，避免日志越积越多占满磁盘。
• 用户规模小、QPS低于5000的时候，全量采集查询日志完全不会影响ES性能，等后续流量涨上去再调整采样率即可，不用一开始就做复杂的性能优化。
• 不用追求100%提取所有复杂查询的搜索词，比如嵌套多层的bool聚合查询，直接保留完整查询DSL供排查即可，核心覆盖普通用户的文本搜索场景就能满足90%以上的分析需求。

内容的提问来源于stack exchange，提问作者R2D2