快速入门

监控基本慨念

什么是监控

监控就是持续不间断地对系统或服务进行监视，以确保我们的系统或服务一直处于正常运行的状态。

当然要想保证系统时刻处于监控的状态，我们需要配置对应的监控策略，便于我们及时检测到系统中可能出现的各种问题，如cpu使用率激增、内存耗尽或磁盘空间不足等。
当这些问题被发现时，监控系统可以警告通知我们，这样我们就可以快速接入，而后对出现的问题进行诊断和解决，从而保证系统的稳定性和可靠性。

同时，监控在整个运维过程、以及整个产品生命周期中都非常重要，它具有以下几个特性：

1. 事前预警：监控能够在故障发生前发出警报，帮助我们提前发现问题，规避问题。
   例如，我们设定了当内存使用率超过80%时，就触发告警。一旦达到阈值，监控系统会通过邮件、微信、钉钉、飞书、如流、短信等媒介，发送告警通知。
   这样，相关人员可以及时接入，进行故障处理，避免因内存耗尽导致系统奔溃，从而有效地降低故障率。

2. 事后追溯：利用监控获取到的数据，来快速分析故障所产生的原因。
   例如，当网站服务出现反应迟钝时，我们可以对一些关键指标数据进行分析，如数据库查询的延迟、cpu负载、磁盘i/o等等。这些异常变动可能就是引发问题的关键线索。有了这样的线索后，我们能更迅速地追查和定位问题。

3. 趋势分析：根据监控指标返回的数据，我们可以了解到系统性能和资源使用的变化趋势。基于这些数据，我们可以预测未来可能出现的问题。
   例如，我们有一个1TB的硬盘，通过监控，发现每天的数据增量约为30GB。
   那么在这种情况下，我们就可以利用趋势分析来预测硬盘会在何使满载。
   通过简单的计算就能得出，硬盘大约在33天后被填满。
   这样分析的信息极其有用，因为我们可以提前采取行动，例如，提前清理无用的数据，或者增加更多的存储空间，以防止硬盘被填满。

4. 对比分析：通过对比不同时间段下的监控数据，分析系统在不同的情况下的表现。
   例如，网站在正常工作日，每分钟处理100次交易。但在周末或大促期间，交易量可能飙升至每分钟1000次。这种激增可能导致系统响应缓慢，数据库查询效率下降，甚至页面加载延迟。
   在这种情况下，我们可以比对这两个时间段的数据，详细观察系统在高交易量时的负载表现，分析问题可能出在哪里，是数据库延迟，服务器资源不足，还是代码执行效率低下。有了这些具体信息，我们就能针对性地采取优化措施，例如，提升数据库查询效率，增加服务器资源，或优化代码等，以提升系统性能，并保证其稳定运行。

5. 数据可视化：将数据以图形的方式展示，使我们能够更容易地了解系统的当前状态和性能。
   例如：我们可以通过可视化工具生成的动态图标，来实现展示集群的负载、内存的使用、硬盘i/o等关键指标。
   这些直观的图形使我们能够洞察到系统状态的变化和趋势。同时数据可视化以图形的方式提供了比数据更清晰、更易理解的信息，极大地提高了我们分析性能指标的效率，从而加强了故障排查和性能优化的能力。

总之，监控是用来确保系统稳定、高效运行的关键手段，它帮助我们提前发现问题、定位问题，以及解决问题。

监控的目标

在复杂的IT环境中，我们需要监控的目标非常之多，如：硬件、网络设施、操作系统、应用程序以及相关的业务等。为了帮助我们更有效地进行监控，我们将这些监控的目标划分为如下几个主要的类别：

监控的方式

在了解了需要监控的各类目标后，我们需要选择合适的监控方式才能有效地跟踪和管理这些目标。
监控系统主要包含两种监控方式：白盒监控和黑盒监控。

• 白盒监控：这种监控方式主要关注问题的根本原因，它通过分析系统内部暴露的各种指标，来发现可能产生的问题。
  例如，在使用redis时，我们可以利用info命令获取众多的内部指标数据，从而了解redis的当前运行状态。例如redis所关联的从节点发生了宕机的情况，那么相应的指标就会显示redis slave down，这样，我们就能够迅速地定位并解决问题。因此，白盒监控主要是通过分析内部指标，并通过这些指标反馈的信息来找出问题的根源。

