《Prometheus监控实战》第7章 可靠性和可扩展性

第7章 可靠性和可扩展性

• 分为两个问题进行考虑

1. 可靠性和容错性
2. 可扩展性

7.1 可靠性和容错性

• 通常的实现方式是构建集群。但是，集群解决方案需要相对复杂的网络，并且需要解决集群中节点之间的状态管理问题
• Prometheus架构认为，实现集群所需的投入以及维护集群节点之间数据一致性的成本要高于数据本身的价值
• Prometheus推荐的容错解决方案是并行运行两个配置相同的Prometheus服务器，并且这两个服务器同时处于活动状态。该配置生成的重复警报可以交由上游Alertmanager使用其分组（及抑制）功能进行处理。一个推荐的方法是尽可能使上游Alertmanager高度容错，而不是关注Prometheus服务器的容错能力

• 这种方法可以通过创建一个Alertmanager集群来实现的。所有Prometheus服务器会向所有的Alertmanager发送警报。Alertmanager负责去除重复数据并通过集群共享警报状态
• 这种方法有明显的缺点。首先，两个Prometheus服务器都会收集指标，以加倍该集合可能产生的工作负载。其次，如果某个Prometheus服务器出现故障或中断，那么另一台服务器就会存在数据缺失，在查询该服务器上的数据时会发现这一差距
• 提示：有多种方法可以在PromQL中对上述问题进行修补。例如，当请求来自两个源的同一指标值 时，你可以通过max by获取两个指标的最大值。或者，当单个工作分片可能存在差距的警报发生时，你可以增加for子句以确保有多个值

7.1.1 重复的Prometheus服务器

• 两个重复的Prometheus服务器的细节，使用配置管理工具可以相对容易实现这一点

7.1.2 设置Alertmanager集群

• Alertmanager包含由HashiCorp Memberlist库（https://github.com/hashicorp/memberlist）提供的集群功能。Memberlist是一个Go语言库，使用基于gossip的协议来管理集群成员和成员故障检测，其也是SWIM协议的扩展（http://arvix.org/abs/1707.00788）
• 我们在每个主机上安装Alertmanager，将使用am1主机来启动集群
• 代码清单：启动Alertmanager集群

• 我们运行alertmanager二进制文件来指定一个配置文件，以及一个集群监听地址和端口。你需要在集群中的每个节点上使用相同的配置，这样可以确保对警报的处理是相同的，并且确保集群的一致性
• 警告：所有Alertmanager应使用相同的配置！如果不相同，那么集群实际上并不是高可用的
• 我们指定了am1主机的IP地址172.19.0.10和8001端口。Alertmanager集群中的其他节点将使用这个地址和羊肉串连接到集群，因此该端口需要在Alertmanager集群节点之间的网络上保持可访问状态
• 提示：如果未指定集群监听地址，则默认为0.0.0.0的9094端口
• 在其他两台主机上运行Alertmanager，监听它们的本地IP地址，并引用刚刚创建的集群节点的IP地址和端口
• 代码清单：启动Alertmanager集群的其他节点

• 可以看到我们在另外两个Alertmanager主机（am2和am3）上同样运行alertmanager二进制文件，并使用各自的IP地址和8001端口来为每台主机指定一个集群监听地址。还使用集群cluster.peer参数来指定am1节点的IP地址和端口作为peer，以便它们可以加入集群
• 可以在Alertmanager的控制台状态页面/status上进行确认。我们来看看主机am1上显示的集群状态https://172.19.0.10:9093/status

• 可以在一个Alertmanager上设置silence并查看配置是否复制到其他Alertmanager节点，以此来测试集群是否正常工作。为此，请单击am1上的New Silence按钮并设置silence，然后检查am2和am3上的/silences路径，应该可以看到所有主机上都复制了相同的silence配置

7.1.3 为Prometheus配置Alertmanager集群

• Alertmanager集群本身负责与集群的其他活动成员共享所有收到的警报，并处理数据去重（如果需要）。因此，你不应该为Alertmanager设置负载平衡，因为Prometheus会帮你处理
• 代码清单：Alertmanager静态定义

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - am1:9003
      - am2:9003
      - am3:9003

