prometheus按指标名称（metrics name）和一组相应的标签（labelset）唯一定义时间序列。 指标名称反映了监控样本的基本标识，标签为采集到的关于该基本特征的数据提供了多种特征维度。 用户可以根据这些特征维度进行筛选、聚合和计数，以生成新的计算时间序列。
promql是的prometheus内置的数据查询语言支持对时序数据进行丰富的查询、聚合和逻辑操作。 它广泛用于：prometheus在日常应用中，包括数据查询、可视化和告警处理。 可以这么说promql是的prometheus基础知识，理解和掌握所有应用场景promql是的prometheus开始的第一课。
promql学习的是我们prometheus最困难和最重要的部分，我们将在本节中介绍promql基础知识、理论基础，然后更深入地了解更高级的查询模式。
执行
什么时候prometheus当它从系统和服务收集指标数据时，它会将数据存储在内置的时间序列数据库中（tsdb），我们可以对收集到的数据进行任何处理promql从tsdb，您可以对所选数据执行筛选、聚合和其他转换操作。
promql可以通过两种方式触发执行：
在prometheus服务器记录规则跟警报规则它定期运行，并执行查询操作来计算规则结果（例如触发警报）。执行在prometheus在服务内部发生，并在配置规则时自动发生。 外部用户和ui界面已准备就绪prometheus提供的服务http api执行promql询问。 这就是仪表板软件（例如grafanapromlens和prometheus内置web ui访问promql道路。
http api场景promql它可以用于许多监控场景，下面简单介绍一些相关案例。
即席查询：最常用，用于日常调试和诊断，验证表达式的正确性也很有用。
我们可以使用它promql对采集到的数据进行实时查询，这有助于我们调试和诊断遇到的一些问题，我们一般直接使用内置的表达式查询接口来执行这样的查询
Dashboard：自定义监控面板时需要用到，所以需要熟悉。
同样，我们也可以基于：promql用于创建可视化图形（如面板）的查询是目前使用最广泛的方法grafana
grafana原生支持prometheus作为数据源，以及内置支持promql查询的表达式。
告警：在对我们关注的服务进行告警时，需要使用告警触发规则，这一点尤为重要。
prometheus您可以直接根据promql对采集到的数据进行查询的结果用于生成告警，完整的告警规则如下：
groups: -name: demo-service-alerts rules: -alert: many5xxerrors expr: |sum by(path, instance, job) (rate(demo_api_request_duration_seconds_count[1m]) / sum by(path, instance, job) (rate(demo_api_request_duration_seconds_count[1m]) 100 > 0.5 ) for: 30s labels: severity: critical annotations: title: '} high 5xx rate on }' description: 'the 5xx error rate for path } on } is }%'然后prometheus这可以通过一个名为alertmanager可以配置一些接收器来接收这些告警，比如钉钉来接收告警
自动化：根据监控查询的结果自定义自动化流程。
此外，我们还可以为以下方面构建自动化流程：promql执行查询结果以做出决策，例如：kubernetes基于自定义指标的水平自动缩放对象hpa
数据模型
prometheus从本质上讲，所有数据都存储为时间序列：属于同一数据指标和同一组标记维度的带时间戳的数据流。 除了存储的时间序列外，prometheus查询的结果可能会生成临时派生的时间序列。 下图说明了基本数据模型关系图：
每个时间序列都由它决定名字并称为标签自选键值对是唯一标识的
指示器名称指定被监控系统的一般功能（例如HTTP 请求总数 - 收到的 HTTP 请求总数)。它可能包含：ASCII 字符、数字下划线和冒号。它必须能够用正则表达式表示[a-za-z_:]a-za-z0-9_:]匹配。
注意：冒号是为用户定义的规则保留的。 它们不应由导出器使用或直接显示的组件。标签可以制作标签prometheus支持多维数据模型：具有相同数据指标名称的任何给定标签组合都可以标识该数据指标的特定维度实例（例如，使用post通向/api/tracks所有处理程序http请求）。查询语言允许基于这些维度进行筛选和聚合。 更改任何标记值（包括添加或删除）都会创建新的时间序列。
标签名称可以包含：ASCII 字符、数字和下划线。它必须能够用正则表达式表示[a-za-z_:]a-za-z0-9_:]匹配。 自开头的标签名称保留供内部使用。
标记值可以包含任何 Unicode 字符。
具有空白标记值的标签被视为等同于不存在的标记。
数据样本
数据样本构成实际的时间序列数据。 每个数据示例包括：
64 位浮点数值毫秒精度的时间戳时间序列
prometheus所有收集的样本数据都以时间序列格式存储内存数据库并定期保存到硬盘。 时间序列存储在一系列时间戳和值中，我们称之为向量（vector），每个时间序列按指标名称（metrics name）和一组标记集（labelset）命名。 如下图所示，时间序列可以理解为时间序列x轴的数字矩阵：
^ │node_cpu_seconds_total │ node_cpu_seconds_total │ node_load1{} v度量：指标的名称和描述当前样本特征的标签集合时间戳：精确到毫秒的时间戳示例值：float64 float 表示当前样本的值它看起来像这样：
value->http_request_total@1434417560938 => 94355http_request_total@1434417561287 => 94334http_request_total@1434417560938 => 38473http_request_total@1434417561287 => 38544http_request_total@1434417560938 => 4748http_request_total@1434417561287 => 4785类型
每一个都是不同的指标名称和标签组合均称为时间序列在prometheus表达式语言中的表达式或子表达式包括以下四种类型之一：
即时矢量：一组时间序列，每个时间序列包含一个样本，它们共享相同的时间戳。 也就是说，表达式的返回值将仅包含时间序列中最新的样本值。 相应的此类表达式称为瞬时向量表达式。 范围向量：一组时间序列，每个时间序列包含一段时间内的样本数据，这些数据是瞬时向量（例如[5m]5 分钟）。标量：一个简单的数值浮点值。 字符串：一个简单的字符串值。 所有这些指标都是：prometheus定期从metrics接口收集在那里。 采集之间的间隔由以下公式设置：prometheus.yml配置scrape_interval指定。 最大爬网间隔为秒，这意味着至少每秒将有一个带有新时间戳记录的新数据点，此值可能会或可能不会更改，但每隔一段时间就会更改一次scrape_interval将生成一个新的数据点。
指标类型
在存储方面，所有监控指标都是相同的，但在不同场景下，这些指标存在一些细微的差异。 例如，在node exporter示例中返回的指标node_load1它反映了系统的当前负载状态，并且该指标返回的样本数据随时间不断变化。 和指标node_cpu_seconds_total获得的样本数据是不同的，它是一个不断增加的值，因为它反映了cpu从理论上讲，只要系统不关闭，这个数值就会继续增加。
为了帮助用户了解和区分这些不同监控指标之间的差异prometheus定义了 4 种不同的指标类型：计数器仪表（仪表盘）。直方图总结
在node_exporter（稍后会详细介绍）在返回的样本数据中，注释还包括counter。例如：
# help node_cpu_seconds_total seconds the cpus spent in each mode.# type node_cpu_seconds_total **counter**node_cpu_seconds_total 7.840379222e+07node_cpu_seconds_total 302235.3不要使用计数器来显示可以减少的值。例如：不要使用counter指示当前正在运行的进程数，并改用该进程数gauge鉴于。
您可能认为不断增加的数据是无用的，但是从一开始就知道服务有多少请求有什么价值吗？但请记住，每个指标都有一个为您的所有指标存储的时间戳http现在可以增加请求数1000万但prometheus上一个时间点的值也会被记录下来，我们可以查询到最近一个小时的请求数，当然更多的时候，我们希望看到它请求数增加或减少的速度，所以通常的情况是counter指标都是供我们查看的变化率而不是数字本身。 promql内置聚合操作和函数用户可以进一步分析这些数据，例如，通过rate()功能获取http请求增长率：
rate(http_requests_total[5m])跟counter不同gauge（可扩展或可减）类型的指标侧重于反应系统的当前状态，因此此类指标的样本数据它可以增加或减少。常见指标，例如：node_memory_memfree_bytes（主机上当前可用的内存量），node_memory_mem**ailable_bytes（可用内存量）。gauge监控指标的类型。 由于gauge指标仍然有一个时间戳存储，我们能看到的所有随时间变化的值通常都可以直接绘制出来，这样我们就可以看到值本身，而不是变化率，通过gauge指标，用户可以直接查看系统的当前状态。
不过，这些简单的指标类型都只是为每个样本获得一个数字prometheus力量在于你如何跟踪它们，就像我们画了两张图，一张是http请求的变化率，另一个是分配的gauge实际内存的类型，直接从图中可以看出两者之间存在相关性当请求激增时，内存使用量也会激增，但如果我们仔细观察，我们也会发现，在峰值之后，内存使用率并没有恢复到峰值之前的水平，而是整体上逐渐增加，说明很可能在应用程序中内存泄漏这些简单的指标可以帮助我们发现这些可能的问题。
为gauge监控指标类型，已通过promql内置函数delta()您可以了解样本随时间的变化情况。 例如，计算cpu两小时内的温差：
delta(cpu_temp_celsius[2h])predict_linear(node_filesystem_free_bytes[1h], 4 * 3600)在大多数情况下，人们倾向于使用它某些定量指标的平均值例如：平均 CPU 使用率、页面的平均响应时间这样一来，系统也存在明显的问题api呼叫的平均响应时间是一个示例：如果大多数api请求得到维护100ms在响应时间范围内，而单个请求所需的响应时间5s，那么它会导致一些web页面响应时间下降中位数on，这种现象称为长尾问题
为了区分它是平均慢还是长尾慢最简单的方法是遵循它对请求延迟的范围进行分组。例如，统计延迟在0~10ms有多少个请求10~20ms以及发出了多少请求。 这样，就可以快速分析系统运行缓慢的原因。 histogram跟summary所有这些都是为了能够解决这样的问题而存在的，通过histogram跟summary我们可以快速了解监测样本的分布情况。
summary对观测值（通常为请求持续时间和响应大小等数据）进行采样。 它不仅提供观测值的总数和所有观测值的总和，而且还计算滑动时间窗口内的可配置分位数。
基础数据指标名称如下之summary键入数据指标，该指标在数据收集期间显示多个时间序列：
观察到的事件流φ-quantiles(0≤φ≤1)，显示为在所有观测值中和，显示为_sum观察到的事件计数，显示为_count（phi） 是summary类型中的一个参数，表示分位数。 取值范围如下：自，表示分位数的位置。
summary用于记录某些内容平均大小，可能是计算所需的时间或正在处理的文件的大小summary将显示两条相关消息：count（事件发生的次数）和sum（所有事件的总大小），如下图计算，汇总指标可以返回次数为3，总和为15，这意味着计算总数是必需的15s平均而言，要处理每次计算5s。下一个示例的次数为：，总结，则平均值为，因为两组指标都记录有时间戳，所以我们可以使用它们summary构建显示平均值变化率的图形，例如图形上的语句一分钟时间段内的平均速率。
例如，指标prometheus_tsdb_wal_fsync_duration_seconds指标类型为：summary，它记录了prometheus server中等wal_fsync处理时间，按访问方式prometheus server之/metrics地址，可以获取以下监控示例数据：
# help prometheus_tsdb_wal_fsync_duration_seconds duration of wal fsync.# type prometheus_tsdb_wal_fsync_duration_seconds summaryprometheus_tsdb_wal_fsync_duration_seconds 0.012047795prometheus_tsdb_wal_fsync_duration_seconds 0.012047795prometheus_tsdb_wal_fsync_duration_seconds 0.012047795prometheus_tsdb_wal_fsync_duration_seconds_sum 53.40982735799987prometheus_tsdb_wal_fsync_duration_seconds_count 4563histogram观测值（通常是请求持续时间或响应大小等数据）以可配置的数字间隔进行采样和计数。 它还提供所有数据的总和。
基础数据指标名称如下之histogram数据指标，在数据收集过程中显示多个时间序列：
数值间隔的累积计数器显示为_bucket所有观测值的总和，显示为：_sum计数的事件计数显示如下：_count（同上）_bucket相同）虽然summary非常有用，但平均值会隐藏一些细节，在上图中跟总和的范围非常广泛，如果我们想看看花了多少时间，那么我们需要一个直方图。 直方图转换为bucketbucket 表单来记录数据，因此我们可能有一个 bucket 来满足需求1s或更少的计算，另一个桶用于5s或更少10s或更少20s或更少60s或更少指标返回每个存储桶的计数，其中 3 个在5s或在更短的时间内完成，6 英寸10s或在更短的时间内。 prometheus中的直方图是累积，所以所有 10 个计算都属于60s或更短的时间段，在这 10 次中，有 9 次有处理时间20s或更少，显示数据的分布。 所以你可以看到，我们的大部分计算都在10s下面，只有一个超出20s，这对于计算百分位数很有用。 它看起来像这样：
在prometheus server在本身返回的示例数据中，我们还可以找到类型为histogram的监控指标。
# help prometheus_tsdb_compaction_chunk_range_seconds final time range of chunks on their first compaction# type prometheus_tsdb_compaction_chunk_range_seconds histogramprometheus_tsdb_compaction_chunk_range_seconds_bucket 28240prometheus_tsdb_compaction_chunk_range_seconds_bucket 28240prometheus_tsdb_compaction_chunk_range_seconds_bucket 28240prometheus_tsdb_compaction_chunk_range_seconds_bucket 28240prometheus_tsdb_compaction_chunk_range_seconds_bucket 317534prometheus_tsdb_compaction_chunk_range_seconds_bucket 3.380749e+06prometheus_tsdb_compaction_chunk_range_seconds_bucket 3.559075e+06prometheus_tsdb_compaction_chunk_range_seconds_bucket 4.128665e+06prometheus_tsdb_compaction_chunk_range_seconds_bucket 8.19135613e+08prometheus_tsdb_compaction_chunk_range_seconds_bucket 8.62465566e+08prometheus_tsdb_compaction_chunk_range_seconds_bucket 8.62465566e+08prometheus_tsdb_compaction_chunk_range_seconds_sum 1.778631422788386e+15prometheus_tsdb_compaction_chunk_range_seconds_count 8.62465566e+08参考**。