01 . Prometheus简介及安装配置Grafana

时间  2020-05-09
标签 prometheus 简介 安装 配置 grafana 繁體版
原文   原文链接

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+项的第三方集成。

image.png

监控的目标

在《SRE: Google运维解密》一书中指出，监控系统须要可以有效的支持白盒监控和黑盒监控。经过白盒可以了解其内部的实际运行状态，经过对监控指标的观察可以预判可能出现的问题，从而对潜在的不肯定因素进行优化。而黑盒监控，常见的如HTTP探针，TCP探针等，能够在系统或者服务在发生故障时可以快速通知相关的人员进行处理。经过创建完善的监控体系，从而达到如下目的：node

1 . 长期趋势分析：经过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，经过对磁盘空间增加率的判断，咱们能够提早预测在将来什么时间节点上须要对资源进行扩容。python

2 . 对照分析：两个版本的系统运行资源使用状况的差别如何？在不一样容量状况下系统的并发和负载变化如何？经过监控可以方便的对系统进行跟踪和比较。mysql

3 . 告警：当系统出现或者即将出现故障时，监控系统须要迅速反应并通知管理员，从而可以对问题进行快速的处理或者提早预防问题的发生，避免出现对业务的影响。linux

4 . 故障分析与定位：当问题发生后，须要对问题进行调查和处理。经过对不一样监控监控以及历史数据的分析，可以找到并解决根源问题。ios

5 . 数据可视化：经过可视化仪表盘可以直接获取系统的运行状态、资源使用状况、以及服务运行状态等直观的信息。nginx

与常见监控系统比较
  • 对于常见的监控系统，如Nagios、Zabbix的用户而言，每每并不能很好的解决上述问题。这里以Nagios为例，以下图所示是Nagios监控系统的基本架构:

image.png

  • Nagios的主要功能是监控服务和主机。Nagios软件须要安装在一台独立的服务器上运行，该服务器称为监控中心,每一台被监控的硬件主机或者服务都须要运行一个与监控中心服务器进行通讯的Nagios软件后台程序，能够理解为Agent或者插件。

image.png

  • 首先对于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的要求比较高.git

InfluxDB至关不错，但其杀手锏功能相似于集群化之类的，都是付费版本才有的，且其维护基于单一的商业公司（言下之意，若是你不用商业版，其实InfluxDB也没有什么特别大的优点，并且仍是单一公司维护有风险,）github

Graphite和Prometheus比起来，Prometheus功能更丰富强大.web

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 则是销毁重建，对监控系统可能会有一些新的影响。

image.png

强大的数据模型
  • 全部采集的监控数据均以指标(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组件

image.png

image.png

  • 上图为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类：

  1. 直接采集：这一类Exporter直接内置了对Prometheus监控的支持，好比cAdvisor，Kubernetes，Etcd，Gokit等，都直接内置了用于向Prometheus暴露监控数据的端点。
  2. 间接采集：间接采集，原有监控目标并不直接支持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并配置Grafana

Prometheus基于Golang编写，编译后的软件包，不须要依赖第三方依赖，用户只须要下载对应平台的二进制包，解压而且添加基本的配置便可正常启动Prometeus Server。

二进制安装Prometheus

下载二进制包并解压

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

image.png

安装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状态

image.png

  • 接下来咱们能够经过访问node_exporter那个节点的IP:9100 访问到如下页面:
    image.png

image.png

  • 咱们能够看到当前主机的全部监控数据.可是每个指标以前都有以下形式的信息

image.png

# 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采集到的主机负载的样本数据，这些样本数据按照时间前后顺序展现，造成了主机负载随时间变化的趋势图表：
    image.png

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
mkdir /data/grafana/plugins
mkdir /data/grafana/provisioning
mkdir /data/grafana/data
mkdir /data/grafana/log
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

image.png

添加数据源
* grafana虽然已经安装好了，可是这个时候尚未数据，没办法做图。
* 下面咱们把grafana和prometheus关联起来，也就是在grafana中添加添加数据源。
* 在配置页面点击添加数据源，而后选择prometheus，输入prometheus服务的参数便可。

image.png

image.png

image.png

添加自带的示例图表
  • 按照上面的指导添加数据源以后，咱们就能够针对这些数据来绘制图表了。grafana最人性化的一点就是拥有大量的图表模板，咱们只须要导入模板便可，从而省去了大量的制做图表的时间。
  • 目前咱们的prometheus尚未什么监控数据，只有prometheus自己的数据，咱们看下这些prometheus自己数据图表是怎样的。
  • 在添加数据源的位置上，右边的选项有个Dashboards的菜单选项，咱们点击进去，而后导入prometheus2.0.
    image.png
  • 接下来咱们就能看到Grafana强大的图形能力了
    image.png

接下来咱们到grafana中添加对应的模板，能够将以前那个模板删掉，咱们去寻找适应的模板

image.png

image.png

image.png

image.png

image.png

  • 导入 dashboard
  • 从 grafana 官网下载相关 dashboaed 到本地，如: https://grafana.com/
  • Grafana 首页--> 页面顶部-->Dashboards--> 页面左边 Filter by-选择仪表盘 prometheus

image.png

image.png

image.png

image.png

image.png

image.png

若是有须要，咱们能够安装饼形插件

# 使用新的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中的饼图就能够正常展现出来了，可能须要一点时间缓冲

image.png

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程