1. 课程导论：可观测性概念、租户隔离的必要性、Docker 在其中的角色、安全评估的总体框架
1.1 可观测性（Observability）核心概念
可观测性并非单一工具或指标，而是通过系统外部输出来推断内部状态的能力。在云原生与微服务架构中，它通常由三大支柱构成：
| 支柱 | 定义 | 典型数据源 | 核心价值 |
|---|---|---|---|
| Metrics（指标） | 可聚合的数值时间序列 | Prometheus, VictoriaMetrics | 趋势监控、告警阈值、容量规划 |
| Logs（日志） | 离散的、带时间戳的事件记录 | ELK, Loki, Fluentd | 故障根因定位、审计追溯 |
| Traces（链路追踪） | 请求在分布式系统中的完整路径 | Jaeger, OpenTelemetry, Zipkin | 性能瓶颈分析、服务依赖拓扑 |
关键认知： 三大支柱并非孤立存在。现代可观测性强调“关联性”——例如通过 Trace ID 将日志与链路绑定，或通过 Metrics 中的标签（Label）下钻到具体 Trace。本课程所有架构设计均围绕这一关联性展开。
1.2 租户隔离的必要性
在多租户（Multi-Tenant）环境中，不同业务线、不同客户或不同环境（开发/测试/生产）共享同一套可观测性基础设施。若缺乏隔离，将引发以下严重问题：
- 数据泄露风险： 租户 A 的敏感日志或业务指标可能被租户 B 查询到。
- 噪声干扰： 一个租户的异常流量或错误日志会污染全局告警，导致误报。
- 资源争抢： 高流量租户可能耗尽存储或查询资源，影响其他租户的可用性。
- 合规失效： 金融、医疗等行业要求数据必须按租户物理或逻辑隔离，否则无法通过审计。
常见误区： 很多团队认为“只要在数据中加一个 tenant_id 标签就完成了隔离”。实际上，标签级隔离在查询性能、权限控制、资源配额方面存在巨大隐患。本课程将展示为什么需要“物理+逻辑”双层隔离架构。
1.3 Docker 在可观测性租户隔离中的角色
Docker 容器化技术为租户隔离提供了天然的边界与资源管控能力。其核心角色体现在三个层面：
| 层面 | Docker 能力 | 对可观测性隔离的价值 |
|---|---|---|
| 进程隔离 | Namespace（PID, Network, Mount） | 每个租户的可观测性 Agent 运行在独立容器中，互不感知 |
| 资源限制 | Cgroups（CPU, 内存, 磁盘 IO） | 防止单个租户的 Agent 或数据采集量影响全局基础设施 |
| 部署编排 | Docker Compose / Swarm / Kubernetes | 支持按租户维度独立部署 Collector、Storage 和 Query 组件 |
实践要点： 本课程后续章节将演示如何通过 Docker 网络隔离（如 macvlan/overlay）实现租户间可观测性数据的完全物理隔离，同时保留跨租户全局视图的查询能力。
1.4 安全评估的总体框架
本课程的安全评估并非泛泛而谈，而是围绕“可观测性数据生命周期”构建的闭环框架。评估覆盖以下五个阶段：
- 数据采集安全： Agent 身份认证、采集端点加密（mTLS）、防止伪造数据注入。
- 数据传输安全： 传输层加密（TLS 1.3）、网络策略最小化、防止中间人攻击。
- 数据存储安全： 租户级加密密钥管理、存储卷隔离、数据保留与销毁策略。
- 数据查询安全： 细粒度 RBAC/ABAC、查询审计日志、防止跨租户数据泄露（SQL/Lucene 注入）。
- 基础设施安全： Docker 守护进程安全、镜像漏洞扫描、运行时安全（Seccomp/AppArmor）。
框架核心原则： 安全评估不是一次性检查，而是持续性的“评估 → 加固 → 验证 → 监控”循环。本课程将在每个架构决策点嵌入对应的安全评估 checklist。
以下表格总结了安全评估框架与可观测性三大支柱的映射关系：
| 安全评估阶段 | Metrics 关注点 | Logs 关注点 | Traces 关注点 |
|---|---|---|---|
| 数据采集 | 指标注入认证 | 日志来源完整性 | Span 上下文合法性 |
| 数据传输 | gRPC TLS 配置 | Kafka TLS + SASL | OTLP 加密传输 |
| 数据存储 | TSDB 租户加密 | 索引加密 + 轮转 | Span 存储隔离 |
| 数据查询 | PromQL 租户过滤 | Kibana 空间隔离 | Jaeger 租户标签 |
| 基础设施 | Docker 资源隔离 | 容器日志逃逸防护 | Agent 权限最小化 |