• 黑盒监控：这种监控方式主要关注问题的表面现象，通常，它会通过tcp、http等探针的方式模拟用户的请求，来获取服务的指标数据（例如，响应时间、站点可用性等）。
  例如，redis所关联的从节点发生宕机时，黑盒监控会返回像connection refused或connection timeout这样的提示等信息，而不会像白盒监控那样提示redis slave down。
  因此，黑盒监控的主要目标是站在用户的角度，关注他们在实际使用过程中可能遇到的问题，而不会去探究问题的根源。

因此，白盒监控和黑盒监控是两种相辅相成的方法，它们让我们能够从不同角度深入理解系统的运行状况。当我们将这两种监控方式结合使用时，可以更全面地了解系统的当前运行状况，提前发现并解决问题，从而更好地维护和优化系统，同时也能保障业务的稳定运行。

著名的监控方法论

方法论的重要性

我们前面讨论了要监控的目标和监控方式。思考一下，如果我们有100台主机，每台主机运行200个应用，每个应用又有上百个指标需要追踪。这就意味着我们需要处理二十万个监控的指标。
那么在这种情况下，若对所有指标都设置告警，我们很快就会被告警信息淹没。
所以，我们需要明确应用的哪些指标是最关键的，应优先关注，并在出现异常情况下触发告警。

解决这个问题的方法是引入一些成熟的监控方法论。
这些方法论帮助我们识别出最重要的指标，让我们可以将注意力集中在这些指标上，并在这些指标出现异常时触发告警。
目前，业界广泛使用的监控方法论包括google的四个黄金指标、以及red方法和use方法。

四个黄金指标

google的四个黄金指标着眼点在服务监控，这个四个指标分别是延迟、流量、错误、饱和度。

1. 延迟（latancy）：指一个服务完成请求所需的时间。
   例如，你在一个购物网点点击了查看商品列表的按钮，从你点击按钮到商品列表完全显示在你的屏幕上，假设所需的时间是1秒，那么我们就说这个服务的延迟是1秒。
   然后，这个延迟计算需要考虑的是成功的请求还是失败的请求，因为一个失败的请求可能很快就返回了，但这并不意味着服务实际响应快。因此，我们需要分别统计成功请求的延迟和失败请求的延迟，以准确反映服务的性能。

2. 流量（traffic）：有时也称为吞吐量，是指服务在单位时间内能处理的请求数量或mysql能处理的事务数量。
   例如，网站在5秒内处理了1000个请求，那么我们就说这个服务的流量或吞吐量每5s能达到1000个请求。这个指标可以帮助我们了解服务的处理能力，并为资源分配、性能优化等提供决策依据。

3. 错误（errors）：指一个服务请求错误的次数或错误的占比率。
   例如，在10000个请求中，有100个请求因为某些原因（如服务器内部错误、返回内容不符合预期、请求超时等）处理失败，那么我们就可以说这个服务的错误数是100，或者失败错误率是1%（100/10000）。监控错误数或错误率可以帮助我们及时发现和定位服务的问题，提高服务的可靠性和用户的满意度。

4. 饱和度（saturation）：用于衡量资源的使用程度，通常是指一个服务有多满。
   例如，一台web服务每秒能处理1000个请求。如果当前web服务每秒只处理100个请求，那么它的饱和度为10%（100/1000）。
   这意味着web服务目前不够饱和，还有大量的处理能力未被使用。
   但如果web服务每秒处理了700个请求，那么其饱和度就达到了70%（700/1000）。
   这意味着web服务真正的发挥了作用。
   同时我们也需要关注对应的指标，如果请求量持续增长，则会达到web服务的最大处理能力，可能会导致web服务无法快速地响应新的请求。

USE方法

use方法是由netflix的内核和性能工程师提出的系统性能分析方法。它主要着眼于系统资源的使用情况，这三个指标分别是使用率、饱和度、错误。

