态势感知安全日志

设置问题

根据你描述的情况，核心问题出在日志解析与关联分析环节。平台在30号后未能从原始数据中生成安全日志和事件，平台的日志处理流水线可能在某处中断了。

 一、常见诱因与定位步骤

日志处理是个有序流程，任何前置问题都会导致最终结果消失。请按以下顺序排查。

• 步骤1：立刻核对系统时间

  • 排查点：你说问题出现在“30号以后”，首先应检查平台系统时间是否因故障跳变。

  • 操作：SSH登录后台，执行date命令，确认时间无误。

• 步骤2：检查日志解析

  • 排查点：这是该版本最常见的原因。页面显示有“被动采集”，代表原始日志进入了平台。此时需要排查日志是否被正确解析。

  • 现象：威胁日志中存在乱码，或日志类别被错误识别。

  • 操作：在“威胁日志”中仔细查看30号之后的条目内容是否正常。如果发现乱码，需检查对应日志源的字符集配置，通常是未设为 GBK 导致。

• 步骤3：检查磁盘与存储

  • 排查点：磁盘满会触发平台保护机制，停止写入新数据。CSAP系列默认在磁盘使用率达到 96% 时，可能会停止接收日志。

  • 操作：前往“系统设置” -> “存储管理”查看磁盘使用率。如磁盘已满，需手动清理或扩容，也可在“自动清理”中配置阈值。

• 步骤4：验证后端服务

  • 排查点：关键后台服务僵死或异常。

  • 操作：重启采集器及相关服务。注意，重启前请务必在业务低峰期操作，并提前备份配置。

• 步骤5：查看策略与告警

  • 排查点：关联规则因配置变动、授权到期或匹配条件变化而失效，导致有安全日志但无安全事件。

  • 操作：检查是否有被禁用的策略，或策略配置是否完整。同时，查看平台是否有磁盘、服务异常、License等相关的系统告警。

 二、快速验证环境

通过几个动作，可以帮你快速确认平台状态，缩小问题范围：

1. 主动采集验证：新添加一个日志源（或用测试设备发日志），看平台能否立即生成安全日志。

2. 查看服务状态：用SSH登录后台，检查关键服务是否运行正常。

3. 咨询400支持：鉴于该版本可能存在Bug，建议直接拨打 H3C 400热线（400-810-0504），提供明确的“版本号、问题时间点、磁盘使用率”等信息，可加快处理速度。

 三、总结

整个排查流程需要遵循“数据先行、配置随后、服务兜底”的逻辑。建议先从磁盘空间和日志乱码这两个最常见的问题入手，并根据排查结果分情况处理：

• 若磁盘满：立即清理或扩容。

• 若日志乱码：修正日志源的字符集。

• 若磁盘空间充裕且日志解析正常：重启后端分析服务。

一、先确认 3 个核心现象（你已部分确认）
采集器：在线、心跳正常、被动采集数有增长、时间最新 → 采集器通道通。
日志源：设备侧 syslog/forward 正常发送，无断流、无端口过滤 → 源端输出正常。
平台侧：能看到采集量但无安全日志 / 事件 = 数据进入采集器后，入库、解析、标准化、关联 / 告警环节卡住。
重点时间点：30 号后突然清零 → 大概率是 30 号前后的变更 / 磁盘满 / 索引损坏 / 服务挂掉 / 规则库过期。
二、第一层：系统资源与磁盘（最常见，优先查）
1. 磁盘使用率（90%+ 必丢日志 / 不入库）
Web：系统 → 系统维护 → 磁盘管理 → 看 /data、/es、/mongo 使用率。
后台（SSH）：
bash
运行
df -h
关键：/es 或 /data 满 → 日志无法写入索引，只计数不存。
处理：清理旧日志 / 扩容，或调整 “日志存储策略”（默认 30 天覆盖，你刚好 30 号出问题，高度吻合）。
2. 系统时间（30 号后时间跳变 / 时区错 → 日志时间戳异常，不显示）
Web：系统 → 系统设置 → 时间设置，确认时区 Asia/Shanghai、时间正确。
后台：
bash
运行
date
timedatectl
三、第二层：日志接收 / 存储服务状态（E1149P06 重点）
1. 采集器进程（SIP‑Logger）
Web：日志采集 → 采集器管理 → 看在线、版本、心跳；重启异常采集器。
后台：
bash
运行
ps aux | grep logger
systemctl status sip-logger
2. ES（搜索引擎，存原始日志）
状态：
bash
运行
systemctl status elasticsearch
curl localhost:9200
异常：30 号后 ES 挂掉 / 索引损坏 → 只计数不入库。
修复（谨慎）：
bash
运行
# 重启ES
systemctl restart elasticsearch
# 查看索引
curl localhost:9200/_cat/indices?v
3. MongoDB（存事件 / 告警）
状态（正常为 primary）：
bash
运行
mongod.sh mongo ts
异常：状态为 other → 事件库不可写，无安全事件。
修复：执行对应版本的 mongo 恢复脚本（需深信服 L2 支持）。
4. 标准化 / 解析服务（Logstash）
状态：
bash
运行
systemctl status logstash
日志：
bash
运行
tail -f /var/log/logstash/*.log
关键报错：字段映射失败、模板不存在、解析异常 → 日志被丢弃，不生成安全日志。
四、第三层：规则库与策略（30 号是否自动更新 / 变更）
规则库版本：系统 → 系统维护 → 规则库管理 → 看30 号是否自动升级失败 / 回退。
安全策略：
日志采集策略：是否启用、是否关联正确日志源、过滤规则是否误删所有日志。
安全事件策略：是否启用、告警阈值是否被设为 “无”、事件分类是否被清空。
测试：新建一条极简规则（如匹配任意 syslog），看是否生成事件。
五、第四层：抓包验证（确认数据真的到平台）
在态势感知后台抓采集器接收端口（默认 UDP 514、TCP 5044）：
bash
运行
# 抓514端口
tcpdump -i any host 采集器IP and port 514 -w test.pcap
# 抓5044端口
tcpdump -i any host 采集器IP and port 5044 -w test.pcap
有包：数据到平台，问题在解析 / 入库 / 告警。
无包：采集器与平台间网络 / 端口过滤（防火墙 / 安全组）。
六、30 号后突然无日志的高频根因（你的场景命中率极高）
磁盘满（/es 或 /data 100%） → 日志只计数不入库，刚好 30 天覆盖阈值。
ES 索引损坏 / 分片丢失 → 原始日志无法存储，页面无数据。
MongoDB 状态异常（other） → 安全事件库不可写，无事件生成。
30 号规则库自动更新失败 → 解析 / 关联规则失效，日志被丢弃。
系统时间跳变 / 时区错误 → 日志时间戳异常，页面不展示。
七、建议操作顺序（1 小时内定位）
先查 磁盘使用率（90%+ 直接清理 / 扩容）。
再查 ES、Mongo、Logstash 服务状态。
看 30 号前后规则库 / 策略变更记录。
后台 抓包确认数据到达。