开发者学堂课程【3天吃透 Prometheus：Prometheus 存储和集群】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1244/detail/18451
Prometheus 存储和集群
4、Prometheus 存储配置
（1）配置参数口
--storage.tsdb.path：数据储存路线，WAL日志亦会储存于该目录下，默认为data；
-storage.tsdb.retention.time：样本数据在储存中保存的时间长，超过该时间长的数据就会被删除；默认为15d；(可以自己更改时间)
--storage.tsdb.retention.size：每个 Block 的最大字节数（不包含WAL 文件），支持B、KB、MB、GB、TB、PB和EB，例如512MB等：
--storage.tsdb.wal-compression：是否启用 WAL 的压缩机制，2.20及以后的版本中默认即为启用；
(2)容量规划
needed_disk_space=retention_time_scconds*ingested_samples_per_second*bytes_per_sample
需要用到的磁盘空间=保存时长*每秒钟的平均样本数*每个样本的字节数（每个样本值几乎是等同的）
例：1秒钟采集一个样本，每个样本大小大约为1.7KB，保存30天所需的磁盘空间为
10000*1.7KB*30*86400
目前固态硬盘不再是稀有物，完全可以把批发读写这样的数据放在性能比，磁盘IO性能较好的设备上进行保存。但固态硬盘的可靠性不如机械硬盘，可以让固态硬盘当缓存，自己将程序再写一遍然后定期同步到机械硬盘中。
5、Prometheus 远程存储
Prometheus 本地存储时间不长，若想长期存储，存到Prometheus 并不合适因为 Prometheus 是一个监控系统，它的核心功能是监控。因而 Prometheus 最好能使用专门外置的存储系统来存储数据。Prometheus 没有除 tsdb 这样的引擎之外的其他存储设备，它可以直接支持借助于远端的第三方的存储服务来存储数据，远端的存储服务要使用 Adapter 来进行适配。 Adapter 对于 Prometheus，可以通过 PrometheusQL 把数据查出再导入到另外一个存储系统中。读取时，适配器将数据从存储系统中读出，然后交给 Prometheus 的内存再显示给用户。对 Prometheus 而言，适配器对写和读是分开操作的，写可以写在一个存储中，读可以在另外一个存储中读，只要存储本身是可以复制同步过来。它允许本身就是一个集群的可以发往不同的节点。
Prometheus 可通过基于 gRPC 的适配器对接到远程存储
适配器主要处理里“读”和“写”两种数据操作，它们可分别通过不同的URL完成
（1）配置远程读存储
url.//读服务器的地址、端口等。最重要的一项。如果存储确实需要认证则提供一种方式即可。
[name:]//取域名[:…]//过滤数据[remote_timeout:|default=1m][read_recent:|default=false]//远程服务是否需要认证是否需要代理。[username:][password:][password_file:][bearer_token:][bearer_token_file:][][proxy_ult]
（2）配置远程写存储
除了与“读存储相同部分的配置参数外，还有这些专用配置参数
queue_config://要配置队列，因为远程服务比较慢。Prometheus请求很快，可以使用队列先暂存起来。
[capacity:|default=2500][max_shards:|default=200][min_shards:|default=1][max_samples_per_send:|default=500][batch_send_deadline:|default=5s][min_backoff:|default=30ms][max_backoff:|default=100ms][send:|default=true][send_interval|default=1m]
Prometheus 俨然就是一个分步式监控系统，各种功能都是以Prometheus solo 为中心辐射出去，各种第三方解决方案或者自己独立解决方案。最麻烦的地方在于alergen mange 可能会宕机，存储也有可能会宕机，对存储本身最好利用自己的功能做成集群的形式。例如三个节点做成的集群才是可用的。Prometheus 自己也应该做成集群，GRAFARA 也要多个。手动维护的话要组合的东西太多不容易操作，就算不使用 KMS 可以使用单机编排，若单机编排承载不了，就使用 KBS。这么多实例该如何部署，接下来讲解 Prometheus 集群。
三、Prometheus 集群
1、Prometheus Server 简单多实例
建立起多个 Prometheus Server，同时工作，共同收集同一组指标时
存在数据不一致的可能性；
特点：
不支持数据长期存储；
仅适用于小规模的系统环境；
所谓 Prometheus 集群就是为了提高可用性跑两个 Prometheus。两个Prometheus 共同监控同一组target。PrometheusA 有自己的TSDB，PrometheusB 也有自己的 TSDB，数据存储在本地，即使它们的抓取周期配置相同但启动时间点不一样也会导致抓取周期不同，二者数据很难完全相同。因此存在数据不一致的可能性。
Prometheus 每一个都在本地保存数据，意味着是有状态的，从这个角度讲 Prometheus 是有状态应用。也可以使用将有状态变成无状态的方式共享。
2、Prometheus 多实例共享同一远程存储
在前一种模型的基础上，为多个 PromethcusServer 添加一个共享的远程存储
支持数据的长期存储
Prometheus Server 恢复后能够快速恢复数据
仅适用于小规模的系统环境：
PrometheusA 和 PrometheusB 可以对接同一个远程存储。此时PrometheusA 与 PrometheusB 都直接把数据存到远端，此时对于proxy依然通过代理来访问，但因为 grafara
要展示数据源，而 Prometheus 本地没有数据， grafara支持多种数据源，通过inflax 可以直接在 3rd-party storage展示。即直接用inflaxDB 的查询接口展示即可。这样做解决了数据不一致的问题，还支持长期存储， PrometheusServer 恢复后能够快速恢复数据，但
仅适用于小规模的系统环境，因为单个 Prometheus 实例所支持的能够抓取的目标是有限的，这只是解决了存储问题而未解决扩展问题。
3、扩展 Prometheus
Prometheus Federation（Prometheus联邦）
设定多台 Promethcus Server，分别监控不同的 Target；
可基于地址位置、机房、业务等纬度来拆分监控对象；
设定一台主节点，来合开多个分片的 Prometheus Server 各自抓取的数据；
主节点使用 Prometheus federationAPI 进行数据合并；
主节点也 PrometheusGrafana 的数据源；
工作方式如上图：可以做多个 Prometheus，每个 Prometheus负责监控一组应用，很多个 MySQL 用一个专门的 Prometheus监控，并且这个 Prometheus 只监控 MySQL 。另一个 Prometheus 只负责监控 Node。显然一个只能展示 MySQL 的监控，另一个只能查询 Node 的监控数据。如果要期望他们合在一起进行展示查询，就需要通过 Federation 合并在一起被中央 Prometheus 统一存储。这是一种分布式逻辑，中央 Prometheus 不会去其他被监控服务器上抓取指标，而是到其他多个 Prometheus 上提取并合并指标。但这样一来每一组都需要提高可用性。
4、混合联邦模型与集群共享存储
多台 Prometheus 服务器分别监控不同的 Target ，而后使用两台或以上的 Prometheus Server 基于 FederationAPI 合并监控数据至共享的远程存储
能监控更具规模的系统环境，但部署复杂；
假设一个数据中心，因为系统是多机房的，数据中心中的每一个机房里面部署一个 Prometheus 作为合并房，合并一个机房中监控的多个不同指标。比如可以将 My SQL 和 Node 合并起来。合并起来后存储被中央全局 Prometheus 所抓取。抓取完后集中式放在 Ser-party storage 中。为了避免过于复制，没必要将每一级别都考虑的非常完整。
混合联邦模型与集群共享存储，既有可用性提升又有扩展模型。但如果手动组织过于困难。
5、Alertmanager 高可用
Gossip 协议
多 Alertmanager 实例的场景中，告警信息可能会被重复发送；
Gossip 机制可为多个 Alertanager 之间提供了信息传递的机制以确保在多个 Alertmanager 分别接收到相同告警信息的情况下，只会有一个告警通知被发送给 Receiver；
Gossip 是分布式系统中被广泛使用的协议，用于实现分布式节点之间的信息交换和状态同步；
Alertmanager 高可用比 Prometheus 高可用更加麻烦，如下图所示有两个 Prometheus Server，为了可用性配置了每个 Prometheus Server 都能使用两个 Alertmanager实例进行报警。但如果这两个 Alertmanager 都在正常工作，一个 Prometheus Server 触发一次告警后，两个 Alertmanager 同时给一个用户发告警是没有必要的，还会让用户更受困扰。两个 Alertmanager 可以认为在 Prometheus 组合的时候是有状态的，或者需要一次中央协调节点 leader,实在没有 leader 也可以使用中央协作机制，需要使用流言协议。
每一个节点拿到信息以后都会将一些信息尽可能让其他节点明白这个节点做过的事情，以确保其他节点不会重复发送告警，这是借助流言协议进行协作的。
当我们启动 Alertmanager 的时候。会有 gossip not settled的信息提示。因为在指定部署的时候只有一个 Alertmanager 所以没必要设定，但即便是设定了也无法发出。提示为gossipe settled:proceeding。因为只有一个实例，但多实例的 Alertmanager 必须要使用流言协议组织成集群，以确保同一个Prometheus Server 触发的告警不会被重复发送。
这是 Alertmanager 内置的一种功能，所以只要部署了Alertmanager 就可以使用该功能。
Gossip 是无状态的，但事实上也并非完全是无状态因为导入一个告警后它可能对一个 Gossip 有效，对另一个无效。