1. 使用率（utilization）：用于衡量系统资源使用情况
   例如，cpu在过去的60秒内有30秒被用来执行指令，那么我们可以说这个cpu的使用率是50%。
   这里的资源主要包括但不限于：cpu、内存、网络、磁盘等。
   一旦使用率达到了100%，通常表明系统已经发生了瓶颈。

2. 饱和度（saturation）：用于衡量系统资源的队列长度（不同于4大黄金信号）
   cpu的饱和度：在linux系统中，可以通过查看系统的平均负载来观察cpu的饱和度。平均负载是指在一定时间间隔内，运行队列中的进程数（包括正在运行的和等待运行的）。
   如果平均负载持续高于cpu的核心数，那么可以认为cpu的饱和度较高，可能需要增加cpu资源或优化系统的处理能力。
   磁盘的饱和度：在linux系统中，可以使用iostat -x命令查看aqu-sz（average queue size）平均队列大小字段来观察磁盘的饱和度。
   aqu-sz表示在给定的时间段内采样设备请求队列的平均长度。如果aqu-sz的值持续较高，可能意味着磁盘已经饱和，磁盘i/o操作的需求超过了其处理能力，可能需要更换更高i/o的磁盘。

3. 错误（errors）：用于衡量资源事件错误计数。
   例如：一个程序尝试使用malloc()函数分配内存，但系统没有足够的内存可供分配，那么malloc()将返回一个错误，那么我们就可以追踪malloc()失败的次数。
   其次，在网络接口的数据包传输过程中，由于接收缓冲区满了，无法容纳新到来的数据包，导致了86个数据包被丢弃drop。这种丢包事件也被视为错误errors

RED方法

red方法是由weave cloud提出的一种专为云原生应用和微服务架构设计的性能监控方法。它基于google的四个黄金指标（即延迟、流量、错误、饱和）的原则，结合了prometheus和kubernetes容器实践，进一步细化并总结出了三个关键指标：请求率、错误数、请求处理时间。
因此，red方法能够有效地帮助用户衡量云原生以及微服务应用下的用户体验问题。

1. （request）rate：系统每秒钟接收的请求数。而google指标中的流量是指系统单位时间内处理的请求数，或是请求的总量。

2. （request）errors：每秒失败的请求数。

3. （request）duration：处理每个请求所花费的时长。而google指标中的延迟是指系统从接收请求到响应请求所花费的时间。在某些情况下，duration可能更关注单个请求的处理时间，而延迟可能更关注系统的整体响应时间。

prometheus介绍

prometheus是什么

prometheus是由soundcloud使用go语言开放的时序数据库（TSDB，time series database），但它的功能并非局限于tsdb，因为它还支持对目标（如服务器、应用程序等）进行监控；
因此，我们也可以理解prometheus是一款开源的监控系统，但仅仅依托prometheus不足以支撑整个监控系统，它需要结合生态内其他的组件来构建一个完整的it监控系统。
例如：alertmanager、grafana、pushgateway等等

什么是时序数据

所谓时序数据，指的是，按照固定时间周期对某个或某些指标进行反复测量从而得到测量的数据集合。这些数据随着时间的推移，会形成一个连续的序列，因此被称为时序数据。

如果我们将这些数据绘制在图形上，通常会有一个数据轴（Y轴）表示数据值，一个时间轴（X）轴表示测量的时间点。

prometheus时序数据

在prometheus中，时序数据主要包括三个部分：指标名称、标签集、时序数据（时间戳、数据）

1. 指标名称
   例如，监控服务器的cpu使用率、内存总量，对应的指标名称可以是cpu_usage,memory_memtotal等。
   指标名称是被监控端提供的。

2. 标签集
   标签集用于区分不同的数据源或示例。
   假设我们有两台服务器，一台是web服务器，另一台是db数据库服务器。
   为了区分这两台服务器的cpu使用率数据，我们可以为它们添加不同的标签，
   例如：cpu_usage{type="web"}和cpu_usage{type="db"}

3. 时序数据
   指按照固定时间间隔，采集对应指标名称，从而获取到对应指标的数据。
   例如，每分钟采集一次cpu使用率（cpu_usage）。
   每个数据点包括采集cpu使用率的时间戳，以及该时间点采集到的样本值。

