按需采集关键事件的核心是源头过滤和规则前置，即在日志产生端或转发链路第一环节裁剪，聚焦安全类（如ssh失败登录）、稳定性类（如服务崩溃）、业务类（如支付失败）等高价值日志，通过rsyslog的filter+action精准拦截或重定向。
按需采集关键事件，核心是减少冗余、聚焦高价值日志，而不是全量收进再筛选。重点在于源头过滤和规则前置——在日志产生端或转发链路第一环节就做裁剪，避免带宽、存储和分析成本被低价值日志拖累。
明确哪些算“关键事件”
关键事件不是凭感觉定的，而是结合业务风险与运维目标来定义：
- 安全类：SSH 失败登录（auth.err）、sudo 权限提升（auth.info）、防火墙拒绝记录（kern.warn）、用户账户异常变更（authpriv.info）
- 稳定性类：服务崩溃（daemon.err）、磁盘空间告警（user.warning）、OOM killer 触发（kern.emerg）、系统重启日志（syslog.info）
- 业务类：支付失败（local7.err）、订单超时（local6.warn）、API 响应 5xx（local5.err）——需提前约定 facility 和 level
在 rsyslog 中实现精准过滤
不要依赖后端平台做海量日志的全文检索，而应在 rsyslog 配置里直接拦截或重定向关键事件：
- 用 filter + action 组合只转发匹配项：例如
if $programname == 'sshd' and $syslogseverity （只发 warning 及以上 sshd 日志） - 用 stop 终止非关键日志继续处理：
if $syslogfacility-text == 'mail' then stop（丢弃全部邮件日志） - 把关键日志单独写入专用文件并启用轮转：
local7.* /var/log/app-critical.log;RSYSLOG_FileFormat，再配置 LogListener 或 Azure Monitor 只采集该路径
远程采集时控制协议与粒度
跨网络传输是瓶颈点，必须兼顾可靠性和精简性：
- 优先选 TCP 而非 UDP，避免关键日志因丢包丢失；若必须用 UDP，建议搭配 RELP 协议（rsyslog 支持）保障投递确认
- 在腾讯云 CLS 或 Azure Monitor 的采集配置中，关闭“解析失败上传”，并设为 auto 解析协议；对不匹配 RFC3164/RFC5424 格式的杂日志直接丢弃，不占存储
- Azure DCR 配置 Syslog 数据源时，对每个 facility 单独设置最低 level——比如 auth 设为 alert，而 daemon 设为 err，避免 info 级日志涌入
验证与持续调优
规则上线后必须验证是否真在“按需”工作：
- 用
logger -p local7.err "test critical"发测试日志，检查是否出现在目标位置；再发logger -p local7.info "test info"，确认未被采集 - 观察采集端日志量变化：正常情况下，开启按需采集后日均体积应下降 40%–70%，若降幅不足，说明过滤规则覆盖不全或有设备未同步配置
- 每季度回顾一次关键事件清单，剔除已下线服务的日志项，新增新接入系统的 high-risk facility/level 组合
