tombstones 时序数据库连载系列：指标届的独角兽Prometheus

简介

普罗米修斯是SoundCloud公司开发的一站式监控报警平台，依赖性小，功能齐全。

2016年加入CNCF，广泛应用于库伯内特集群监控系统。2018年8月，成为K8S之后的第二个毕业设计。普罗米修斯作为CNCF生态系统中的重要成员，其活动量仅次于库伯内特。

关键功能包括： 多维数据模型：metric，labels灵活的查询语言：PromQL， 在同一个查询语句，可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。可独立部署，拆箱即用，不依赖分布式存储通过Http pull的采集方式通过push gateway来做push方式的兼容通过静态配置或服务发现获取监控项支持图表和dashboard等多种方式

核心组件:

Prometheus Server： 采集和存储时序数据client库： 用于对接 Prometheus Server, 可以查询和上报数据push gateway处理短暂任务：用于批量，短期的监控数据的汇总节点，主要用于业务数据汇报等定制化的exporters,比如：HAProxy， StatsD，Graphite等等， 汇报机器数据的插件告警管理：Prometheus 可以配置 rules，然后定时查询数据，当条件触发的时候，会将 alert 推送到配置的 Alertmanager多种多样的支持工具

优点和缺点:

同InfluxDB相比, 在场景方面：PTSDB 适合数值型的时序数据。不适合日志型时序数据和用于计费的指标统计。InfluxDB面向的是通用时序平台，包括日志监控等场景。而Prometheus更侧重于指标方案。两个系统之间有非常多的相似之处，包括采集，存储，报警，展示等等Influxdata的组合有：telegraf+Influxdb+Kapacitor+ChronografPromethues的组合有：exporter+prometheus server+AlertManager+Grafana采集端prometheus主推拉的模式，同时通过push gateway支持推的模式。influxdata的采集工具telegraf则主打推的方式。存储方面二者在基本思想上相通，关键点上有差异包括：时间线的索引，乱序的处理等等。数据模型上Influxdb支持多值模型，String类型等，更丰富一些。Kapacitor 是一个混合了 prometheus 的数据处理,存储规则,报警规则以及告警通知功能的工具.而AlertManager进一步提供了分组,去重等等。influxdb之前提供的cluster模式被移除了，现在只保留了基于relay的高可用，集群模式作为商业版本的特性发布。prometheus提供了一种很有特色的cluster模式，通过多层次的proxy来聚合多个prometheus节点实现扩展。同时开放了remote storage，因此二者又相互融合，Influxdb作为prometheus的远端存储。OpenTSDB 的数据模型与Prometheus几乎相同，查询语言上PromQL更简洁，OpenTSDB功能更丰富。OpenTSDB依赖的是Hadoop生态,Prometheus成长于Kubernetes生态。

数据模型

采用单值模型, 数据模型的核心概念是metric,labels和samples.格式：<metric name>{<label name>=<label value>, …}例如：http_requests_total{method="POST",endpoint="/api/tracks"}。metric的命名具有业务含义，比如http_request_total.指标的类型分为：Counter， Gauge，Historgram，Summarylabels用于表示维度.Samples由时间戳和数值组成。jobs and instancesPrometheus 会自动生成target和instances作为标签job: api-serverinstance 1: 1.2.3.4:5670instance 2: 1.2.3.4:5671

整体设计理念

墓石

记录通过标记删除，数据的物理清除发生在压缩和重新加载时。已删除记录的信息以时间窗口为单位存储。

查询PromQL

Promethues的查询语言是PromQL，解析AST。执行计划和数据汇总由PromQL完成。扇出模块将向本地和远程发送查询数据，PTSDB负责本地数据的检索。

PTSDB实现定义的Adpator，包括Select、LabelNames、LabelValues和Querier。

PromQL定义了三种类型的查询:

即时向量:它包含一组时间序列，每个时间序列只有一个点，例如:http_requests_total

范围向量:包含一组时间序列，每个时间序列有多个点，例如:http_requests_total[5m]

标量:标量只有一个数字，没有时间序列，例如:计数(http_requests_total)

一些典型的查询包括:

查询当前所有数据http_requests_totalselect * from http_requests_total where timestamp between xxxx and xxxx条件查询http_requests_total{code="200", handler="query"}select * from http_requests_total where code="200" and handler="query" and timestamp between xxxx and xxxx模糊查询: code 为 2xx 的数据http_requests_total{code~="20"}select * from http_requests_total where code like "%20%" and timestamp between xxxx and xxxx值过滤： value大于100http_requests_total > 100select * from http_requests_total where value > 100 and timestamp between xxxx and xxxx范围区间查询: 过去 5 分钟数据http_requests_total[5m]select * from http_requests_total where timestamp between xxxx-5m and xxxxcount 查询: 统计当前记录总数count(http_requests_total)select count(*) from http_requests_total where timestamp between xxxx and xxxxsum 查询：统计当前数据总值sum(http_requests_total)select sum(value) from http_requests_total where timestamp between xxxx and xxxxtop 查询: 查询最靠前的 3 个值topk(3, http_requests_total)select * from http_requests_total where timestamp between xxxx and xxxx order by value desc limit 3irate查询：速率查询irate(http_requests_total[5m])select code, handler, instance, job, method, sum(value)/300 AS value from http_requests_total where timestamp between xxxx and xxxx group by code, handler, instance, job, method;

PTSDB的技术要点

无序处理

PTSDB采用最小时间窗的方法处理无序，并规定了法定的最小时间戳。小于此时间戳的数据将被丢弃，不再处理。

合法的最小时间戳取决于当前头块中最早的时间戳和可存储的块范围。

数据行为的这种限制大大简化了设计的灵活性，并为高效处理和数据完整性提供了基础。

内存管理

用mmap读取压缩合并后的大文件(不占用太多句柄)，

建立进程的虚拟地址与文件偏移量的映射关系，只有查询读取对应位置时，数据才真正读入物理内存。

绕过了文件系统页面缓存，减少了一个数据副本。

查询完成后，相应的内存由Linux系统根据内存压力自动回收，可以用于回收前的下一次查询命中。

因此，使用mmap自动管理查询所需的内存缓存，具有管理简单、效率高的优点。

压缩

压缩的主要操作包括合并块、删除过期数据和重建块数据。

合并多个block成为更大的block，可以有效减少block个，当查询覆盖的时间范围较长时，避免需要合并很多block的查询结果。为提高删除效率，删除时序数据时，会记录删除的位置，只有block所有数据都需要删除时，才将block整个目录删除。block合并的大小也需要进行限制，避免保留了过多已删除空间(额外的空间占用)。比较好的方法是根据数据保留时长，按百分比（如10%）计算block的最大时长, 当block的最小和最大时长超过2/3blok范围时，执行compaction

快照

PTSDB提供快照备份数据的功能。用户可以通过管理/快照协议生成快照，快照数据存储在数据/快照/-目录中。

PTSDB最佳实践 在一般情况下，Prometheus中存储的每一个样本大概占用1-2字节大小。如果需要对Prometheus Server的本地磁盘空间做容量规划时，可以通过以下公式计算：needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample保留时间(retention_time_seconds)和样本大小(bytes_per_sample)不变的情况下，如果想减少本地磁盘的容量需求，只能通过减少每秒获取样本数(ingested_samples_per_second)的方式。因此有两种手段，一是减少时间序列的数量，二是增加采集样本的时间间隔。考虑到Prometheus会对时间序列进行压缩，因此减少时间序列的数量效果更明显。PTSDB的限制在于集群和复制。因此当一个node宕机时，会导致一定窗口的数据丢失。当然，如果业务要求的数据可靠性不是特别苛刻，本地盘也可以存储几年的持久化数据。当PTSDB Corruption时，可以通过移除磁盘目录或者某个时间窗口的目录恢复。PTSDB的高可用，集群和历史数据的保存可以借助于外部解决方案，不在本文讨论范围。历史方案的局限性，PTSDB在早期采用的是单条时间线一个文件的存储方式。这中方案有非常多的弊端，比如：Snapshot的刷盘压力：定期清理文件的负担；低基数和长周期查询查询，需要打开大量文件；时间线膨胀可能导致inode耗尽。PTSDB面临的挑战

在使用过程中，PTSDB在某些方面也遇到了一些问题，比如；

Compaction对于IO, CPU, 以及Memory的影响冷启动后，预热阶段CPU和内存占用会上升在高速写入时会出现CPU的Spike等等总结

作为K8S监控方案中存储时间序列数据的实施标准，PTSDB在时间序列中的影响力和普及度也在逐渐提高。目前，阿里巴巴TSDB已经支持适配器作为其远程存储方案。

本文是云起社区的原始内容，未经许可不得转载。