每一个指标名称和标签组合都会形成一条独立的时间序列。
这就表示，即使我们只探测了一个指标cpu_usage，但是它具有不同的标签值，就会产生不同的分别代表不同实例的时间序列。
在这些时间序列中，每一个特定的数据点被称为一个样本。
每个样本都包含指标名称、标签、时间戳以及对应的指标值。

prometheus的特定

多维数据模型

prometheus采用多维度的数据模型，可以对不同维度的数据进行监控和分析，同时promql可以对数据进行复杂的计算、过滤和查询等操作。
当使用prometheus监控一个web服务时，通常需要收集的数据包括：服务地址以及端口、请求url、请求的方法、请求的次数、以及请求状态码等指标。

在prometheus的多维数据模型中，我们可以通过定义不同的标签来为同一个指标添加不同的维度。
例如，我们可以定义http_total为一个指标名称，它用于记录http的总请求数，同时使用实例（instance）、路径（path）、方法（method）等标签来为该指标添加不同的维度。

假设我们有两个实例，分别是ip1和ip2，我们可以用以下方式记录数据：

# 这⾥我们记录了每个实例上的 HTTP 请求总数，并通过不同的标签来记录请求、路径以及⽅法等
http_total{instance="ip1", path="/api", method="GET"} 500
http_total{instance="ip1", path="/api", method="POST"} 200
http_total{instance="ip2", path="/user", method="GET"} 1000
http_total{instance="ip2", path="/user", method="POST"} 300

有了这些指标对应的数据后，我们就可以通过PromQL来对数据进行各种统计和分析，例如，可以查询ip1这个实例上的http请求数的总和

sum(http_total{instance="ip1"})
# 结果展示
{} 700

当然也可以查询某个路径上的请求方法分别情况，例如：统计所有http请求中path="/api"的总次数，然后基于method标签进行分组，可以拿到请求/api这个接口，get方法请求了多少次，post方法请求了多少次。

sum (http_total{path="/api"}) by (method)
# 结果展示
{method="GET"} 500
{method="POST"} 200

总之，通过多维数据模型，我们可以为每个指标添加不同的维度，同时也可以根据不同的维度进行数据的灵活查询与聚合等操作。

强大的PromQL

PromQL（prometheus query language）是prometheus的核心特性，它提供了强大且灵活的查询功能。相比之下，许多传统的监控系统只能进行简单的数据过滤和阈值判断，而缺乏类似的查询语言。

当我们需要特定的数据在原始数据中没有时，许多监控系统会在数据采集阶段（即在源头收集数据的阶段）进行处理。然而，数据采集阶段并不适合进行所有的计算场景。

以机器内存监控为例，我们可以从/proc/meminfo获得各种相关数据，如memavailable和memtotal。但是操作系统并不直接提供内存使用率相关的指标。

在zabbix你需要在数据源（被监控端）预先计算出内存使用率，然后传递给zabbix服务器进行监控和告警。
而在prometheus中，我们可以利用其查询语言PromQL在中心服务器上直接计算内存使用率：（1-memavailable/memtotal）*100。

这种设计理念使prometheus在处理复杂计算和告警场景时具有更高的灵活性。数据采集阶段专注于收集原始数据，而复杂的计算由中心服务器（即prometheus）处理。

通过PromQL可以轻松解决如下问题：

• 预测在12小时候，磁盘空间是否会被占满？
• cpu占用率前5位的服务有哪些？（过滤）
• 过去1分钟的系统负载超过了其cpu核心数两倍的实例有哪些？

高效的数据存储

prometheus使用专用的时间序列数据库。这种数据库非常强大，能够容纳和处理数以百万计的监控指标。
这些监控指标，都按照时间顺序排列并存储，每个数据点都配有一个时间戳。
所有的监控数据都精确地记录在这个时间点上。所以当你想要查看某个特定时间点的数据时，你可以直接提前对应的时间点，快速地找到所需的数据。无需遍历整个数据库。

