如何在Kibana中获取近7天新增错误日志及部署后新代码错误

一、基线对比法 #

• 先建立部署前的错误基线：提取部署前N天（比如7天）的所有唯一错误类型，存储成基准集合（比如用日志系统的索引或本地字典）。
• 部署后，实时抓取日志中的错误，将每个错误类型与基线集合对比，不在基线里的标记为疑似新错误。
• 示例：部署前基线没有“XYZ field not found”，部署后出现就直接标记。

二、时间窗口过滤+去重 #

• 设定部署时间点为分割线，只抓取部署后到当前的日志数据。
• 对这段时间内的错误做去重处理（比如按错误消息模板、错误码、堆栈摘要分组），得到唯一错误列表。
• 可以用日志查询语句实现，比如：

  # 假设用ELK查询，过滤部署后日志，按错误消息聚合
  GET /logs/_search
  {
    "query": {
      "range": {
        "@timestamp": { "gte": "部署时间戳" }
      },
      "match": { "level": "ERROR" }
    },
    "aggs": {
      "unique_errors": {
        "terms": { "field": "message.keyword", "size": 100 }
      }
    }
  }
  

三、错误上下文关联代码变更 #

• 把错误的堆栈信息、涉及的模块，和本次部署的代码变更文件做关联。
• 比如错误里提到的UserService类，刚好是本次部署修改过的，就标记为高优先级新错误。
• 可以结合CI/CD工具的变更记录，自动匹配错误涉及的代码路径。

四、动态阈值告警 #

• 针对每个错误类型设置出现次数阈值，部署后如果某个错误的出现次数从0突然飙升到超过阈值，直接触发告警并标记为新错误。
• 比如之前从未出现过“XYZ field not found”，部署后10分钟内出现5次，就认定是新增错误。

五、人工抽样验证 #

• 对自动识别出的疑似新错误，安排运维或开发做快速抽样验证，排除日志格式变化、第三方服务波动等非代码变更导致的错误。

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