王绍宏
1c07acc01d
一、增加现场原始日志采集功能
1. 新增按设备采集原始日志的API：
- 指定设备ID；
- 采集时长最长10分钟；
- 单次最多返回50条样本。
2. 样本选择策略：
- 优先保留时间窗口内最早到达的N条日志；
- 后续出现JSON解析异常、非标、规则执行异常、InfluxDB/达梦写入异常或Retry/DLT时，
使用异常日志逐条替换最早的正常样本；
- 异常样本同样遵循先到先得。
3. 支持三个syslog-consumer-rule实例联合采集：
- 采集请求只需发送到任意一个实例；
- 三个实例通过公共Redis同步采集任务并汇总候选样本；
- 不需要配置其他实例IP；
- Redis只保存有界候选集，不保存时间窗口内的全部日志。
4. 生命周期和资源控制：
- 采集到期后自动停止接收新日志；
- 默认进入30秒DRAINING阶段，等待异步处理异常完成样本替换；
- 最终结果默认保留30分钟，之后自动删除；
- 单实例、单会话最多保留“前N条+前N条异常”；
- Redis故障不阻断Kafka主消费链路。
5. 返回规则解析和非标表截断之前的完整原始报文，不受
HB_XDR_TRUNCATED字段截断影响。
6. 原始日志采集和多实例汇聚默认启用：
SYSLOG_RAW_CAPTURE_ENABLED=true
SYSLOG_RAW_CAPTURE_CLUSTER_ENABLED=true
二、修复天眼/微步JSON规则匹配问题
1. JSON规则配置了cropper时，先判断原始报文是否包含对应head_key；
不匹配的规则不再将当前报文误判为非法JSON。
2. 同一设备绑定多条规则时，单条不适用或解析失败的JSON规则不再立即终止整个规则链，
程序会继续匹配后续适用规则。
3. 只有全部适用JSON规则均解析失败、且没有其他规则成功处理时，才写入
“JSON解析异常”非标记录。
4. 对cropper截取后仍包含Syslog或设备前缀的内容，在JSON专用路径中重新收敛到
第一个“{”至最后一个“}”，确保交给Jackson的是完整外层JSON。
5. 修复以下现场场景：
- 天眼规则129截取结果仍带有alarm前缀；
- 微步设备同时绑定固定偏移规则和Threatbook/TDP JSON规则；
- 不适用的固定偏移规则抢先产生JSON解析异常；
- Syslog头加JSON正文不能继续匹配后续适用规则。
三、增加现场采集工具及运维说明
新增upgrade-doc/v5：
- README.md：升级、配置、生命周期和故障排查说明；
- capture-device-raw-logs.sh：一键创建采集会话、等待完成并自动落盘。
脚本输出：
- result.json：完整采集结果；
- samples.jsonl：每行一条样本及处理状态；
- raw/*.log：每条未截断原始报文；
- summary.txt：采集数量、异常数量和替换数量；
- latest.json：中断或超时时的最后有效快照。
四、兼容性与升级范围
- 兼容JDK 8；
- 无需新增或修改达梦数据库表；
- 无需创建新的Kafka Topic；
- 需要滚动升级全部syslog-consumer-rule实例；
- 三个实例必须连接相同的Redis；
- 本次提交不包含syslog-serve的高内存、WAL或JVM参数调整。
180 lines
6.5 KiB
Markdown
180 lines
6.5 KiB
Markdown
# v3 新增变量配置
|
||
|
||
应用侧只需要修改两个 Docker Compose 文件。变量放到对应服务的 `environment:` 下，不要修改 JAR 中的
|
||
`application.properties`；Kafka Broker 参数单独按第 4 节核对。
|
||
|
||
## 1. syslog-serve
|
||
|
||
配置文件：
|
||
|
||
```text
|
||
syslog-serve/docker-compose/docker-compose-serve-prod.yaml
|
||
```
|
||
|
||
在 `services.syslog-serve.environment` 中增加：
|
||
|
||
```yaml
|
||
# 开启 Syslog TCP/UDP 监听，字符集按现场设备实际编码调整。
|
||
- SYSLOG_SERVER_ENABLED=true
|
||
- SYSLOG_CHARSET=UTF-8
|
||
|
||
# 单条最多接收 6 MiB，达到 128 KiB 时发送到大日志 Topic。
|
||
- SYSLOG_MAX_FRAME_LENGTH=6291456
|
||
- SYSLOG_MESSAGE_MAX_BYTES=6291456
|
||
- SYSLOG_LARGE_MESSAGE_THRESHOLD_BYTES=131072
|
||
|
||
# 200KiB/条容量基线；WAL 高水位约在 14,000 条、2.7~2.8GiB 对齐触发。
|
||
- SYSLOG_WAL_QUEUE_CAPACITY=20000
|
||
- SYSLOG_WAL_MAX_PENDING_BYTES=4294967296
|
||
- SYSLOG_WAL_HIGH_WATERMARK_PERCENT=70
|
||
- SYSLOG_WAL_LOW_WATERMARK_PERCENT=40
|
||
- SYSLOG_WAL_FLUSH_RECORDS=200
|
||
- SYSLOG_WAL_FLUSH_INTERVAL_MS=100
|
||
- SYSLOG_WAL_SEGMENT_MAX_BYTES=4294967296
|
||
|
||
# Kafka 投递限制正文最多 1GiB 在途，并增加加密后的 Producer 缓冲。
|
||
- SYSLOG_DISPATCH_WORKER_THREADS=8
|
||
- SYSLOG_DISPATCH_MAX_INFLIGHT=5000
|
||
- SYSLOG_DISPATCH_MAX_INFLIGHT_BYTES=1073741824
|
||
- SPRING_KAFKA_PRODUCER_PROPERTIES_BUFFER_MEMORY=536870912
|
||
|
||
# Dockerfile 不展开 JAVA_OPTS，使用 JVM 自动读取的 JAVA_TOOL_OPTIONS。
|
||
- JAVA_TOOL_OPTIONS=-Xms8g -Xmx24g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:MaxDirectMemorySize=8g -XX:+ExitOnOutOfMemoryError
|
||
|
||
# 大日志 Kafka Topic 及 Producer 请求上限。
|
||
- KAFKA_PRODUCER_LARGE_TOPIC=agent-01-syslog-topic.large
|
||
- KAFKA_PRODUCER_MAX_REQUEST_SIZE=33554432
|
||
```
|
||
|
||
其中：
|
||
|
||
- `SYSLOG_MAX_FRAME_LENGTH`：TCP 单帧最大长度；
|
||
- `SYSLOG_MESSAGE_MAX_BYTES`：所有来源的单条日志硬上限，超过后拒绝；
|
||
- `SYSLOG_LARGE_MESSAGE_THRESHOLD_BYTES`：达到该值后走大日志 Topic；
|
||
- `SYSLOG_WAL_QUEUE_CAPACITY`、`SYSLOG_WAL_MAX_PENDING_BYTES`：共同限制 WAL 接入条数和原文字节量；
|
||
- `SYSLOG_DISPATCH_MAX_INFLIGHT_BYTES`：限制 Kafka Dispatcher 在途正文总量；
|
||
- `JAVA_TOOL_OPTIONS`：设置实际 JVM 堆和直接内存上限，不能替换成当前 Dockerfile 不会展开的 `JAVA_OPTS`。
|
||
|
||
`SYSLOG_MAX_FRAME_LENGTH` 必须大于或等于 `SYSLOG_MESSAGE_MAX_BYTES`。如果设备发送 GBK，应将
|
||
`SYSLOG_CHARSET` 改为 `GBK`。
|
||
|
||
## 2. syslog-consumer-rule
|
||
|
||
配置文件：
|
||
|
||
```text
|
||
syslog-consumer-rule/docker-compose/docker-compose-consumer-rule-prod.yaml
|
||
```
|
||
|
||
在 `services.syslog-consumer-rule.environment` 中增加；如果以后部署多实例，各实例保持一致：
|
||
|
||
```yaml
|
||
# 大日志独立消费通道。
|
||
- KAFKA_CONSUMER_LARGE_TOPIC=agent-01-syslog-topic.large
|
||
- SYSLOG_LARGE_LISTENER_ENABLED=true
|
||
- SYSLOG_LARGE_LISTENER_CONCURRENCY=1
|
||
- SYSLOG_LARGE_LISTENER_MAX_POLL_RECORDS=5
|
||
- SYSLOG_LARGE_LISTENER_MAX_PARTITION_FETCH_BYTES=33554432
|
||
- SYSLOG_LARGE_LISTENER_FETCH_MAX_BYTES=67108864
|
||
|
||
# 大日志规则处理批次和独立线程池。
|
||
- SYSLOG_LARGE_PROCESSING_BATCH_MAX_BYTES=8388608
|
||
- SYSLOG_LARGE_PROCESSOR_CORE_POOL_SIZE=1
|
||
- SYSLOG_LARGE_PROCESSOR_MAX_POOL_SIZE=2
|
||
- SYSLOG_LARGE_PROCESSOR_QUEUE_CAPACITY=10
|
||
|
||
# Retry、DLT、Replay 也允许传输大日志。
|
||
- KAFKA_RELIABILITY_MAX_REQUEST_SIZE=33554432
|
||
|
||
# 连续性优先：特殊异常即使无法写入 DLT，也记录告警并继续消费。
|
||
- SYSLOG_FAILURE_CONTINUITY_ENABLED=true
|
||
- SYSLOG_FAILURE_CONTINUITY_DLT_PUBLISH_TIMEOUT_MS=1000
|
||
|
||
# InfluxDB 原文最多保存 256 KiB，单批写入最多 8 MiB。
|
||
- INFLUXDB_RAW_MESSAGE_MAX_UTF8_BYTES=262144
|
||
- INFLUXDB_RAW_WRITE_BATCH_MAX_BYTES=8388608
|
||
|
||
# 达梦正常日志大字段和非标日志原文最多保存 256 KiB。
|
||
- DM_NORMAL_LARGE_FIELD_MAX_UTF8_BYTES=262144
|
||
- DM_NON_NORMAL_LARGE_FIELD_MAX_UTF8_BYTES=262144
|
||
```
|
||
|
||
被截断的数据会以以下标记结尾：
|
||
|
||
```text
|
||
...[HB_XDR_TRUNCATED original_utf8_bytes=原始字节数]
|
||
```
|
||
|
||
以下三个存储上限配置为 `0` 时表示不截断：
|
||
|
||
```text
|
||
INFLUXDB_RAW_MESSAGE_MAX_UTF8_BYTES
|
||
DM_NORMAL_LARGE_FIELD_MAX_UTF8_BYTES
|
||
DM_NON_NORMAL_LARGE_FIELD_MAX_UTF8_BYTES
|
||
```
|
||
|
||
规则解析始终使用完整原文，只在写入 InfluxDB 或达梦时截断。
|
||
|
||
`SYSLOG_FAILURE_CONTINUITY_ENABLED=true` 时：
|
||
|
||
- InfluxDB 原文写入失败，会先尝试把原消息写入普通/大日志 DLT，再继续规则解析和达梦写入；
|
||
- 其他无法完成的特殊异常，会先尝试写 DLT，然后提交原 Kafka offset，避免阻塞整个分区；
|
||
- 如果 DLT 也不可用，仍会输出 `[SYSLOG_CONTINUITY_LOSS]` 日志并提交 offset。此时消息可能无法重放，
|
||
但不会阻塞后续新消息。
|
||
|
||
DLT 首次写入失败最多等待 `SYSLOG_FAILURE_CONTINUITY_DLT_PUBLISH_TIMEOUT_MS` 毫秒；随后不再逐条等待，
|
||
整批记录一次后立即放行。
|
||
|
||
设置为 `false` 可恢复原来的失败保留 offset 行为。
|
||
|
||
## 3. 日统计投影
|
||
|
||
日统计投影默认开启，一般不需要新增配置。只需确认现场没有配置：
|
||
|
||
```text
|
||
STATS_PROJECTION_ASYNC_ENABLED=false
|
||
```
|
||
|
||
如果现场需要显式写明，可以在 `syslog-consumer-rule` 的 `environment` 中配置：
|
||
|
||
```yaml
|
||
- STATS_PROJECTION_ASYNC_ENABLED=true
|
||
- STATS_PROJECTION_TOPIC=agent-01-syslog-topic.STATS.PROJECTION
|
||
- STATS_PROJECTION_GROUP_ID=agent-01-syslog-group-dm-stats-projection
|
||
```
|
||
|
||
## 4. Kafka 配置
|
||
|
||
每个 Kafka Broker 的 `replica.fetch.max.bytes` 必须不小于 32 MiB：
|
||
|
||
```properties
|
||
replica.fetch.max.bytes=33554432
|
||
```
|
||
|
||
然后执行：
|
||
|
||
```bash
|
||
bash upgrade-doc/v3/kafka/02-create-large-log-topics.sh
|
||
```
|
||
|
||
生产者和消费者的大日志 Topic 名称必须完全相同：
|
||
|
||
```text
|
||
KAFKA_PRODUCER_LARGE_TOPIC=agent-01-syslog-topic.large
|
||
KAFKA_CONSUMER_LARGE_TOPIC=agent-01-syslog-topic.large
|
||
```
|
||
|
||
## 5. 使配置生效
|
||
|
||
在现场对应的部署目录先检查 Compose，再重建容器：
|
||
|
||
```bash
|
||
docker compose -f docker-compose-serve-prod.yaml config
|
||
docker compose -f docker-compose-serve-prod.yaml up -d --force-recreate syslog-serve
|
||
|
||
docker compose -f docker-compose-consumer-rule-prod.yaml config
|
||
docker compose -f docker-compose-consumer-rule-prod.yaml up -d --force-recreate syslog-consumer-rule
|
||
```
|
||
|
||
建议先升级 `syslog-consumer-rule`，确认大日志消费者正常后，再升级 `syslog-serve`。
|