Promethus简介
Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。
Prometheus作为新一代的云原生监控系统，目前已经有超过650+位贡献者参与到Prometheus的研发工作上，并且超过120+项的第三方集成。
监控的目标
在《SRE: Google运维解密》一书中指出，监控系统需要能够有效的支持白盒监控和黑盒监控。通过白盒能够了解其内部的实际运行状态，通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。而黑盒监控，常见的如HTTP探针，TCP探针等，可以在系统或者服务在发生故障时能够快速通知相关的人员进行处理。通过建立完善的监控体系，从而达到以下目的：
1 . 长期趋势分析：通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间增长率的判断，我们可以提前预测在未来什么时间节点上需要对资源进行扩容。
2 . 对照分析：两个版本的系统运行资源使用情况的差异如何？在不同容量情况下系统的并发和负载变化如何？通过监控能够方便的对系统进行跟踪和比较。
3 . 告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员，从而能够对问题进行快速的处理或者提前预防问题的发生，避免出现对业务的影响。
4 . 故障分析与定位：当问题发生后，需要对问题进行调查和处理。通过对不同监控监控以及历史数据的分析，能够找到并解决根源问题。
5 . 数据可视化：通过可视化仪表盘能够直接获取系统的运行状态、资源使用情况、以及服务运行状态等直观的信息。
与常见监控系统比较
对于常见的监控系统，如Nagios、Zabbix的用户而言，往往并不能很好的解决上述问题。这里以Nagios为例，如下图所示是Nagios监控系统的基本架构:
Nagios的主要功能是监控服务和主机。Nagios软件需要安装在一台独立的服务器上运行，该服务器称为监控中心,每一台被监控的硬件主机或者服务都需要运行一个与监控中心服务器进行通信的Nagios软件后台程序，可以理解为Agent或者插件。
首先对于Nagios而言，大部分的监控能力都是围绕系统的一些边缘性的问题，主要针对系统服务和资源的状态以及应用程序的可用性。 例如：Nagios通过check_disk插件可以用于检查磁盘空间，check_load用于检查CPU负载等。这些插件会返回4种Nagios可识别的状态，0(OK)表示正常，1(WARNING)表示警告，2(CRITTCAL)表示错误，3(UNKNOWN)表示未知错误，并通过Web UI显示出来。
对于Nagios这类系统而言，其核心是采用了测试和告警(check&alert)的监控系统模型。 对于基于这类模型的监控系统而言往往存在以下问题：1 . 与业务脱离的监控：监控系统获取到的监控指标与业务本身也是一种分离的关系。好比客户可能关注的是服务的可用性、服务的SLA等级，而监控系统却只能根据系统负载去产生告警；
2 . 运维管理难度大：Nagios这一类监控系统本身运维管理难度就比较大，需要有专业的人员进行安装，配置和管理，而且过程并不简单
3 . 可扩展性低： 监控系统自身难以扩展，以适应监控规模的变化；
4 . 问题定位难度大：当问题产生之后（比如主机负载异常增加）对于用户而言，他们看到的依然是一个黑盒，他们无法了解主机上服务真正的运行情况，因此当故障发生后，这些告警信息并不能有效的支持用户对于故障根源问题的分析和定位。
OpenTSDB是基于Hadoop/HBase的，扩展性不错，但过重，且对于Ops的要求比较高.
InfluxDB相当不错，但其杀手锏功能类似于集群化之类的，都是付费版本才有的，且其维护基于单一的商业公司（言下之意，如果你不用商业版，其实InfluxDB也没有什么特别大的优势，而且还是单一公司维护有风险,）
Graphite和Prometheus比起来，Prometheus功能更丰富强大.1
Prometheus vs. Zabbix
# Zabbix](https://www.zabbix.com/) 使用的是 C 和 PHP, Prometheus 使用 Golang, 整体而言 Prometheus 运行速度更快一点。
# Zabbix 属于传统主机监控，主要用于物理主机、交换机、网络等监控，Prometheus 不仅适用主机监控，还适用于 Cloud、SaaS、Openstack、Container 监控。
# Zabbix 在传统主机监控方面，有更丰富的插件。
# Zabbix 可以在 WebGui 中配置很多事情，Prometheus 需要手动修改文件配置
Prometheus vs Sensu
Sensu 广义上讲是 Nagios 的升级版本，它解决了很多 Nagios 的问题，如果你对 Nagios 很熟悉，使用 Sensu 是个不错的选择。
Sensu 依赖 RabbitMQ 和 Redis，数据存储上扩展性更好。
Prometheus vs InfluxDB
InfluxDB 是一个开源的时序数据库，主要用于存储数据，如果想搭建监控告警系统，需要依赖其他系统。
InfluxDB 在存储水平扩展以及高可用方面做的更好, 毕竟核心是数据库。
Prometheus的缺点
Prometheus是一个开源的完整监控解决方案，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型。 相比于传统监控系统Prometheus具有以下优点如下:
缺点
# 1. 整体的集群庞大到一定程度之后(全局的监控需求)
# 2. 单个服务的集群扩展到一定程度(单服务的监控需求)
# 3. 跨机房监控需求(单个机房单个Prometheus服务器，但需要有一个跳脱实例机房的节点进行overview)
在这些情况下，单个节点的Prometheus可能就无法胜任了，这时候必然就需要进行水平扩展或者引入分布式集群概念
联邦集群
# 1. 联邦集群中的Prometheus节点是分层级的
# 2. 下级的Prometheus节点采集应用数据
# 3. 上级的Prometheus节点从下级的Prometheus节点上采集数据.
Prometheus并不存在高可用的解决方案
官方现在的设计是将单节点的Prometheus做好，并提供联邦集群这个解决方案让用户自己去组件自己的监控拓扑网络，这在规模比较小的时候还能对付，规模一大就容易出错了，维护者必须很清楚联邦集群每一个节点负责的业务是什么,然后各层级节点如何对应汇集数据，这非常考验整个拓扑结构的搭建者的功力，以及维护的流程和工具
Prometheus的优点
易于管理
Prometheus核心部分只有一个单独的二进制文件，不存在任何的第三方依赖(数据库，缓存等等)。唯一需要的就是本地磁盘，因此不会有潜在级联故障的风险。
Prometheus基于Pull模型的架构方式，可以在任何地方（本地电脑，开发环境，测试环境）搭建我们的监控系统。对于一些复杂的情况，还可以使用 Prometheus服务发现(Service Discovery)的能力动态管理监控目标。
监控服务内部运行状态
Pometheus鼓励用户监控服务的内部状态，基于Prometheus丰富的Client库，用户可以轻松的在应用程序中添加对Prometheus的支持，从而让用户可以获取服务和应用内部真正的运行状态。
比如在 Kubernetes 的 Pod 中的 docker 实例，可能是内部 IP 地址，对外可见 IP 地址是 Pod 地址；
另一方面，docker 容器应用生命周期可能会比较短，VM 上的应用是重部署，docker 则是销毁重建，对监控系统可能会有一些新的影响。
强大的数据模型
所有采集的监控数据均以指标(metric)的形式保存在内置的时间序列数据库当中(TSDB)。所有的样本除了基本的指标名称以外，还包含一组用于描述该样本特征的标签。
如下所示:
http_request_status{code='200',content_path='/api/path', environment='produment'} => [value1@timestamp1,value2@timestamp2...]
http_request_status{code='200',content_path='/api/path2', environment='produment'} => [value1@timestamp1,value2@timestamp2...]
每一条时间序列由指标名称(Metrics Name)以及一组标签(Labels)唯一标识。每条时间序列按照时间的先后顺序存储一系列的样本值。
表示维度的标签可能来源于你的监控对象的状态，比如code=404或者content_path=/api/path。也可能来源于的你的环境定义，比如environment=produment。基于这些Labels我们可以方便地对监控数据进行聚合，过滤，裁剪。
强大的查询语言PromQL
Prometheus内置了一个强大的数据查询语言PromQL
Prometheus是一个时序数据库，（所有保存在Proetheus里的数据都是按时间戳和值的序列顺序存放的，称为Vector（向量）），因为是NoSQL，相比关系型数据库Mysql能很好支持大量数据写入.
从最新测试结果看，在硬件资源满足情况下，Prometheus单实例每秒采集10万条
# 每一次数据采集或得到的即一个Sample(样本)，其由三部分组成:
# Metrics(指标): 包含了Metrics name以及Labels.
# Timestamp(时间戳): 当前采样的时间，精确到毫秒.
# Value(采样值): 其类型为float64浮点数.
# 通过PromQL可以实现对监控数据的查询、聚合。同时PromQL也被应用于数据可视化(如Grafana)以及告警当中。
# 通过PromQL可以轻松回答类似于以下问题：
# 在过去一段时间中95%应用延迟时间的分布范围？
# 预测在4小时后，磁盘空间占用大致会是什么情况？
# CPU占用率前5位的服务有哪些？(过滤)
高效
对于监控系统而言，大量的监控任务必然导致有大量的数据产生。而Prometheus可以高效地处理这些数据，对于单一Prometheus Server实例而言它可以处理：
# 数以百万的监控指标
# 每秒处理数十万的数据点。
可扩展
Prometheus是如此简单，因此你可以在每个数据中心、每个团队运行独立的Prometheus Sevrer。Prometheus对于联邦集群的支持，可以让多个Prometheus实例产生一个逻辑集群，当单实例Prometheus Server处理的任务量过大时，通过使用功能分区(sharding)+联邦集群(federation)可以对其进行扩展。
易于集成
使用Prometheus可以快速搭建监控服务，并且可以非常方便地在应用程序中进行集成。目前支持： Java， JMX， Python， Go，Ruby， .Net， Node.js等等语言的客户端SDK，基于这些SDK可以快速让应用程序纳入到Prometheus的监控当中，或者开发自己的监控数据收集程序。同时这些客户端收集的监控数据，不仅仅支持Prometheus，还能支持Graphite这些其他的监控工具。
同时Prometheus还支持与其他的监控系统进行集成：Graphite， Statsd， Collected， Scollector， muini， Nagios等。
Prometheus社区还提供了大量第三方实现的监控数据采集支持：JMX， CloudWatch， EC2， MySQL， PostgresSQL， Haskell， Bash， SNMP， Consul， Haproxy， Mesos， Bind， CouchDB， Django， Memcached， RabbitMQ， Redis， RethinkDB， Rsyslog等等。
可视化
Prometheus Server中自带了一个Prometheus UI，通过这个UI可以方便地直接对数据进行查询，并且支持直接以图形化的形式展示数据。同时Prometheus还提供了一个独立的基于Ruby On Rails的Dashboard解决方案Promdash。最新的Grafana可视化工具也已经提供了完整的Prometheus支持，基于Grafana可以创建更加精美的监控图标。基于Prometheus提供的API还可以实现自己的监控可视化UI。
开放性
通常来说当我们需要监控一个应用程序时，一般需要该应用程序提供对相应监控系统协议的支持。因此应用程序会与所选择的监控系统进行绑定。为了减少这种绑定所带来的限制。对于决策者而言要么你就直接在应用中集成该监控系统的支持，要么就在外部创建单独的服务来适配不同的监控系统。
而对于Prometheus来说，使用Prometheus的client library的输出格式不止支持Prometheus的格式化数据，也可以输出支持其它监控系统的格式化数据，比如Graphite。
因此你甚至可以在不使用Prometheus的情况下，采用Prometheus的client library来让你的应用程序支持监控数据采集。
相比关系型数据库它使用了时间序列数据库
# 时序数据库特点:
# 1.大部分时间都是写入操作。
# 2.写入操作几乎是顺序添加，大多数时候数据到达后都以时间排序。
# 3.写操作很少写入很久之前的数据，也很少更新数据。大多数情况在数据被采集到数秒或者数分钟后就会被写入数据库。
# 4.删除操作一般为区块删除，选定开始的历史时间并指定后续的区块。很少单独删除某个时间或者分开的随机时间的数据。
# 5.基本数据大，一般超过内存大小。一般选取的只是其一小部分且没有规律，缓存几乎不起任何作用。
# 6.读操作是十分典型的升序或者降序的顺序读。
# 7.高并发的读操作十分常见。
# InfluxDB,OpenTSDB使用的也是时序数据库.
Prometheus组件
上图为Prometheus的基本架构以及生态中的一些组件作用:
Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控。不需要任何SDK或者其他的集成过程。这样做非常适合做虚拟化环境监控系统，比如VM、Docker、Kubernetes等。输出被监控组件信息的HTTP接口被叫做exporter 。目前互联网公司常用的组件大部分都有exporter可以直接使用，比如Varnish、Haproxy、Nginx、MySQL、Linux系统信息(包括磁盘、内存、CPU、网络等等).
Prometheus服务过程
Prometheus服务过程大概是这样:
Prometheus Daemon负责定时去目标上抓取metrics(指标)数据，每个抓取目标需要暴露一个http服务的接口给它定时抓取。Prometheus支持通过配置文件、文本文件、Zookeeper、Consul、DNS SRV Lookup等方式指定抓取目标。Prometheus采用PULL的方式进行监控，即服务器可以直接通过目标PULL数据或者间接地通过中间网关来Push数据。
Prometheus在本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列中。
Prometheus通过PromQL和其他API可视化地展示收集的数据。Prometheus支持很多方式的图表可视化，例如Grafana、自带的Promdash以及自身提供的模版引擎等等。Prometheus还提供HTTP API的查询方式，自定义所需要的输出。
PushGateway支持Client主动推送metrics到PushGateway，而Prometheus只是定时去Gateway上抓取数据。
Alertmanager是独立于Prometheus的一个组件，可以支持Prometheus的查询语句，提供十分灵活的报警方式。
Prometheus使用场景
Prometheus适用场景
Prometheus在记录纯数字时间序列方面表现非常好。它既适用于面向服务器等硬件指标的监控，也适用于高动态的面向服务架构的监控。对于现在流行的微服务，Prometheus的多维度数据收集和数据筛选查询语言也是非常的强大。Prometheus是为服务的可靠性而设计的，当服务出现故障时，它可以使你快速定位和诊断问题。它的搭建过程对硬件和服务没有很强的依赖关系。
Prometheus不适用场景
Prometheus它的价值在于可靠性，甚至在很恶劣的环境下，你都可以随时访问它和查看系统服务各种指标的统计信息。 如果你对统计数据需要100%的精确，它并不适用，例如：它不适用于实时计费系统。
Prometheus Server
Prometheus Server是Prometheus组件中的核心部分，负责实现对监控数据的获取，存储以及查询。 Prometheus Server可以通过静态配置管理监控目标，也可以配合使用Service Discovery的方式动态管理监控目标，并从这些监控目标中获取数据。其次Prometheus Server需要对采集到的监控数据进行存储，Prometheus Server本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。最后Prometheus Server对外提供了自定义的PromQL语言，实现对数据的查询以及分析。
Prometheus Server内置的Express Browser UI，通过这个UI可以直接通过PromQL实现数据的查询以及可视化。
Prometheus Server的联邦集群能力可以使其从其他的Prometheus Server实例中获取数据，因此在大规模监控的情况下，可以通过联邦集群以及功能分区的方式对Prometheus Server进行扩展。
Exporters
Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。
一般来说可以将Exporter分为2类：
- 直接采集：这一类Exporter直接内置了对Prometheus监控的支持，比如cAdvisor，Kubernetes，Etcd，Gokit等，都直接内置了用于向Prometheus暴露监控数据的端点。
- 间接采集：间接采集，原有监控目标并不直接支持Prometheus，因此我们需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序。例如： Mysql Exporter，JMX Exporter，Consul Exporter等。
AlertManager
在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。AlertManager即Prometheus体系中的告警处理中心。
PushGateway
由于Prometheus数据采集基于Pull模型进行设计，因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。 当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转。可以通过PushGateway将内部网络的监控数据主动Push到Gateway当中。而Prometheus Server则可以采用同样Pull的方式从PushGateway中获取到监控数据。
二进制安装Prometheus
Prometheus基于Golang编写，编译后的软件包，不需要依赖第三方依赖，用户只需要下载对应平台的二进制包，解压并且添加基本的配置即可正常启动Prometeus Server。
下载二进制包并解压
wget https://github.com/prometheus/prometheus/releases/download/v2.13.0/prometheus-2.13.0.linux-amd64.tar.gz
tar xvf prometheus-2.13.0.linux-amd64.tar.gz -C /usr/local/
cd /usr/local/
ln -s prometheus-2.13.0.linux-amd64/ prometheus
修改配置文件
vim prometheus.yml
# 全局配置global:
scrape_interval: 15s # 设置抓取间隔，每15s采集一次数据，默认为1分钟
evaluation_interval: 15s # 估算规则的默认周期，每15秒计算一次规则。默认1分钟
# scrape_timeout # 默认抓取超时，默认为10s
# Alertmanager相关配置
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# 规则文件列表，使用'evaluation_interval' 参数去抓取
rule_files: # rule_files指定加载的告警规则文件.一般在单独的文件定义，
# 在prometheus.yml中引用.这个规则文件格式请看后面报警示例.
# - "first_rules.yml"
# - "second_rules.yml"
# 抓取配置列表
scrape_configs: # 指定prometheus要监控的目标.在scrape_config中每个监控目标是一个job，但job类型有很多种,
# 可以是最简单的static_config,即静态地指定每一个目标
- job_name: 'prometheus' #
static_configs:
- targets: ['localhost:9090'] # 这里定义了一个job的名称: job_name:'prometheus',然后定义监控节点
# 下面的内容不用写到配置文件里面，否则影响后面服务的启动,只是做一个示例:
static_config:
- targets: ['server01:9100','IP:9100','nginxserver:9100','web006:9100','redis:9100',
'logserver:9100','redis1:9100']
# 可以看到target可以并列写入多个节点，用逗号隔开，机器名+端口号，端口号主要是exporters的端口，
# 这里9100其实是node_exporter的默认端口，配置完成后,prometheus就可以通过配置文件识别监控的节点,
# 持续开始采集数据，prometheus基础配置也就搭建好了.
# cat first_rules.yml
groups:
- name: example
rules:
- alert: InstanceDown
expr: up == 0
for: 1m
labels:
severity: critical
annotations:
summary: Instance has been down for more than 5 minutes
创建prometheus的用户及数据存储目录
# 为了安全，我们使用普通用户来启动prometheus服务，
# 作为一个时序型数据库产品，prometheus的数据默认会存放在应用目录下，我们需修改为/data/prometheus下
useradd -s /sbin/nologin -M prometheus
mkdir -p /data/prometheus
chown -R prometheus:prometheus /usr/local/prometheus
chown -R prometheus:prometheus /data/prometheus/
创建Systemd服务启动prometheus
# prometheus的启动很简单，只需要重新启动解压目录的二进制文件prometheus即可，
# 但是为了更加方便的对prometheus进行管理，这里使用systemd来启停prometheus。
vim /usr/lib/systemd/system/prometheus.service
[Unit]
Description=Prometheus
Documentation=https://prometheus.io/
After=network.target
[Service]
Type=simple
User=prometheus
ExecStart=/usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml --storage.tsdb.path=/data/prometheus
Restart=on-failure
[Install]
WantedBy=multi-user.target
# 在此配置文件里面，定义了启动的命令，定义了数据存储在/data/prometheus路径下，
# 否则默认会在prometheus二进制目录的data下.
systemctl start prometheus
systemctl status prometheus
systemctl enable prometheus
容器安装Prometheus
对于Docker用户，直接使用Prometheus的镜像即可启动Prometheus Server：
docker run -p 9090:9090 -v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus
浏览器访问IP:9090
安装Node Exporter采集主机数据
为了方便看出效果，我们到另外一台机器安装node exporter
与传统的监控zabbix来对比的话，prometheus-server就像是mysql，负责存储数据。只不过这是时序数据库而不是关系型的数据库。数据的收集还需要其他的客户端，在prometheus中叫做exporter。针对不同的服务，有各种各样的exporter，就好比zabbix的zabbix-agent一样。
这里为了能够采集到主机的运行指标如CPU, 内存，磁盘等信息。我们可以使用Node Exporter。Node Exporter同样采用Golang编写，并且不存在任何的第三方依赖，只需要下载，解压即可运行。
下载地址:
wget https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz
解压node_exporter
tar xvf node_exporter-0.18.1.linux-amd64.tar.gz -C /usr/local/
# 新建一个目录专门安装各种exporter
mkdir -p /usr/local/prometheus_exporter
cd /usr/local
mv node_exporter-0.18.1.linux-amd64/ /usr/local/prometheus_exporter/
cd /usr/local/prometheus_exporter/
ln -s node_exporter-0.18.1.linux-amd64/ node_exporter
启动node_exporter
#直接打开node_exporter的可执行文件即可启动 node export，默认会启动9100端口。建议使用nohup来启动
/usr/local/prometheus_exporter/node_exporter/node_exporter
#建议使用nohup
nohup /usr/local/prometheus_exporter/node_exporter/node_exporter >/dev/null 2>&1 &
# 或者直接
cp /usr/local/prometheus_exporter/node_exporter-0.18.1.linux-amd64/node_exporter /usr/local/bin/
node_exporter
# 但是这些局限性都很强，我们可以跟prometheus一样，加入到系统服务，使用systemd管理
添加Node_exporter到系统服务
vim /usr/lib/systemd/system/node_exporter.service
[Unit]
Description=node_exporter
Documentation=https://prometheus.io/
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/prometheus_export/node_exporter-0.18.1.linux-amd64/node_exporter
# 注意此处版本
Restart=on-failure
[Install]
WantedBy=multi-user.target
# 启动服务
systemctl start node_exporter
systemctl daemon-reload
systemctl status node_exporter
加入开机自启动
在 /etc/rc.local 加入上面的启动命令即可
# 配置Prometheus,收集node exporter的数据
# 可以看到node exporter启动后也就是暴露了9100端口，并没有把数据传到prometheus，
# 我们还需要在prometheus中配置，让prometheus去pull这个接口的数据。
# 我们去监控主机编辑prometheus.yml文件，修改最后几行，然后重启服务
vim /usr/local/prometheus/prometheus.yml
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'node'
static_configs:
- targets: ['172.19.0.51:9100']
# node节点的targets处的IP填写你要监控的node的IP.
systemctl restart prometheus
# 我们登录到Prometheus主机，看下这个节点是不是up状态
接下来我们可以通过访问node_exporter那个节点的IP:9100 访问到以下页面:
我们可以看到当前主机的所有监控数据.但是每一个指标之前都有如下形式的信息
# HELP用于解释当前指标的含义
# TYPE则说明当前指标的数据类型
从上面的例子中node_cpu的注释表明当前指标是cpu0上idle进程占用CPU的总时间，CPU占用时间是一个只增不减的度量指标，从类型中也可以看出node_cpu的数据类型是计数器(counter),与该指标的实际含义一致，又例如node_locad1该指标反映了当前主机再一分钟以内的负载情况，系统的负载情况会随着系统的资源使用而变化，因此node_load1反映的是当前状态，数据可能增多也可能减少，从注释中可以看出当前指标类型为仪表盘(gauge),与指标反映的实际含义一致.
# 除了这些以外，在当前页面中根据物理主机系统的不同，你还可能看到如下监控指标：
# node_boot_time：系统启动时间
# node_cpu：系统CPU使用量
# node_disk_*：磁盘IO
# node_filesystem_*：文件系统用量
# node_load1：系统负载
# node_memeory_*：内存使用量
# node_network_*：网络带宽
# node_time：当前系统时间
# go_*：node exporter中go相关指标
# process_*：node exporter自身进程相关运行指标
比如我们使用PromQL表达式查询特定监控指标的监控数据，如下所示，如下所示，查询主机负载变化情况，可以使用关键字
node_load1可以查询出Prometheus采集到的主机负载的样本数据，这些样本数据按照时间先后顺序展示，形成了主机负载随时间变化的趋势图表：
Grafana简介
Grafana是一个开源的度量分析与可视化套件。纯 Javascript 开发的前端工具，通过访问库（如InfluxDB），展示自定义报表、显示图表等。大多使用在时序数据的监控方面，如同Kibana类似。Grafana的UI更加灵活，有丰富的插件，功能强大。
Grafana支持许多不同的数据源。每个数据源都有一个特定的查询编辑器,该编辑器定制的特性和功能是公开的特定数据来源。
一个类似Kibana的东西，也是对后端的数据进行实时展示，那么Grafana和Kibana有什么区别？在我看来区别不大，不过在大家的日常使用中Kibana是跟着Logstash、ElasticSearch等组件一起使用做日志展示、索引、分析的，造成了一种假象就是Kibana就只有这种用法了，Kibana也可以接入其他数据源的，不过大家最长用的还是展示日志，Grafana是什么呢？该项目你可能没听过，也比较年轻，他一般是和一些时间序列数据库进行配合来展示数据的，例如：Graphite、OpenTSDB、InfluxDB等。下面看看官方是怎么解释Grafana的：
grafana是用于可视化大型测量数据的开源程序，他提供了强大和优雅的方式去创建、共享、浏览数据。dashboard中显示了你不同metric数据源中的数据。
grafana最常用于因特网基础设施和应用分析，但在其他领域也有机会用到，比如：工业传感器、家庭自动化、过程控制等等。
grafana有热插拔控制面板和可扩展的数据源，目前已经支持Graphite、InfluxDB、OpenTSDB、Elasticsearch。
Grafana安装
此处我们拿prometheus做例子,虽然说prometheus能展示一些图表，但对比Grafana，那只是过家家，接下来我们在同一个服务器安装Grafana服务，用来展示prometheus收集到的数据
下载并解压安装包
wget https://dl.grafana.com/oss/release/grafana-6.4.2.linux-amd64.tar.gz
tar xvf grafana-6.4.2.linux-amd64.tar.gz -C /usr/local/
ln -s /usr/local/grafana-6.4.2/ /usr/local/grafana
创建grafana用户及数据存放目录
useradd -s /sbin/nologin -M grafana
mkdir /data/grafana -p
mkdir /data/grafana/plugins -p
mkdir /data/grafana/provisioning -p
mkdir /data/grafana/data -p
mkdir /data/grafana/log -p
chown -R grafana:grafana /usr/local/grafana/
chown -R grafana:grafana /data/grafana/
修改配置文件
vim /usr/local/grafana/conf/defaults.ini
data = /data/grafana/data
logs = /data/grafana/log
plugins = /data/grafana/plugins
provisioning = /data/grafana/conf/provisioning
把grafana-server添加到systemd中
vim /usr/lib/systemd/system/grafana-server.service
[Unit]
Description=Grafana
After=network.target
[Service]
User=grafana
Group=grafana
Type=notify
ExecStart=/usr/local/grafana/bin/grafana-server -homepath /usr/local/grafana
Restart=on-failure
[Install]
WantedBy=multi-user.target
systemctl start grafana-server && systemctl enable graana-server
启动服务，并用web访问http://IP:3000，默认3000端口，admin/admin
添加数据源
# grafana虽然已经安装好了，但是这个时候还没有数据，没办法作图。
# 下面我们把grafana和prometheus关联起来，也就是在grafana中添加添加数据源。
# 在配置页面点击添加数据源，然后选择prometheus，输入prometheus服务的参数即可。
添加自带的示例图表
按照上面的指导添加数据源之后，我们就可以针对这些数据来绘制图表了。grafana最人性化的一点就是拥有大量的图表模板，我们只需要导入模板即可，从而省去了大量的制作图表的时间。
目前我们的prometheus还没有什么监控数据，只有prometheus本身的数据，我们看下这些prometheus本身数据图表是怎样的。
在添加数据源的位置上，右边的选项有个Dashboards的菜单选项，我们点击进去，然后导入prometheus2.0.
接下来我们就能看到Grafana强大的图形能力了
接下来我们到grafana中添加对应的模板，可以将之前那个模板删掉，我们去寻找适应的模板
导入 dashboard
从 grafana 官网下载相关 dashboaed 到本地，如: https://grafana.com/
Grafana 首页--> 页面顶部-->Dashboards--> 页面左边 Filter by-选择仪表盘 prometheus
可以直接复制id到导入那一步,复制他自己会导入json
此处也可以直接写id,过一会他自己就能加载模板了
如果有需要，我们可以安装饼形插件
# 使用新的grafana-cli工具从命令行安装piechart-panel：
grafana-cli plugins install grafana-piechart-panel
# 该插件将安装到您的grafana插件目录中; 如果安装了grafana软件包，则默认在/var/lib/grafana/plugins
cd /var/lib/grafana/plugins/
但是因为我们之前自定义了目录，所以要将插件放到配置文件中定义的插件目录位置
mv /var/lib/grafana/plugins/* /data/grafana/plugins/
# 重启grafana
systemctl restart grafana-server
# 这样dashboard中的饼图就可以正常展示出来了，可能需要一点时间缓冲
