时序数据库选型
采集器采集到数据之后，要推给时序数据库，接下来我们一起来看看时序数据库如何选型；
监控系统的架构中，最核心的就是时序库。老一些的监控系统直接复用关系型数据库；
Zabbix 直接使用 MySQL 存储时序数据，MySQL 擅长处理事务场景，没有针对时序场景做优化，容量上有明显的瓶颈。
Open-Falcon 是用 RRDtool 攒了一个分布式存储组件 Falcon-Graph，但是 RRDTool 本身的设计就有问题，散文件很多，对硬盘的 IO 要求太高，性能较差。Falcon-Graph 是分布式的，可以通过堆机器来解决大规模的问题，但显然不是最优解。后来，各种专门解决时序存储问题的数据库横空出世，比较有代表性的有：OpenTSDB、InfluxDB、TDEngine、M3DB、VictoriaMetrics、TimescaleDB 等。
1.OpenTSDB
OpenTSDB 2010 年出现，出现较早
OpenTSDB: 底层基于 HBase 封装的，后来发展有了基于 Cassandra 封装的版本。
缺点: 底层存储是基于 HBase 的，一般小公司都玩不转，在国内的受众相对较少，选型很少采用。
2.InfluxDB
InfluxDB 来自 InfluxData，是一个创业公司做的项目，2019 年 D 轮融资 6000 万美金，开发人员不担心养家糊口的问题，做的产品还是非常不错的。InfluxDB 针对时序存储场景专门设计了存储引擎、数据结构、存取接口，国内使用范围比较广泛，而且 InfluxDB 可以和 Grafana、Telegraf 等良好整合，生态是非常完备的。
缺点: InfluxDB 开源版本是单机的，没有开源集群版本; 存储容量和扩展性是个问题
3.TDEngine
国产开源版 InfluxDB，GitHub 的 Star 数上万
优点:
1.针对物联网设备的场景做了优化，性能很好，也可以和 Grafana、Telegraf 整合，对于偏设备监控的场景，TDEngine 是个不错的选择。
2.TDEngine 的集群版是开源的。
3.TDEngine 不止是做时序数据存储，还内置支持了流式计算，可以让用户少部署一些组件。
注意: TDEngine 支持 Prometheus 的 remote_read 和 remote_write 接口的。但不支持 Prometheus 的 Query 类接口；
3.M3DB
M3DB 是来自 Uber 的时序数据库，M3 声称在 Uber 抗住了 66 亿监控指标，这个量非常庞大。
优点: M3DB 是全开源的，包括集群版
缺点: M3DB架构比较复杂，CPU 和内存占用较高，在国内没有大规模推广起来。
4.VictoriaMetrics
VictoriaMetrics，简称 VM，架构非常简单清晰，采用 merge read 方式，避免了数据迁移问题，搞一批云上虚拟机，挂上云硬盘，部署 VM 集群，使用单副本，是非常轻量可靠的集群方式。VM 架构图如下
5.TimescaleDB
TimescaleDB 是 timescale.inc 开发的一款时序数据库，作为一个 PostgreSQL 的扩展提供服务。它是基于 PostgreSQL 设计而成的，而 PostgreSQL 生态四十年的积累，就是巨人的肩膀，很多底层的工作 PostgreSQL 其实已经完成了。就拿保障数据安全来说吧，因为程序可能随时会崩溃，服务器可能会遇到电源问题或硬件故障，磁盘可能损坏或者夯住，这些极端场景都需要完善的解决方案来处理。PostgreSQL 社区已经有了现成的高可用特性，包括完善的流复制和只读副本、数据库快照功能、增量备份和任意时间点恢复、wal 支持、快速导入导出工具等。而其他时序库，这些问题都要从头解决。但是传统数据库是基于 btree 做索引的，数据量到百亿或者千亿行，btree 会大到内存都存不下，产生频繁的磁盘交换，数据库性能会显著下降。另外，时序数据的写入量特别大，PostgreSQL 面对大量的插入，性能也不理想。TimescaleDB 就要解决这些问题。目前 Zabbix 社区在尝试对接到 TimescaleDB，
缺点: TimescaleDB国内应用案例还比较少。
6.Prometheus-云原生监控领域事实标准
1.云原生生态支持较好 K8S
2.周边生态繁荣: Grafana展示/AlertManager告警打通； Exporter采集器生态较为丰富完善
Pushgateway：用于接收短生命周期任务的指标上报，是 PUSH 的接收方式。因为 Prometheus 主要是 PULL 的方式拉取监控数据，这就要求在拉取的时刻，监控对象得活着，但是很多短周期任务，比如 cronjob，可能半秒就运行结束了，就没法拉取了。为了应对这种情况，才单独做了 Pushgateway 组件作为整个生态的补充。
Service discovery：我们演示抓取数据时，是直接在 prometheus.yml 中配置的多个 Targets。这种方式虽然简单直观，但是也有弊端，典型的问题就是如果 Targets 是动态变化的，而且变化得比较频繁，那就会造成管理上的灾难。所以 Prometheus 提供了多种服务发现机制，可以动态获取要监控的目标，比如 Kubernetes 的服务发现，可以通过调用 kube-apiserver 动态获取到需要监控的目标对象，大幅降低了抓取目标的管理成本。
如果规模比较小，1000 台机器以下，通常一个单机版本的 Prometheus 就够用了。如果规模再大一些，建议你考虑 VictoriaMetrics，毕竟架构简单，简单的东西可能不完备，但是出了问题容易排查，更加可控。
注: Thanos、M3DB、VictoriaMetrics 都直接兼容 Prometheus 的 Query 类接口，上层程序可以把这些时序库当做 Prometheus 来使用。