指标名称
|
| cpu     数据cpu1 数据cpu2 数据cpu3
| memory  数据mem1 数据mem2 数据mem3
| network 数据net1 数据net2 数据net3
| process 数据pro1 数据pro2 数据pro3
| nginx   数据ng1  数据ng2  数据ng3
|------------------------------------------------------> 时间戳
          时间点1  时间点2  时间点3

prometheus不仅拥有高效的查询能力，而且还具有出色的存储效率，这主要得益于它采用的压缩算法。
该算法使得每个数据点所占用的存储空间约3.5字节。这种优化的存储方式大幅的降低了IO操作，以及存储的成本。
根据官方的数据，百万条的时间序列数据，每30秒记录一次，并且需要保留60天的历史数据，仅需要200GB左右的存储空间。这种高效的存储方式使prometheus能够轻松处理大规模数据，同时维持低成本。

多种服务发现

在实际应用中，我们监控的实例或者服务经常会发生变化，如容器实例的创建和销毁等，因此prometheus提供了多种服务发现方式来应对这种挑战。
这些方式包括：

• 1.静态服务配置：可以通过配置文件指定固定地址和端口，对目标服务进行监控。
• 2.基于配置文件的发现机制：以配置文件作为发现的源头，通过监控这些文件的变动来动态调整监控目标的增加或减少。通常会配合如像ansible这样的工具一起使用，对配置文件进行批量更新，只需要让prometheus重新加载这些配置，就能自动适应新的监控环境。
• 3.基于注册中心的发现机制：在微服务架构中，常常会使用consul等服务注册中心来管理所有的服务。prometheus可以读取consul中的服务列表，从而自动发现并开始监控所有注册的服务。
• 4.基于公有云api的发现机制：当你需要监控公有云上的rds服务时，一条条配置非常麻烦，这个时候就可以使用prometheus基于公有云的openapi进行服务发现。例如，配置prometheus自动拉取aws账户下所有rds实例的列表，从而实现对所有数据库实例的监控。
• 5.基于kubernetes的发现机制：在kubernetes环境中，prometheus可以通过调用kube-apiserver获取集群中的node、pod、endpoint、ingress等信息。例如，如果你在kubernetes集群中部署了一个新的应用，prometheus可以自动发现并开始监控这个新的pod
• 6.基于dns、http等服务发现。

可扩展的架构

prometheus支持横向扩展，可以通过部署多个实例、使用远程存储或者使用prometheus联邦等方式实现高可用和高性能的监控系统。

例如，为了应对大规模监控需求，可以部署多个prometheus实例并将它们配置位监控不同的服务或资源。同时，可以使用prometheus将这些实例的数据汇总到一个中心实例中，实现统一的监控视图。

总结

综上所述，prometheus具有灵活性、强大的查询语言、服务发现自动化、数据采集高效、架构可扩展等特点，是一款非常适合用于大规模监控系统的开源软件。

prometheus数据采集

prometheus数据采集方式

在传统的zabbix监控系统中，通常是需要在被监控的节点上安装agent代理程序。
由agent代理程序定期收集指标数据，并将其发送到监控服务器，完成数据采集。

在prometheus中，被监控端无需安装专门的agent。它只需要被监控端通过http协议开放出符合prometheus规范的指标数据，prometheus就能够顺利完成数据抓取。

但是，并不是所有的应用或服务都能直接支持http协议并提供符合prometheus所兼容的指标格式。因此，prometheus设计了三种主要的数据抓取机制，即instrumentation、exporter、pushgateway

1. instrumentation：被监控端通过http暴露出prometheus格式的数据，prometheus就可以直接才接，这就是所谓的instrumentation。像kubernetes、haproxy、zookeeper、rabbitmq、etcd等应用程序原生就支持暴露指标，可以直接被prometheus所监控。对于python、java、go这些开发语言编写的业务应用，开发人员可以直接引用prometheus客户端来编写代码，让应用程序原生就能支持暴露需要监控的指标数据，这些指标数据可以直接被prometheus采集。这就相当于应用程序本身具备了与prometheus通信的能力，无需额外的中间件来转换数据。

