自从上了 Prometheus 监控，睡觉真香！

发表于 3年以前 | 总阅读数：445 次

对很多人来说，未知、不确定、不在掌控的东西，会有潜意识的逃避。

当我第一次接触 Prometheus 的时候也有类似的感觉。对初学者来说， Prometheus 包含的概念太多了，门槛也太高了。

概念：Instance、Job、Metric、Metric Name、Metric Label、Metric Value、Metric Type（Counter、Gauge、Histogram、Summary）、DataType（Instant Vector、Range Vector、Scalar、String）、Operator、Function

马云说：“虽然阿里巴巴是全球最大的零售平台，但阿里不是零售公司，是一家数据公司”。

Prometheus 也是一样，本质来说是一个基于数据的监控系统。

日常监控

假设需要监控 WebServerA 每个API的请求量为例，需要监控的维度包括：服务名（job）、实例IP（instance）、API名（handler）、方法（method）、返回码(code)、请求量（value）。

如果以SQL为例，演示常见的查询操作：

查询 method=put 且 code=200 的请求量(红框)

SELECT * from http_requests_total WHERE code=”200” AND method=”put” AND created_at BETWEEN 1495435700 AND 1495435710;

查询 handler=prometheus 且 method=post 的请求量(绿框)

SELECT * from http_requests_total WHERE handler=”prometheus” AND method=”post” AND created_at BETWEEN 1495435700 AND 1495435710;

查询 instance=10.59.8.110 且 handler 以 query 开头的请求量(绿框)

SELECT * from http_requests_total WHERE handler=”query” AND instance=”10.59.8.110” AND created_at BETWEEN 1495435700 AND 1495435710;

通过以上示例可以看出，在常用查询和统计方面，日常监控多用于根据监控的维度进行查询与时间进行组合查询。另外，关注公众号Java技术栈，在后台回复：面试，可以获取我整理的最新Java系列面试题和答案。

如果监控100个服务，平均每个服务部署10个实例，每个服务有20个API，4个方法，30秒收集一次数据，保留60天。那么总数据条数为：100(服务) 10（实例） 20（API） 4（方法） 86400（1天秒数）* 60(天) / 30（秒）= 138.24 亿条数据，写入、存储、查询如此量级的数据是不可能在Mysql类的关系数据库上完成的。

因此 Prometheus 使用 TSDB 作为存储引擎。

存储引擎

TSDB 作为 Prometheus 的存储引擎完美契合了监控数据的应用场景：

那么 TSDB 是怎么实现以上功能的呢？

"labels": [{
    "latency":        "500"
}]
"samples":[{
    "timestamp": 1473305798,
    "value": 0.9
}]

原始数据分为两部分 label, samples。前者记录监控的维度（标签:标签值），指标名称和标签的可选键值对唯一确定一条时间序列（使用 series_id 代表）；后者包含包含了时间戳（timestamp）和指标值（value）。

series
^
│. . . . . . . . . . . .   server{latency="500"}
│. . . . . . . . . . . .   server{latency="300"}
│. . . . . . . . . .   .   server{}
│. . . . . . . . . . . . 
v
<-------- time ---------->

TSDB 使用 timeseries:doc:: 为 key 存储 value。为了加速常见查询查询操作：label 和时间范围结合。

TSDB 额外构建了三种索引：Series, Label Index 和 Time Index。

以标签 latency 为例：

Series