2. 核心概念：OpenTelemetry Collector 架构与 Prometheus 基础组件

在云原生可观测性体系中，OpenTelemetry Collector 与 Prometheus 是两个核心支柱。Collector 负责数据的采集、处理与导出，而 Prometheus Server 与 Alertmanager 则构成指标存储与告警的闭环。理解它们的内部架构是构建可靠日志平台的前提。

2.1 OpenTelemetry Collector 三阶段架构

Collector 采用管道（Pipeline）模式，数据流经 Receiver → Processor → Exporter 三个核心阶段。每个阶段均可独立配置与扩展，支持多种数据格式（Traces、Metrics、Logs）。

2.1.1 组件职责对比

2.1.2 Collector 内部数据流

下图展示了单个 Pipeline 中数据从接收到导出的完整路径。实际部署中可定义多个 Pipeline 实现数据隔离。

2.2 Prometheus Server 核心组件

Prometheus Server 是 Prometheus 生态的中央组件，负责指标抓取、存储与查询。其内部模块化设计保证了高可用与扩展性。

2.2.1 组件清单与功能

2.2.2 Prometheus Server 内部模块关系

2.3 Alertmanager 基础组件

Alertmanager 负责接收 Prometheus Server 推送的告警，执行去重、分组、静默与路由，最终通过多种渠道（Email、PagerDuty、Webhook）发送通知。

2.3.1 Alertmanager 核心流程

1. 接收告警： 通过 Alertmanager API 接收来自 Prometheus 或其他源的告警。
2. 分组（Grouping）： 按标签（如 severity、cluster）将相似告警合并为一个通知，避免告警风暴。
3. 静默（Silencing）： 根据静默规则屏蔽特定告警（如计划内维护）。
4. 抑制（Inhibition）： 当高等级告警触发时，自动抑制低等级相关告警。
5. 路由（Routing）： 根据 route 配置将告警发送到不同的接收器（Receiver）。
6. 通知（Notification）： 调用接收器（Email、Slack、Webhook 等）发送最终告警消息。

2.3.2 配置示例：告警路由与接收器

route:
  receiver: 'default-receiver'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
    - match:
        severity: warning
      receiver: 'email-warning'

receivers:
  - name: 'pagerduty-critical'
    pagerduty_configs:
      - routing_key: '<your-key>'
  - name: 'email-warning'
    email_configs:
      - to: 'ops@example.com'

2.4 组件协同关系总结

在云原生日志平台中，OpenTelemetry Collector 与 Prometheus 生态的协同关系可概括为：

• Collector 负责统一采集日志、指标、链路数据，通过 Processor 进行预处理，再通过 Exporter 分发到不同后端。
• Prometheus Server 专注于指标存储与查询，通过 Service Discovery 动态发现目标，Retrieval 模块拉取指标，TSDB 持久化。
• Alertmanager 接收 Prometheus 的告警，执行分组与路由，确保告警准确送达。
• 日志数据（Logs）通常由 Collector 导出到 Loki 或 Elasticsearch，而指标数据（Metrics）流向 Prometheus，形成完整的可观测性数据平面。