• 我们可以为每个Alertmanager添加DNS SRV记录
• 代码清单：Alertmanager SRV记录

• 我们以SRV记录的形式指定了名为_alertmanager的TCP服务。我们的记录返回三个主机名am1、am2和am3，以及端口号9093（Prometheus可以在这里找到一个正在运行的Alertmanager）。让我们配置Prometheus服务器来发现它们
• 代码清单：Alertmanager服务发现

alerting:
  alertmanager:
  - dns_sd_configs:
    - names: ['_alertmanager._tcp.example.com']

• 在这里，Prometheus将查询alertmanager.example.com SRV记录以返回Alertmanager列表。我们可以使用其他服务发现机制，让Prometheus识别集群中的所有Alertmanager
• 如果现在重新启动Prometheus，那么我们可以在Prometheus服务器的状态页面中看到所有连接的Alertmanager
• 现在，当有警报时，它将被发送到所有已发现的Alertmanager。Alertmanager接收警报、处理数据去重并共享 状态
• Prometheus连接的Alertmanager集群

7.2 可扩展性

• Prometheus环境扩展通常有两种形式：功能扩展或水平扩展

7.2.1 功能扩展

• 功能扩展使用分片将监控内部分布到不同的Prometheus服务器上。例如，可以通过地理位置或者逻辑域来拆分服务器

• 或者可以通过特定功能，将所有基础设施监控发送到一台服务器，而将所有应用程序监控发送到另一台服务器
• 按功能分片

• 如果需要对某些区域或功能进行整体视图查看，那么你可以使用联合功能（federation）将时间序列撮到集中的Prometheus服务器。Grafana支持从多个Prometheus服务器撮数据来构建图形，允许在可视化级别联合来自多个服务器的数据，前提是收集的时间序列具有一定的一致性（https://grafana.com/docs/grafana/latest/features/datasources/mixed/#mixed-data-source）

7.2.2 水平分片

• 当单个作业包含数千个实例时，可以考虑另一种方案：水平分片。水平分片使用一系列工作节点（worker），每个节点都抓取一部分目标。然后，我们在工作节点上汇总感兴趣的特定时间序列。例如，若我们正在监控主机指标，则可能会汇总这些指标的子集。然后，主节点（primary）使用Prometheus federation API来抓取每个工作节点的聚合指标（https://prometheus.io/docs/prometheus/latest/federation/）

scrape_configs:
  - job_name: 'federate'
    scrape_interval: 15s

    honor_labels: true
    metrics_path: '/federate'

    params:
      'match[]':
        - '{job="prometheus"}'
        - '{__name__=~"job:.*"}'

    static_configs:
      - targets:
        - 'source-prometheus-1:9090'
        - 'source-prometheus-2:9090'
        - 'source-prometheus-3:9090'

• 水平分片

• 主节点不仅可以提取聚合指标，还可以为Grafana等工具暴露指标或者作为可视化的默认数据源
• 这种扩展方式存在风险和限制，最显而易见的是，你需要从工作节点中抓取一部分指标，而不是大量或正在收集的所有指标。这是一个类似金字塔的层级结构，而不是分布式的层级结构。此外，你还需要考虑主节点对工作节点的抓取请求负载
• 还需要担心主节点与工作节点之间的连接，而不仅仅是工作节点与目标之间的连接。这可能会降低解决方案的可靠性
• 最后，数据的一致性和正确性也可能会降低。工作节点正在根据设定的间隔抓取目标，而你的主节点也要抓取工作节点。这会导致到达主节点的结果出现延迟，并可能导致数据化作或警报延迟
• 两个问题的后果是，在主节点上集中警报可能不是一个好主意。相反，应该将警报推送到工作节点上，在那里更有可能识别出问题，或者减少识别警报条件和触发警报之间的滞后
• 注意：水平分片通常是最后的选择。我们希望在你需要以这种方式扩展之前，每个目标都有数万个目标或大量时间序列