1. 引言：当可观测性遇上安全
过去十年，可观测性（Observability）与安全（Security）几乎是两条平行演进的技术赛道。前者围绕 Metrics、Logs、Traces 三大支柱，服务于 SRE 与研发团队，目标是"更快发现并定位故障"；后者围绕威胁检测、事件响应、合规审计，服务于安全团队，目标是"更快发现并阻断攻击"。
但当我们把视角拉高会发现：两者本质上都在回答同一个问题------"系统里正在发生什么，以及这是否正常？" 故障与攻击在数据层面高度同构：一次异常的 CPU 飙升，可能是流量突增，也可能是一次挖矿木马；一次异常的出站连接，可能是业务调用，也可能是一次数据外泄。
本文从 CNCF 的行业观察出发，结合安全厂商收购可观测性公司的产业信号，探讨如何以 OpenTelemetry 为骨干构建统一数据采集层，用 Trace 关联分析还原攻击链路，并给出 Security Observability 平台的技术选型建议。
2. CNCF CTO 观察：可观测性与安全正在融合
CNCF CTO 在多个公开场合反复强调一个判断：可观测性与安全的边界正在消失。这一判断并非概念炒作，而是由三个现实因素共同推动：
- 数据同源：安全检测所需的运行时行为数据（进程、网络、文件、系统调用），与可观测性所需的运行时上下文（服务、依赖、调用链）来自同一批采集点。重复采集意味着双倍开销与双份维护成本。
- 响应同速：云原生环境下，攻击窗口以分钟计。安全团队如果还在等日志从另一个系统批量导出，就已经错过了最佳处置时机。可观测性平台提供的实时流式能力，正是安全响应所需要的。
- 组织同频：越来越多企业将 SRE 与安全运营（SecOps）纳入同一个平台工程团队，共享数据底座与告警通道，避免"两套系统、两套口径、两套值班"。
CNCF 社区的具体动作也印证了这一趋势：OpenTelemetry 项目持续扩展对安全相关信号的支持，Falco 等运行时安全项目与可观测性生态的集成日益紧密，Kubernetes 审计日志、eBPF 采集等能力被逐步纳入统一的数据管道。
一句话总结：可观测性是安全的数据底座，安全是可观测性的价值延伸。
下图展示了可观测性与安全在数据、响应、组织三个维度上的融合关系：
3. 安全厂商收购可观测性公司的行业信号
如果说 CNCF 的观察是"技术趋势"，那么资本市场的动作就是"产业确认"。近几年，多起安全厂商收购可观测性/日志分析公司的案例，释放出明确的行业信号：
| 信号维度 | 具体表现 | 深层含义 |
|---|---|---|
| 能力补齐 | 安全厂商收购日志分析、APM、追踪类公司 | 单纯依赖网络流量与终端 Agent 已不足以覆盖云原生攻击面 |
| 数据整合 | 将安全事件与业务调用链数据打通 | 检测需要业务上下文，否则误报率居高不下 |
| 平台化 | 从单点工具走向统一数据平台 | 客户不愿为"安全"和"运维"分别采购两套数据底座 |
| 商业模式 | 按数据量计费向按价值/风险计费演进 | 安全效果需要可度量，而度量依赖可观测数据 |
这些收购背后的共同逻辑是：安全产品的竞争力，正在从"检测规则的数量"转向"数据上下文的深度"。一个能回答"这个异常请求来自哪个服务、经过了哪些依赖、影响了哪些用户"的平台，其检测价值远高于一个只会喊"发现可疑 IP"的工具。
对建设者而言，这意味着选型时不应再把可观测性平台与安全平台割裂评估，而应优先考虑能否共享同一套采集、存储与查询能力。
从"单点工具"到"统一数据平台"的演进路径，可以更直观地理解这些收购背后的产业逻辑：
4. 统一数据采集：OpenTelemetry 作为安全遥测的骨干
4.1 为什么选择 OpenTelemetry
OpenTelemetry（OTel）已成为云原生可观测性的事实标准，其核心价值在于厂商中立的数据模型与统一的采集协议（OTLP）。将其作为安全遥测的骨干，有三点关键理由：
- 一次采集，多处消费：同一份 Trace/Log/Metric 数据，既可供 SRE 排障，也可供安全规则引擎检测，避免重复埋点。
- 语义约定可扩展 ：OTel 的 Semantic Conventions 为资源属性（如
k8s.pod.name、process.command_line）提供了标准化命名，安全检测规则可以直接基于这些属性编写，跨环境可移植。 - 生态完整：Collector 支持丰富的 Processor 与 Exporter，可在数据管道中完成脱敏、采样、富化与分流。
下图对比了传统"双管道"采集与 OTel 统一采集的差异：
4.2 采集架构设计
4.3 关键实践要点
- 统一资源属性 ：为每个遥测数据附加
service.name、k8s.namespace.name、cloud.account.id等资源标签，这是后续安全关联分析的"主键"。 - 安全信号标准化：将进程执行、文件访问、网络连接等安全事件映射为 OTel Log 记录，并遵循统一的属性命名，避免各 Agent 各自为政。
- 分级采样策略：对高价值安全信号（如特权进程启动、敏感文件访问）采用全量采集，对普通业务 Trace 采用尾部采样，平衡成本与覆盖。
- 数据脱敏前置：在 Collector 层完成 PII 脱敏，确保安全数据留存不违反合规要求。
yaml
# OTel Collector 配置片段：安全信号分流示例
processors:
batch:
timeout: 5s
attributes/security:
actions:
- key: telemetry.category
value: security
action: insert
tail_sampling:
policies:
- name: security-critical
type: string_attribute
string_attribute:
key: security.severity
values: ["high", "critical"]
- name: baseline
type: probabilistic
probabilistic:
sampling_percentage: 10
exporters:
otlp/observability:
endpoint: obs-backend:4317
otlp/security:
endpoint: sec-engine:4317
service:
pipelines:
traces:
receivers: [otlp]
processors: [attributes/security, tail_sampling, batch]
exporters: [otlp/observability, otlp/security]5. 安全事件的 Trace 关联分析：从指标异常到攻击链路还原
5.1 核心思路
传统安全告警是"点"------一个可疑 IP、一次异常登录。而 Trace 提供的是"线"------一次请求从入口到出口的完整路径。将安全事件挂载到 Trace 上，就能把孤立的告警点连成可解释的攻击链路。
5.2 关联分析流程
5.3 典型关联场景
场景一：从资源异常到挖矿木马
某 Pod CPU 持续 100%，可观测性平台告警。通过 Trace 关联发现该 Pod 在异常时段内启动了 xmrig 进程（来自 eBPF 采集的进程执行事件），并存在到矿池地址的出站连接。三个信号叠加，从"性能问题"升级为"安全事件"。
场景二：从异常出站到数据外泄
安全引擎检测到某服务向陌生域名发起大量 HTTPS 请求。通过 Trace 回溯，发现该请求源自一个被注入的依赖库，且调用链上游是用户数据查询接口。由此确认这是一次供应链投毒导致的数据外泄尝试。
场景三：从登录异常到横向移动
身份系统报告某账号在短时间内从多个地域登录。通过 Trace 关联该账号发起的 API 调用，发现其访问了多个本无权限的服务，且调用模式呈现明显的自动化扫描特征，判定为凭证泄露后的横向移动。
三个典型场景在信号来源与攻击阶段上的对应关系如下：
5.4 实现要点
- Span 与安全事件对齐 ：在关键 Span 上附加
security.event.type、security.risk.score等属性，使安全事件天然具备调用链上下文。 - 统一时间基准：所有采集点必须做时钟同步（NTP/PTP），否则跨源关联会因时间漂移而失效。
- 保留原始数据：关联分析往往需要回溯原始日志，因此需在数据湖中保留足够长的原始数据窗口（建议不少于 30 天）。
6. 构建 Security Observability 平台的技术选型
6.1 选型原则
- 开放优先：优先选择支持 OTLP、OpenTelemetry 语义约定的组件，避免被单一厂商锁定。
- 存算分离：采集、存储、查询分层解耦，便于按需扩展与成本优化。
- 安全内建：脱敏、访问控制、审计日志应作为平台的基础能力，而非事后补丁。
6.2 分层选型建议
| 层次 | 能力要求 | 候选方案 |
|---|---|---|
| 采集层 | 多源接入、低开销、可扩展 | OpenTelemetry Collector、eBPF Agent（如 Cilium Tetragon、Falco） |
| 传输层 | 高吞吐、可靠投递 | Kafka / Pulsar 作为缓冲与解耦 |
| 存储层 | 多模态存储、冷热分层 | ClickHouse（日志/事件）、Prometheus 兼容 TSDB（指标）、对象存储（Trace 与归档） |
| 查询分析层 | 关联查询、链路还原 | 支持 TraceQL / SQL 的查询引擎，图数据库辅助链路建模 |
| 检测层 | 规则 + 行为基线 + ML | Sigma 规则引擎、Falco 运行时规则、异常检测模型 |
| 响应层 | 自动化编排 | SOAR 平台、K8s 准入控制、网络策略联动 |
各层组件之间的数据流向与职责边界如下：
6.3 落地路线图
- 阶段一（1--2 个月）：完成 OTel Collector 部署与核心服务接入，统一资源属性规范。
- 阶段二（2--3 个月）：打通 Trace 与安全事件数据，建立关联查询能力，验证 2--3 个典型场景。
- 阶段三（3--6 个月）：沉淀检测规则库，引入行为基线，降低误报率。
- 阶段四（持续）：对接响应编排，实现从检测到处置的自动化闭环。
6.4 常见坑与规避
- 数据量失控：安全信号全量采集容易导致存储成本飙升，务必提前设计采样与保留策略。
- 关联字段缺失：如果早期没有统一资源属性，后期关联分析会非常痛苦，务必在阶段一就定好规范。
- 组织壁垒：技术打通容易，团队协作难。建议设立联合平台团队，共享 SLO 与值班机制。
7. 总结
可观测性与安全的融合，不是把两个系统简单拼在一起，而是在数据层面建立统一的语言。OpenTelemetry 提供了这套语言，Trace 关联分析提供了还原攻击链路的方法论，而分层解耦的技术选型则保证了平台的可演进性。
对于正在建设统一数据平台的团队，建议从"统一采集"这一最小切口入手，先让数据流起来，再逐步叠加检测与响应能力。融合的价值不在于工具的数量，而在于当异常发生时，你能用同一份数据同时回答"哪里坏了"和"谁在攻击"。