2. exporter（导出器）：有些应用程序并不原生支持通过http协议暴露指标数据。对于这类应用，我们可以使用exporter来代为采集指标。exporter是一个独立的运行程序，负责从目标应用中采集原始格式的数据，并将其转换为prometheus可以理解的格式，然后通过http协议暴露出来，供prometheus抓取指标。简单来说，exporter就像一个翻译官，将目标应用程序的数据翻译成prometheus可以读懂的语言。

3. pushgateway（推送网关）：对于那些生命周期较短或者不方便被prometheus主动拉取数据的应用程序（如短暂运行的脚本任务）可以使用pushgateway。让这些短暂运行的脚本程序，将对应的指标数据主动推送到pushgateway，然后prometheus从pushgateway中抓取数据。pushgateway就像一个中间站，存储这些短暂任务产生的指标数据，等待prometheus来抓取。

prometheus作业与实例

在prometheus中，被监控的每一个对象都称为实例（instance），实例代表着一个独立的监控目标，它由ip地址加端口号组合而成。

如localhost:9000，在prometheus的配置中，这些实例也可以被称为目标（target）或者端点（endpoint）

为了方便管理这些目标实例，我们通常会将功能相似或者类型相同的（实例instance）归纳到一个作业（job）中。

• 实例（instance）：实例指的是一个被监控的端点。它通常是指向一个运行的服务或应用程序的进程，每个实例都以host:port进行标识。例如，一个mysql数据库服务运行在10.0.0.51:3306上，那么它就是一个实例。

• 作业（job）：作业是一组具有相同类型的实例集合。例如，多个分布在不同服务器上的mysql应用，我们可以将这些实例归类为同一个mysql的job作业，而后按照job分组后的维度进行分析。

在prometheus的数据模型中，job和instance是两个核心的标签，它们会自动附加到所有收集的时间序列数据上。如下所示：

# 查询
cpu_usage
# 结果
cpu_usage{job="node-exporter",instance="10.0.0.7"} 14.04
cpu_usage{job="node-exporter",instance="10.0.0.8"} 12.04
cpu_usage{job="node-exporter",instance="10.0.0.9"} 16.04

prometheus架构

prometheus生态组件

prometheus最为核心的功能就是数据采集和数据存储。但是，仅有这两项功能并不能构成一个完整的监控系统。
因此，prometheus需要与其他的组件进行结合，从而实现数据的分析、展示和告警，因此一个完整意义上的监控系统需要如下5个组成部分：

• 1.数据采集：prometheus采用pull模式主动向被监控端抓取指标数据。被监控端可以是直接暴露出的应用程序指标数据，也可以是通过安装exporter来抓取和暴露应用程序的数据。只要是以prometheus格式提供的指标数据，都可以被prometheus抓取。

• 2.数据存储：prometheus会将抓取到的数据，存储在本地的时间序列数据库中，以防止数据丢失

• 3.数据查询和分析：prometheus内置了强大的查询语言PromQL，用户可以通过PromQL查询存储在prometheus上的时序数据，进行实时查询和分析。同时PromQL支持多种聚合操作和数学运算，可以对数据进行深入分析。

• 4.告警系统：prometheus的告警分为两个部分组成，告警规则和alertmanager。告警规则定义在prometheus服务器中，根据用户指定的条件触发告警。当告警触发时，prometheus服务器会将告警信息发送给alertmanager。alertmanager会对告警信息进行去重、分组，然后将告警信息通过媒介发送给接收者（如邮件、钉钉等）。

• 5.数据可视化：prometheus内置了一个简单的图形界面，用户可以在web浏览器中使用PromQL查询时序数据，并将查询结果以图形的形式展示出来。此外，prometheus还可以与第三方可视化工具（如grafana）集成，提供更丰富的可视化功能。

prometheus工作逻辑

了解prometheus生态中的各个组件后，我们可以概况其工作流程：目标发现、数据抓取、存储、分析、告警和展示。这些步骤共同构成了prometheus强大的监控和告警系统。

