4. Agent 核心功能：日志采集、元数据提取、策略匹配、阻断/放行决策
准入 Agent 是部署在终端或网络边界上的轻量级执行单元，其核心职责可抽象为一条闭环链路：采集 → 提取 → 匹配 → 决策。四个环节必须满足低延迟、高可靠、可审计三大要求，才能在不影响业务连续性的前提下，实现日志检索准入门禁的实时控制。
4.1 功能全景与模块划分
Agent 内部按功能域划分为四个独立模块，模块间通过内存管道或本地 IPC 通信，避免单点故障扩散。下表列出各模块的输入、输出与关键约束：
| 模块 | 输入 | 输出 | 关键约束 |
|---|---|---|---|
| 日志采集 | 文件、系统日志、网络流 | 结构化日志事件 | 采集延迟 ≤ 200ms；磁盘 I/O 隔离 |
| 元数据提取 | 结构化日志事件 | 增强元数据（用户、进程、地理位置等） | 提取耗时 ≤ 50ms；支持自定义字段 |
| 策略匹配 | 增强元数据 + 策略规则集 | 匹配结果（命中/未命中） | 规则数 ≤ 10,000 条；匹配延迟 ≤ 10ms |
| 阻断/放行决策 | 匹配结果 + 上下文状态 | 决策动作（ALLOW / BLOCK / CHALLENGE） | 决策幂等；支持回滚审计 |
设计要点：四个模块必须支持独立升级与降级。例如，当策略匹配模块因规则变更需要重启时，日志采集与元数据提取应继续运行，数据暂存于环形缓冲区，避免日志丢失。
4.2 日志采集：多源异构归一化
Agent 需要同时采集文件日志（如 Nginx access.log）、系统日志（如 syslog、Windows Event Log）以及网络流日志（如 NetFlow/IPFIX）。采集层采用 插件式输入 架构，每种数据源对应一个独立 Input Plugin。
- 文件采集：基于 inotify + 偏移量持久化，支持日志轮转（logrotate）场景下的断点续采。
- 系统日志：通过 Unix Domain Socket 或 Windows ETW 订阅实时事件，避免轮询开销。
- 网络流：监听 UDP 端口接收流数据，使用固定大小缓冲区防止丢包。
# 日志采集配置示例（YAML 风格）
input:
- type: file
path: /var/log/nginx/access.log
offset_file: /var/lib/agent/offsets/nginx.offset
multiline_flush_interval: 5s
- type: syslog
protocol: unix
path: /run/systemd/journal/syslog
facility: ["auth", "authpriv"]
- type: netflow
port: 2055
buffer_size: 65536
timeout: 30s
避坑提示：不要在生产环境使用 glob 模式实时扫描海量日志目录。应使用白名单路径列表 + inotify 事件驱动，避免 CPU 和磁盘 I/O 被扫描操作打满。
4.3 元数据提取：上下文增强引擎
原始日志通常只包含 IP、端口、时间戳等基础字段。元数据提取模块负责将原始字段转换为安全决策所需的上下文信息，例如：将源 IP 映射为地理位置、将进程 PID 映射为可执行文件路径、将用户 ID 映射为部门与角色。
提取引擎采用 链式处理器 模式，每个处理器只负责一种元数据转换，处理器之间通过上下文对象传递数据：
- GeoIP 处理器：查询本地 GeoIP 数据库，输出国家、城市、ASN。
- 进程解析器：通过 /proc 或 Windows API 获取进程命令行、父进程、启动时间。
- 用户映射器：对接 LDAP/AD 或本地用户数据库，输出用户组与权限等级。
- 威胁情报标记器：将 IP/域名与本地威胁情报缓存比对，输出风险标签。
// 元数据提取链伪代码
public class MetadataPipeline {
private List<Processor> processors;
public EnhancedEvent process(RawEvent event) {
EnhancedEvent enhanced = new EnhancedEvent(event);
for (Processor p : processors) {
if (!p.process(enhanced)) {
// 处理器返回 false 表示跳过，不阻断整条链
continue;
}
}
return enhanced;
}
}
4.4 策略匹配：规则引擎与快速检索
策略匹配模块是决策的核心。Agent 本地维护一份从管理端同步的策略规则集，每条规则包含 条件表达式 和 动作。匹配引擎需要支持以下能力：
- 字段级匹配：支持等于、不等于、包含、正则、CIDR 范围、数值范围。
- 逻辑组合：AND / OR / NOT 嵌套，最多支持 5 层深度。
- 优先级裁决：高优先级规则优先匹配，同优先级下按首次命中原则。
- 快速失效：使用布隆过滤器或前缀树对高频字段（如源 IP、用户 ID）做预过滤，减少全量规则遍历。
| 规则 ID | 条件 | 动作 | 优先级 |
|---|---|---|---|
| R001 | source.ip IN 10.0.0.0/8 AND user.role != "admin" | BLOCK | 100 |
| R002 | dest.port == 22 AND geo.country == "CN" | CHALLENGE | 50 |
| R003 | threat.label CONTAINS "malware" | BLOCK | 200 |
性能基线：在 10,000 条规则、5 个匹配字段的条件下，单次匹配延迟应控制在 10ms 以内。超过该阈值时，建议启用规则编译缓存或切换为基于 rete 网络的规则引擎。
4.5 阻断/放行决策：动作执行与审计
决策模块接收策略匹配结果，结合当前 Agent 状态（如网络连接数、系统负载）做出最终动作。动作类型分为三种：
- ALLOW（放行）：日志事件正常进入 ELK 管道，不做任何拦截。
- BLOCK（阻断）：丢弃日志事件，并向管理端上报阻断记录。对于网络流日志，可联动 iptables/nftables 插入临时阻断规则。
- CHALLENGE（挑战）：将日志事件暂存至本地隔离区，要求用户进行二次认证（如 MFA）后才放行。
所有决策结果必须写入本地审计日志，格式如下：
{
"timestamp": "2025-03-21T14:30:00.123Z",
"agent_id": "agent-node-7",
"event_id": "evt-9a8b7c6d",
"decision": "BLOCK",
"rule_id": "R001",
"reason": "Internal IP from non-admin user",
"action_detail": "drop_packet | log_only"
}
4.6 Agent 核心功能架构图
下图展示四个核心模块之间的数据流与依赖关系：
4.7 决策流程与状态机
决策模块内部维护一个轻量级状态机，确保每个日志事件只被处理一次且结果可追溯。状态转换如下：
幂等保证：每个事件在进入 PENDING 状态时生成全局唯一 ID（UUID v7），决策结果写入本地 RocksDB 实例。即使 Agent 崩溃重启，已决策的事件不会重复处理，未决策的事件从 PENDING 状态重新进入匹配流程。
4.8 关键设计原则总结
- 低耦合：四个模块通过标准化事件接口交互，任一模块可独立替换或升级。
- 可观测：每个模块暴露 Prometheus 指标（处理延迟、吞吐量、错误计数），便于 ELK 统一监控。
- 安全优先：决策模块默认执行 白名单策略——未匹配任何规则的日志事件默认放行，但必须记录审计日志。
- 资源隔离：日志采集使用独立线程池，元数据提取使用协程池，策略匹配使用无锁环形缓冲区，避免模块间资源争抢。