开发者学堂课程【3天吃透 Prometheus：Prometheus 存储和集群】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1244/detail/18451
Prometheus 存储和集群
6、Prometheus 的高可用方案
（1）Prometheuss+InfluxDB（或其它TSDB，如M3DB等）
对中小企业来讲，Prometheuss+InfluxDB 是比较廉价易用的解决方案。两个实例加一个第三方存储。对规模不大的企业足够解决问题。还要加上Alertmanager，Alertmanager 还可以使用流言协议组织成集群就完成了。第三方存储包括著名的InfluxDB和M3DB。M3DB特别适用于帮 Prometheus 存样本或者指标数据。
纯手动组织适用于中小规模，不想手动组织可用第二种解决方案。
（2）Prometheus+Thanos
Thanos is an open source highly available Prometheus setup with long term storage and querying capabilities
Thanos是一个开源的，高可用 Prometheus 的解决方案。是专门用来部署高可用 Prometheus 的第三方的专门的解决方案。支持长期存储，还支持提供统一的查询接口。Thanos使得Prometheus的管理和使用更加方便。
All of these projects may fit specific use ,but none of them is a silver-bullet.The following benefits made us decide to go with Thanos：
Thanos不能适用于所有场景，但它有如下优势：
Stateless components 各个组件都是无状态的除了Thanos
Stable StoreAPI between services 支持稳定的API，再各服务之间通过storeAPI进行数据交互。
Historic metrics and the whole state are persisted to objcct storage 能够完整的保存历史数据。
Last but not least it is a CNCF projeetThanos_components（为了完成功能 Thanos 有如下组件）SlidecarStoreCompactQueryRuleBucker
这些组件需要部署到 KBS 上，因为 Thanos 是 CNCF 旗下原生产品。
Thanos部署示例
架构图如下
左边蓝色部分为被监控组件，中间为 Prometheus 抓联组件，需要在每一个 Prometheus 实例上加一个 setcar ,能够与 Thanos 控制端交互，而 Thanos 控制端控制端有 Cateway （网关）,Compacter（压缩器）,Querier（查询接口）。最终对应的数据都存储到Object store当中， Grafara 可以借助于 Thanos Querier 来进行数据展示，Prometheus各个实例可以通过Alertmanager 调 PagerDuty 或者其他媒介向管理员或者用户发送告警信息。
其中黑色线表示数据，红色为 Prometheus 的数据流向，紫色为 Thanos 的数据流向。
（3）Prometheus+Cortex：Prometheus-as-a-Service
Cortex也是CNCF上的，也是为了能够让Prometheus适配到KBS上，支持更强大功能而设计的一个解决方案，被称为Paas，它可以实现只需要调API发申请要Prometheus的监控系统，就能够呈现出来的功能。
为Prometheus添加长期存储、数据的全局视图及多租户功能(可以让整个集群上的空间单独地进行监控，在公有云多租户场景中是一个必须的组件)
特点如下：
支持多租户，作为服务的Cortex可提供鉴权和访问控制功能；
数据长期保留，状态可被管理；
高可用，可伸缩；
提供更好的查询效率及全局视图，尤其是长查询
组件
Distributor：使用Prometheus的远程写入API处理由Promethcus实例写入Cortex的时间序列数据；传入的数据会自动复制和分片；并且会并行发送到多个Cortcx Ingester；Ingester：从Distributor节点接收时间序列数据，然后将该数据写入长期存储后端，压缩数据到Promethcus块以提高效率；
Ruler：执行规则并生成告警，将告警发送到Alertanager；
Querier：处理来自客户端的PromOL查询，对短期时间序列数据和长期存储中的样本进行抽样；
7、Cortex 和 Prometheus 混合部署架构
Cortex 也完全可以不需要使用 Promethcus 来抓指标数据，只要兼容 Promethcus 的指标数据 Cortex 就有实例能够抓。因此Cortex 需要独立运行，告警信息通过 Alertmanager 来发送，Alertmanager 为 Cortex 部署并独立进行管理。通过Proxy还可以接入 Querying and data visualization 页面， Grafana 等都可以通过 Proxy 代理进而访问 Promethcus 。Long-term storage 支持图上四个组件。
总结：在小规模解决方案中如果把 Promethcus 高可用，部署PromethcusA 和 PromethcusB 监控同一组 target。
两个实例部署若有必要可指明究竟是哪个服务器监控的，可以给他们打上标签，例如 PromethcusA 监控打上 PromethcusA 标签，PromethcusB 监控的打上 Promethcus 的标签，就可以分辨出是哪一个服务器所监控的。
打标签对将来要进行联邦的时候或许会有用，对我们而言，做PromethcusAB 这种简单的负载均衡可用性机制可能会存在数据不一致的场景，但数据不一致没有太大的影响，可以建一个第三方存储。
Alertmanager 高可用需要指明在作为源协议的时候，通过哪一个端口和地址注册为集群内部通信的端口和地址， Alertmanager 所使用的的地址和端口和它的客户端所使用和提供的客户端和地址不同，因此在配置 Alertmanager 集群的时候需指明对应的Alertmanager 自己的对应的地址和端口。地址和端口指的是流言的地址和端口以及向客户端发送服务的地址和端口。
在不使用多余配置信息情况下的配置如下：
假设没有MS的参与，在Node01,Node02,Node03上做一个集群，切换到Promethcus之下，把Alertmanager复制给01，02,03.
配置的相关重要选项如下;
web.listen.address=”:9093” Alertmanager //自己的web监控地址端口9093。
cluster.listen.address=”0.0.0.0:9094//流言协议，多个集群间内部协作时监控的地址和端口，默认是本机的9094端口，在每个主机上进行配置时它们并没有容易冲突的地方，因此可以直接指定。但需要从cluster.peer=CLUSTER.PEER这个选项指明流言协议发送到哪一个节点，指明集群成员。显然在每一个节点上指明cluster 成员要指明Initial peers（初始化时所包含的节点）
cluster.peer.timeout=15//集群节点间通信时的超时时长
cluster.gosssip.interval=200ms//流言协议发送间隔，默认200ms
cluster.probe. interval=1s// 节点成员探测，探测的间隔时间
cluster.probe.timeout=500ms//节点成员探测的超时时间
启动第一个节点之后就可以加入第二、第三个节点来成为集群成员
之后先更改默认配置组成部分，没有问题后将配置组成分别复制进Node01,02,03中。然后先启动 Node01，一切完成没有问题后再设置节点2。配置好Node02，后续节点要加入到集群中去，需要使用cluster.peer=CLUSTER.PEER指定对端，加入第一个节点所在集群，其他实例使用默认值即可，节点间可正常通信就为正常。配置节点3逻辑相同。
打开 Alertmanager1.11:9093端口
在 Status 处，可以看到三个节点已经成为一个集群。
尝试发送告警可能会出现只有一个节点会触发告警，但在尝试告警时因为三个节点各自的 postface 没有启动需要使用它们本地的postface 服务，各自主机名不一样，此时使用本地的节点做告警效果不好。但我们自己进行测试时，可以直接指向互联网内126或者QQ的邮件服务，使得三个 Alertmanager 指向同一个服务，发邮件告警即可。
尝试最后一项，先将三个节点都屏蔽掉然后编辑配置文件，直接使用MS01 上的服务，
smtp_smarthost: ‘172.29.1.1.25’ 可用用这个端口作为邮件服务器，直接发给用户。能确保发告警邮件的时候，只会通过三个Alertmanager 发送一次，若连发三次则会在同一个账户收到三封邮件，若只收到一封，则这个集群功能是成功的。因此将receivers替换部分，使用中心邮件服务器尝试。配置完成后只启动Node01,集群生成状态状态如下图所示
加入第二节点后，集群生成状态更改为如下图：
接着在 Promethcus 服务器上监控三个节点，并且将这三个节点作为告警服务器，配置过程如下：
第一先编辑 Promethcus.yem，更改一下监控目标及目标服务器，Alertmanager 直接指向了 Alertmanager 直接更改一个文件即可。
接下来先更改然后将 target 目录下alertmanager.servers.yaml到tmp文件下，所以第一个服务器内应该有三个实例，分别是172.29.1.11:9093、172.29.1.12:9093、172.29.1.13:9093三个主机。都打上app为 alertanager,
targets: 172.29.1.11:9093labels: app:alertmanager 172.29.1.12:9093labels: app:alermanager 172.29.1.13:9093labels: app:alertmanager
然后复制这个文件到当前 targets 目录中，因为设定了每隔一分钟会重载一次，所以复制后会重载出有什么文件。若有错误则进行终止寻找错误。
Promethcus 界面的 Targets 如下，三个实例都应该被发现。
除此之外在 Service Discovery 处也可以显示三个告警信息。
还有在 Runtime information 处也可显示出来。
定两个告警条件尝试触发告警：
宕 Node02 如下所示
若 Targets 处报错
则 Alerts 处处于 ache 状态
当 PENDING 以后，就看是否能接收到邮件，因为不确定邮件是否有问题。
当自己做测试时如果也不使用互联网的邮件服务，就把 postface 调整为能给集域网发邮件即可。
在 admin 上查看是否有新发的邮件。若没有收到则发明邮件配置有问题。不成功可能是因为对 magdue 这个域的解析是失败的，因为互联网有这个域名，通过这个节点上面的 resolve.conf 这个文件解析这个域时很有可能解析到互联网上去了。
做练习时可用微信或钉钉将它们配置成告警媒介，配置一个 receiver 看是否能收到邮件信息。这与 Promethcus 关系不大，主要为如何调 API 来发送告警。
如果三个 Alertmanager 都触发，则把 node03 宕掉所剩的告警信息应该会向 admin 多次发送邮件。
