检索从收窄条件开始
日志平台的检索瓶颈通常不在查询语句写得好不好，而在条件给得太宽：一上来就查全量，既慢又容易把平台拖住。可行的顺序是固定的——先框时间范围，再限定设备或站点来源，然后叠加关键字段条件，最后抽样确认字段名与内容符合预期，再放大范围做统计或导出。设备侧的原始日志和平台解析后的字段往往不是一回事，抽样这一步能避免「查询为空」被误读成「没有日志」。
基本信息
| 检索顺序 | 时间范围 → 设备/来源 → 关键字段 → 抽样确认 → 统计导出 |
|---|---|
| 常用字段 | 源/目的 IP、目的端口、规则或策略 ID、动作、用户名、时间戳 |
| 时间选择 | 先给一个稍宽的时间窗确认数据存在，再逐步收窄到事件时刻 |
| 字段确认 | 取一条已知日志对照平台的字段名与大小写，再批量查询 |
| 导出限制 | 先聚合统计看趋势，确需明细再小范围导出，避免拖垮平台 |
典型使用场景
- 事件研判：某内网主机疑似失陷，按源地址与时间窗拉出全部会话与告警记录
- 用户投诉定位：某业务在特定时段不可访问，检索该时段策略命中与拒绝记录
- 规则验证：新策略或新发布的 NAT 上线后，确认是否有对应放行日志产生
- 误报排查：确认某条告警的原始日志内容与请求参数，判断是否为误报
- 取证与审计：按指定日期检索操作日志与登录日志，作为检查材料
- 容量与趋势分析：按源地址或目的端口聚合，找出流量与告警的主要来源
检索思路与示例
检索思路与示例
步骤一 定时间：2026-10-12 09:00 至 10:00 # 先宽后窄，确认有数据
步骤二 定来源：device = FW-CORE # 多台设备时先分清是哪台
步骤三 加字段：src_ip = 10.0.0.5 且 action = deny # 逐步叠加，避免一次叠加过多
步骤四 抽样看一条原始日志，核对字段名与解析结果 # 字段名以平台解析为准
步骤五 确认无误后改为聚合统计：按 dst_port 计数、按时间分桶
导出 仅导必要字段与必要时间范围，导出后登记用途与存放位置
参考原始行（归一化示例）：
Oct 13 10:00:01 FW-CORE session 10.0.0.5:52341 -> 203.0.113.9:443 action=allow policy=P-231常用字段读法
| 字段 | 含义 | 检索用途 |
|---|---|---|
| 时间戳 | 日志产生或入库的时间 | 框定事件窗口，注意设备与平台的时区差异 |
| 源/目的 IP | 会话两端的地址 | 定位内部主机与外部目标，缩小到单机维度 |
| 目的端口 | 服务端口号 | 判断访问的服务类型，识别异常端口外联 |
| 策略/规则 ID | 命中的策略或特征编号 | 关联配置，确认放行或拦截由哪条规则决定 |
| 动作 | 放行、阻断、仅记录等结果 | 区分「命中」与「生效」，避免误判 |
| 用户名 | 登录或认证主体 | 账号类事件复盘，如异常登录与权限变更 |
查询结果为空时先怀疑字段名、时间范围与时区，而不是直接下结论「没有日志」。设备与日志平台的时区不一致造成的偏差很常见，尤其是跨时区部署或设备改过时区配置之后。