简介
Prometheus是SoundCloud公司开发的一站式监控告警平台，依赖少，功能齐全。于2016年加入CNCF，广泛用于 Kubernetes集群的监控系统中，2018.8月成为继K8S之后第二个毕业的项目。Prometheus作为CNCF生态圈中的重要一员,其活跃度仅次于 Kubernetes。关键功能包括：
多维数据模型：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整体设计思路
Prometheus的整体技术架构可以分为几个重要模块： Main function：作为入口承担着各个组件的启动，连接，管理。以Actor-Like的模式协调组件的运行
Configuration：配置项的解析，验证，加载Scrape discovery manager：服务发现管理器同抓取服务器通过同步channel通信，当配置改变时需要重启服务生效。Scrape manager：抓取指标并发送到存储组件Storage：Fanout Storage：存储的代理抽象层，屏蔽底层local storage和remote storage细节，samples向下双写，合并读取。Remote Storage：Remote Storage创建了一个Queue管理器，基于负载轮流发送，读取客户端merge来自远端的数据。Local Storage：基于本地磁盘的轻量级时序数据库。PromQL engine：查询表达式解析为抽象语法树和可执行查询，以Lazy Load的方式加载数据。Rule manager：告警规则管理Notifier：通知派发管理器Notifier discovery：通知服务发现Web UI and API：内嵌的管控界面，可运行查询表达式解析，结果展示。PTSDB概述本文侧重于Local Storage PTSDB的解析. PTSDB的核心包括：倒排索引+窗口存储Block。数据的写入按照两个小时为一个时间窗口，将两小时内产生的数据存储在一个Head Block中，每一个块中包含该时间窗口内的所有样本数据(chunks)，元数据文件(meta.json)以及索引文件(index)。最新写入数据保存在内存block中， 2小时后写入磁盘。后台线程把2小时的数据最终合并成更大的数据块，一般的数据库在固定一个内存大小后，系统的写入和读取性能会受限于这个配置的内存大小。而PTSDB的内存大小是由最小时间周期，采集周期以及时间线数量来决定的。为防止内存数据丢失，实现wal机制。删除记录在独立的tombstone文件中。核心数据结构和存储格式
PTSDB的核心数据结构是HeadAppender，Appender commit时wal日志编码落盘，同时写入head block中。
PTSDB本地存储使用自定义的文件结构。主要包含：WAL，元数据文件，索引，chunks，tombstones
当日志写入时，以segment为单位存储，每个segment默认128M, 记录数大小达到32KB页时刷新一次。当剩余空间小于新的记录数大小时，创建新的Segment。
当compation时WAL基于时间执行清除策略，小于内存中block的最小时间的wal日志会被删除。重启时，首先打开最新的Segment，从日志中恢复加载数据到内存。
元数据文件meta.json文件记录了Chunks的具体信息, 比如新的compactin chunk来自哪几个小的chunk。 这个chunk的统计信息，比如：最小最大时间范围，时间线，数据点个数等等compaction线程根据统计信息判断该blocks是否可以做compact：（maxTime-minTime）占整体压缩时间范围的50%， 删除的时间线数量占总体数量的5%。 
Symbols存储的是tagk, tagv按照字母序递增的字符串表。比如__name__,go_gc_duration_seconds, instance, localhost:9090等等。字符串按照utf8统一编码。
Series存储了两部分信息，一部分是标签键值对的符号表引用；另外一部分是时间线到数据文件的索引，按照时间窗口切割存储数据块记录的具体位置信息，因此在查询时可以快速跳过大量非查询窗口的记录数据，为了节省空间，时间戳范围和数据块的位置信息的存储采用差值编码。LabelIndex存储标签键以及每一个标签键对应的所有标签值，当然具体存储的数据也是符号表里面的引用值。Posting存储倒排的每个label对所对应的posting refidOffsetTable加速查找做的一层映射，将这部分数据加载到内存。OffsetTable主要关联了LabelIndex和Posting数据块。TOC是各个数据块部分的位置偏移量，如果没有数据就可以跳过查找。
Chunks数据点存放在chunks目录下，每个data默认512M，数据的编码方式支持XOR，chunk按照refid来索引，refid由segmentid和文件内部偏移量两个部分组成。 
PromQL定义了三类查询：
瞬时数据 (Instant vector): 包含一组时序，每个时序只有一个点，例如：http_requests_total区间数据 (Range vector): 包含一组时序，每个时序有多个点，例：http_requests_total[5m]纯量数据 (Scalar): 纯量只有一个数字，没有时序，例如：count(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对于乱序的处理采用了最小时间窗口的方式，指定合法的最小时间戳，小于这一时间戳的数据会丢弃不再处理。合法最小时间戳取决于当前head block里面最早的时间戳和可存储的chunk范围。这种对于数据行为的限定极大的简化了设计的灵活性，对于compaction的高效处理以及数据完整性提供了基础。内存的管理
使用mmap读取压缩合并后的大文件（不占用太多句柄），建立进程虚拟地址和文件偏移的映射关系，只有在查询读取对应的位置时才将数据真正读到物理内存。绕过文件系统page cache，减少了一次数据拷贝。查询结束后，对应内存由Linux系统根据内存压力情况自动进行回收，在回收之前可用于下一次查询命中。因此使用mmap自动管理查询所需的的内存缓存，具有管理简单，处理高效的优势。Compaction
Compaction主要操作包括合并block、删除过期数据、重构chunk数据。合并多个block成为更大的block，可以有效减少block个，当查询覆盖的时间范围较长时，避免需要合并很多block的查询结果。
为提高删除效率，删除时序数据时，会记录删除的位置，只有block所有数据都需要删除时，才将block整个目录删除。block合并的大小也需要进行限制，避免保留了过多已删除空间(额外的空间占用)。比较好的方法是根据数据保留时长，按百分比（如10%）计算block的最大时长, 当block的最小和最大时长超过2/3blok范围时，执行compaction快照PTSDB提供了快照备份数据的功能，用户通过admin/snapshot协议可以生成快照，快照数据存储于data/snapshots/-目录。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等等总结PTSDB 作为K8S监控方案里面存储时序数据的实施标准，其在时序届影响力和热度都在逐步上升。Alibaba TSDB目前已经支持通过Adapter的方式作为其remote storage的方案。