1. 目标发现：在开始监控之前，prometheus需要确定监控目标。它可以通过静态的配置文件指定，或者利用服务发现机制动态地发现需要监控的服务。例如，在kubernetes环境中，prometheus能够自动识别并监控集群中的服务，确保随着集群的变化，监控目标始终是最新的。

2. 数据抓取：有了明确的监控目标后，prometheus通过http协议定期从这些目标的/metrics端点抓取指标数据。这些端点暴露了各种监控指标。

3. 数据存储：数据抓取后会存储在本地的时间序列数据库中。

4. 数据分析：数据一旦被存储，就可以用PromQL查询语言，对其进行分析。无论是实时监控还是历史数据分析，PromQL都能提供丰富的数据聚合功能，以洞察系统的状况。

5. 告警：prometheus根据预定义的规则进行评估。当监控的指标达到告警阈值时，prometheus会将告警信息发送给alertmanager，由alertmanager进行告警处理并通知。

6. 数据可视化：prometheus自带了简单的UI。但对于更高级的数据可视化需求，通常会整合grafana这样的工具来为用户提供直观的数据展示方式。

prometheus数据模型

数据模型基础

prometheus中最为重要的是，对指标进行抓取和存储，这些存储下来的数据可以帮助我们分析趋势，或预测未来。

为了更有高效的存储和查询这些数据，prometheus使用了一种叫时间序列的数据格式进行存储，所谓时间序列就是按照时间顺序记录所采集到的指标以及指标数据。

而每个时间序列都是由一个指标名称加一堆标签所组成的一条唯一序列标识，其格式"<metri_name>{<label_name>=<label_value>,<label_name>=<label_value>,...} @<timestamp> <value>"

举个例子：我们连续记录和测量植物的高度。在这个例子中：

• 1.metric_name：记录植物的高度。
• 2.label_name和label_value：记录植物的其他信息，例如植物的种类为向日葵，所种植的位置是阳台等信息，这些额外的信息就被称为标签，它们会附加到指标上，帮助我们更好地分类和理解数据的意义。
• 3.timestamp和value：每次测量植物的高度，会记录下测量的日期（即时间戳）和那一天植物的高度（即值）。

通过这种方式，prometheus可以跟踪，随时间变化的任何指标，并且可以通过标签来分类和组织这些数据。

指标名称metricname

在监控系统中，我们需要抓取的指标非常多，如cpu使用率、内存使用情况、网络流量等。
我们使用metricname来区分这些不同指标。
这些指标名称一般由小写字母、数字和下划线构成。
例如，cpu_usage这个指标代表cpu的使用率，它的值为15.05，则表示当前cpu的使用率为15.05%。

但是，cpu_usage这个指标并没有具体表明它是针对哪个节点的cpu使用率，也没有指出是哪个cpu核心的使用率。因此，为了区分，并确定不同节点上各个cpu核心的使用率，我们需要引入label（标签）这一机制。

指标标签label

标签以键值对的形式存在，为指标添加了详细信息和上下文（元数据）。

例如，在我们之前提及的指标cpu_usage中，为了区分来自不同节点的cpu使用情况，我们可以利用标签。给每个节点的指标添加一个instance标签，就可以在查询和分析时，区分开每个节点的cpu使用率。

假设我们现在有两个节点，名称分别为node01.dot.com和node02.dot.com，我们可以为各自的cpu_usage指标添加指定的instance标签：

当然标签除了区分节点之外，我们还可以使用标签来继续描述其他维度，例如cpu的各个核心的使用率。我们可以添加一个core的标签来区分每个节点的cpu核心使用情况：

通过使用标签，我们能在prometheus中查询和分析数据。例如，我们想查询node01上各个cpu核心使用情况，或者查询node02节点cpu的第0个核心使用情况：

# 查询node01节点的各CPU核⼼使⽤率
cpu_usage{instance="node01.oldxu.net"}
# 结果
cpu_usage{instance="node01.oldxu.net",core="0"} 7.535
cpu_usage{instance="node01.oldxu.net",core="1"} 7.535
# 查询node02节点，核⼼为0的CPU使⽤率
cpu_usage{instance="node02.oldxu.net",core="0"}
# 结果
cpu_usage{instance="node01.oldxu.net",core="0"} 8.025