本次读后感来自于《深入浅出Prometheus：原理、应用、源码与拓展详解》
书籍链接https://item.jd.com/12573580.html
一 报警
Prometheus 本身对不会对告警进行处理，需要借助另一个组件 AlertManager。Prometheus会配置AlertManager的地址，这样Prometheus发出的告警记录便可以被发送到AlertManager进行处理。
AlertManager 和 Prometheus同样是由 Go 语言开发的，主要功能包括：告警分组、告警抑制和告警静默。
◎ 告警分组指将多条告警合并到一起发送。
◎ 告警抑制指当告警已经发出时，停止发送由此告警触发的其他错误告警。
◎ 告警静默指在一个时间段内不发出重复的告警。AlertManager主要分为两个部分：路由（router）和接收器（receiver）。告警消息先经过路由树，然后被分配到对应的接收器中。路由树是由预先设定的路由规则生成的。AlertManager的高可用架构如图
在高可用架构中，每个 Prometheus 都会配置多个 AlertManager，避免单点故障，其具体流程如下。
（1）Prometheus会通过调用AlertManager提供的告警接口将原始的告警消息发送到AlertManager。
（2）AlertManager的 API除了接收告警，还接收静默请求，将其分别保存到各自的provider里。
（3）provider提供了一个订阅（subscribe）接口，这样Dispatcher组件便可以获取告警数据，并对数据进行分组，通过用户预先设置的规则进入告警抑制阶段或静默阶段。
（4）如果通过了上面的告警静默阶段，则进入路由分发阶段，最终发送通知。
当然，Prometheus配置多个AlertManager会导致重复发送告警，为了解决这个问题，AlertManager引入了 Gossip，这个协议本身比较容易理解，就是以“流言”的方式传播到每个节点，并且拒绝接收重复的消息。
Gossip是一种最终一致性协议，主要负责两处信息的同步，
如下所述。
（1）保证每个 AlertManager的静默配置是一致的，从而保证每个 AlertManager都能静默告警。
（2）告警在每个 AlertManager之间同步，通过Gossip告知其他节点已经发出告警，如果有相同的告警，则需要去重（Dedup）。这里还有一个细节：如果告警是同时发出的，还没等到 Gossip 同步，则该怎么办？为了解决这个问题，AlertManager通过一个 Wait 机制，将每个节点的 Wait 时间调整到不同的时间，例如第1个AlertManager的Wait时间是0s，而第2个AlertManager的Wait时间是5s（index× 5s），这样可以保证有充分的时间来完成数据同步。
二 联邦
为了扩展单个 Prometheus 的采集能力和存储能力，Prometheus 引入了“联邦”的概念。
多个 Prometheus节点组成两层联邦结构，上面一层是联邦节点，负责定时从下面的Prometheus节点获取数据并汇总，部署多个联邦节点是为了实现高可用；下层的 Prometheus 节点又分别负责不同区域的数据采集，在多机房的事件部署中，下层的每个Prometheus节点都可以被部署到单独的一个机房，充当代理。
这种架构不仅降低了单个Prometheus的采集负载，而且通过联邦节点汇聚核心数据，也降低了本地存储的压力。为了避免下层Prometheus的单点故障，也可以部署多套 Prometheus 节点，只是在效率上会差很多，每个监控对象都会被重复采集，数据会被重复保存。这种联邦方案并不是最完善的解决方案，原因如下：
◎ 这种配置方式相对复杂，缺少统一的全局视图；
◎ 对历史数据的存储问题仍未得到彻底解决，必须依赖第三方存储，并且缺少针对历史数据的降准采样能力；
◎ Prometheus在设计之初的定位就是一款实时监控系统，这是根本原因。
三 Prometheus的一些缺陷
作为软件相关的工作者，我们确信任何工具都没有银弹，即便是Prometheus这样流行的工具，原因如下。
◎ Prometheus只针对性能和可用性监控，并不具备日志监控等功能，并不能通过Prometheus解决所有监控问题。
◎ 由于对监控数据的查询通常都是最近几天的，所以 Prometheus 的本地存储的设计初衷只是存储短期（一个月）数据，并非存储大量历史数据。如果需要报表之类的历史数据，则建议使用Prometheus的远端存储如OpenTSDB influxdb等。
◎ Prometheus的监控数据没有对单位进行定义，这里需要使用者自己区分或者事先定义好所有监控数据单位，避免发生数据缺少单位的情况。如果要为多租户提供监控视图，则还需要各个业务系统基于 Prometheus 的多维度指标自己进行组合。
四 Thanos
针对Prometheus这些不足，Improbable开源了他们的Prometheus高可用解决方案 Thanos。
Thanos和 Prometheus无缝集成，并为 Prometheus带来了全局视图和不受限制的历史数据存储能力。在 Thanos 产生前，在 Improbable 公司内部存在多套 Kubernetes 容器集群，每个集群都部署了一套独立的 Prometheus，再通过 Grafana 之类的展现工具分别查看每个集群的资源，缺乏一个全局资源视图；另一方面，Prometheus的高可用需要得到保证，需要一套数据备份方案及历史数据存储方案。在这种背景下，Thanos出现了。
1.Thanos的4个组件
它主要有4个组件：Querier、Sidercar、Store和Compactor。
每个 Prometheus节点都配置了一个 Sidercar组件，Prometheus通过 Kubernetes的部署，可以将Sidercar容器和 Prometheus容器集成到一个 Pod中。
Sidercar
组件有两个主要作用，一是用来代理Querier 对 Prometheus 本地数据的读取，二是将Prometheus本地监控数据通过对象存储接口保存到对象存储中。
Querier
接收 HTTP的 PromQL查询，组件负责数据查询汇聚。当 Querier收到一个请求时，它会向相关Sidecar发送GRPC查询请求，Sidercar再去调用Prometheus的 API 并返回获取的监控数据，Querier 将这些数据聚合在一起，并对它们执行PromQL查询。
为了持久化历史数据，Sidercar 会监控 Prometheus 的本地存储，如果发现有新的监控数据保存到磁盘，则将这些监控数据保存到S3对象存储上；相应地，在查询数据时，如果需要查询历史数据，则Querier会调用
Store
的接口，Store再通过 S3对象存储接口获取数据，Store会将S3的对象数据转化为Querier所需的数据格式。
Compactor
是一个批处理组件，主要负责针对S3的对象压缩，可以将历史的小对象（block，块）合并压缩成大文件对象，对齐数据并且删除这些小文件，从而节省存储占用。
2.节点发现
Querier会通过Store API获取每一个Sidecar上的监控数据。为了让Querier找到Sidecar节点，Thanos引入了Gossip。Thanos的每个组件之间都通过Gossip通信，这样不仅可以动态添加、删除组件节点，还可以在每个节点之间共享元数据信息，但这是有代价的：
（1）Gossip本身比较复杂，维护成本较高；
（2）Gossip全互联NN的方式没有必要存在，因为对于Querier来说，它只需知道所有实现的StoreAPI节点即可；
（3）Gossip底层采用UDP和TCP，如果在网络中只有七层负载均衡，那么会非常尴尬。所以，Thanos 正逐渐淘汰这种做法，而使用基于文件或者 DNS 的方式完成节点注册和发现。
3.历史数据存储
Sidercar可以将本地数据保存到对象存储中。这里简单回顾Prometheus 2.0的数据存储方式，Prometheus 将监控数据按照时间顺序以 block 方式进行划分并存储到磁盘中，在每个block内部通过index索引chunks里面的监控数据。
Thanos的 Sidecar目前只支持 Prometheus 2.0版本以后的数据格式，Sidecar每隔30s 读取一次本地元数据，查看是否有新的监控数据落盘，如果有，则读取本地数据块并将其上传到对象存储，标记最新的读取时间并且通过本地 JSON 文件保存已经上传的块，避免重复上传。
4.历史数据降准对
历史数据的检索通常需要通过降准方式进行：如果检索一天的数据，则通常以h或者10min为准度；如果检索一个月的数据，则通常以 d或者 h为准度；如果检索一年的数据，则准度更低。Thanos会将原始的监控数据降准汇聚，将初始以30s为周期采集的监控数据经过两次压缩后，汇聚成以1h为周期的数据，
数据降准的方式比较简单，需要汇聚 count（个数）、sum（总和）、min（最小值）和max（最大值）
◎ count指将这个压缩时间段内的监控指标个数求和。
◎ sum指对监控指标的数值求和。
◎ avg可以通过sum/count求取。
◎ min和max分别是这个时间段内监控的最大值和最小值。Thanos方案本身对于Prometheus没有任何侵入，可以很好地扩展，但其本身依赖对象存储服务，这部分成本也是需要考虑的。