Beginner prometheus monitoring (1)

1. Introduction to promethues

1.1 Classification of monitoring

Monitoring importance from high to low

Business monitoring: Indicators that company leaders are more concerned about, such as the number of orders on e-commerce platforms, daily activities of users, etc.

System monitoring: mainly the basic monitoring items related to the operating system, such as CPU, memory, hard disk, IO, TCP connection, traffic, etc.

Network monitoring: The monitoring of network status (switches, routers, firewalls, VPNs, etc.) is essential for Internet companies, but it is often ignored. delay and so on.

Log monitoring: The highlight of monitoring is often designed and built separately. All types of logs need to be collected. Common solutions include Elstic stack (free version), Splunk (paid version), etc.

Program monitoring: Generally, it is necessary to cooperate with developers to embed various interfaces in the program to directly obtain data or special log formats.

1.2 Advantages of promethues

Prometheus is an open source complete monitoring solution, which has completely subverted the testing and alarming models of traditional monitoring systems, forming a new model based on centralized rule calculation, unified analysis and alarming.

Compared with the traditional monitoring system Prometheus has the following advantages:

easy to manage

The core part of Prometheus is only a single binary file, without any third-party dependencies (database, cache, etc.). The only thing required is a local disk, so there is no risk of a potential cascading failure.

Based on the architecture of the Pull model, Prometheus can build our monitoring system anywhere (local computer, development environment, test environment). For some complex situations, you can also use the Prometheus service discovery (Service Discovery) capability to dynamically manage monitoring targets.

Monitor the internal health status of the service

Pometheus encourages users to monitor the internal status of services. Based on the rich client library of Prometheus, users can easily add support for Prometheus to applications, so that users can obtain the real running status of services and applications.

time series

The so-called time series (time series) refers to a series of ordered data, usually refers to the sampling data at equal time intervals. Axes are ordered numbers.

powerful data model

All collected monitoring data are stored in the built-in time series database (TSDB) in the form of metrics. In addition to the basic index name, all samples also contain a set of tags used to describe the characteristics of the sample.

Powerful query language PromQL

Prometheus has a built-in powerful data query language PromQL. The query and aggregation of monitoring data can be realized through PromQL. At the same time, PromQL is also used in data visualization (such as Grafana) and alarms.

PromQL can easily answer questions similar to the following:
1>. What is the distribution range of 95% application latency in the past period of time?
2>. Predict what will happen to the disk space usage after 4 hours?
3>. What are the top 5 services with CPU usage? (filter)

efficient

For a monitoring system, a large number of monitoring tasks will inevitably lead to a large amount of data. Prometheus can efficiently process these data. For a single Prometheus Server instance, it can handle: millions of monitoring indicators and processing hundreds of thousands of data points per second. And zabbix is relatively difficult for this;

Scalable (support cluster)

Prometheus is so simple that you can run independent Prometheus Sevrer per data center, per team.

Prometheus's support for federated clusters allows multiple Prometheus instances to generate a logical cluster. When a single instance of Prometheus Server handles too many tasks, it can be expanded by using functional partitioning (sharding) + federation clustering (federation).

easy to integrate

使用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来让你的应用程序支持监控数据采集。

Prometheus除了上述说到的优点，其实也有以下不足之处:

学习成本太大，尤其是其独有的数学命令行，学习起来很吃力，而且全是英文文档;

对磁盘资源也是耗费的较大，这个具体要看监控的集群量和监控项的多少和保存时间的长短;

有网友称在1.x版本中可能会发生数据丢失的风险，因此生产环境中建议大家使用较新的2.x发行版;

温馨提示:

zabbix采用的是MySQL数据库，Prometheus采用的是时间序列数据库，由于监控数据并不需要更新，监控数据会存在大量的写入和查询，其底层实现会更高，具体细节原理可自行查阅资料，Prometheus是支持外部数据库存储的，但我觉得完全没有必要在生产环境中这样做;

如果上述10点还不足以打动你学习Prometheus，那我再说一点比较现实的，国内目前很多中小企业都在使用Prometheus监控docker，Kubernetes，学习它有助于咱们找工作。

1.3 promethues 使用场景

适用的场景(When does it fit?)

Prometheus适用于记录任何纯数字时间序列。它既适合以机器为中心的监控，也适合监控高度动态的面向服务的架构。在微服务的世界中，它对多维数据收集和查询的支持是一个特殊的优势。

Prometheus是为可靠性而设计的，它是您在中断期间访问的系统，让您能够快速诊断问题。每个 Prometheus服务器都是独立的，不依赖于网络存储或其他远程服务。当基础架构的其他部分损坏时，您可以依赖它，并且您无需设置大量基础架构即可使用它。(请记住该点，这是优点也是缺点哟~)

不适用的场景(When does it not fit?)

如上所示，Prometheus重视可靠性。即使在出现故障的情况下，您也可以随时查看有关系统的可用统计信息。

如果您需要100%的准确性，例如按请求计费，Prometheus不是一个好的选择，因为收集的数据可能不够详细和完整。在这种情况下，您最好使用其他系统来收集和分析计费数据，并使用Prometheus进行其余的监控。

1.4 promethues 宏观架构图

图片.png-501.8kB

如下图所示，展示了普罗米修斯(prometheus)的建筑和它的一些生态系统组成部分。

Prometheus server:

prometheus的服务端，负责收集指标和存储时间序列数据，并提供查询接口。

exporters:

如果想要监控，前提是能获取被监控端数据，并且这个数据格式必须遵循Prometheus数据模型，这样才能识别和采集，一般使用exporter数据采集器(类似于zabbix_agent端)提供监控指标数据。

exporter数据采集器，除了官方和GitHub提供的常用组件exporter外，我们也可以为自己自研的产品定制exporters组件哟。

Pushgateway:

短期存储指标数据，主要用于临时性的任务。比如备份数据库任务监控等。

本质上我们可以理解为Pushgateway可以帮咱们监控自定义的监控项，这需要咱们自己编写脚本来推送到Pushgateway端，而后由Prometheus
server从Pushgateway去pull监控数据。

换句话说，请不要被官方的架构图蒙骗了，咱们完全可以基于Pushgateway来监控咱们自定义的监控项哟，这些监控项完全可以是长期运行的呢！

Service discovery:

服务发现，例如我们可以配置动态的服务监控，无需重启Prometheus server实例就能实现动态监控。

Alertmanager:

支持报警功能，比如可以支持基于邮件，微信，钉钉报警。

据网友反馈该组件在生产环境中存在缺陷，因此我们可以考虑使用Grafana来展示并实现报警功能。

Prometheus Web UI

Prometheus比较简单的Web控制台，通常我们可以使用grafana来集成做更漂亮的Web展示哟。

温馨提示:
大多数Prometheus组件都是用Go编写的，这使得它们易于构建和部署为静态二进制文件。

2、部署服务端

Prometheus包下载链接图片.png-302.1kB

2.1 下载安装包

[root@prometheus ~]# wget https://github.com/prometheus/prometheus/releases/download/v2.44.0/prometheus-2.44.0.linux-amd64.tar.gz

2.2 解压启动

[root@prometheus ~]# tar xf prometheus-2.44.0.linux-amd64.tar.gz
[root@prometheus ~]# mv prometheus-2.44.0.linux-amd64 /usr/local/prometheus

2.3 编辑配置文件

[root@prometheus ~]# vim /usr/local/prometheus/prometheus.yml
[root@prometheus ~]# cat /usr/local/prometheus/prometheus.yml
#全局配置
global:
#设置prometheus采集数据的间隔时间，默认是1分钟。通常该值设置15秒就够用了。如果设置的间隔时间过短可能会造成更多的存储空间哟。
  scrape_interval: 30s
#监控数据规则的评估评论，默认值为每1分钟。通常该值设置每15秒评估一次规则就够用了。
  evaluation_interval: 30s

# Alertmanager configuration(先战略性忽略)

# 抓取数据的配置 
scrape_configs:
#定义任务的名称
  - job_name: "prometheus"
    #定义静态的配置，比如使用targets指定要监控的对象
    static_configs:
      - targets: [localhost:9100]

#定义基于文件的动态配置，比如使用files指定文件路径，使用refresh_interval指定监控的间隔时间
#      - file_sd_configs:

  - job_name: "ceshi"
    static_configs:
      - targets: [192.168.200.15:9100]

有关自动发现的配置

azure_sd_configs

consul_sd_configs

dns_sd_configs

ec2_sd_configs

openstack_sd_configs

file_sd_configs

gce_sd_configs

kubernetes_sd_configs

marathon_sd_configs

nerve_sd_configs

serverset_sd_configs

triton_sd_configs

2.4 使用后台启动

[root@prometheus ~]# cd /usr/local/prometheus/
[root@prometheus prometheus]# nohup ./prometheus &>/var/log/prometheus.log &

3、部署node exporter 客户端监控软件

3.1 安装包下载

node exporter包下载链接

图片.png-196.5kB

[root@prometheus 1]# wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz

3.2 解压使用

[root@prometheus ~]# tar xf node_exporter-1.6.0.linux-amd64.tar.gz 
[root@prometheus ~]# mv node_exporter-1.6.0.linux-amd64 /usr/local/node_exporter

3.3 后台启动

[root@prometheus ~]# cd /usr/local/node_exporter/
[root@prometheus node_exporter]# nohup ./node_exporter &>/var/log/node_exporter.log &

3.4 查看监控数据

http://192.168.200.15:9090/targets?search=

图片.png-126.5kB

3.5 查看node exports 实例采集的metrics指标

访问：http://192.168.200.15:9100/metrics

图片.png-259.8kB

官方文档：

默认启用的采集器:https://github.com/prometheus/node_exporter#enabled-by-default

默认禁用的采集器:https://github.com/prometheus/node_exporter#disabled-by-default

温馨提示:对于中小型企业，推荐大家使用默认的采集器启用的采集器即可，基本上也够咱们使用了，除非你要开启监控一些特殊的数据，可以启用对应的采集器。

3.6 metrics 简单介绍

3.6.1 metrics 简单介绍

在Prometheus监控中，对于采集到服务端的指标数据，统一称为metrics数据。

metrics是一种对采样数据的总称，其并不代表一种具体的数据格式，而是一种对于度量计算单位的抽象。

当我们需要为某个系统或者某个服务做监控，统计时，就需要用到metrics。

metrics指标为时间序列数据，它们按相同的时序，以时间维度来存储连续数据的集合。

3.6.2 metric格式

prometheus采集回来的指标数据(metric)是以key/value格式存储和展示可以通过curl localhost:9100/metrics获取key/value 值，如下:

[root@prometheus ~]# curl localhost:9100/metrics
...略...
node_cpu_seconds_total{cpu="0",mode="user"} 1.78
node_cpu_seconds_total{cpu="1",mode="idle"} 10053.3
node_cpu_seconds_total{cpu="1",mode="iowait"} 0.3
node_cpu_seconds_total{cpu="1",mode="irq"} 0
node_cpu_seconds_total{cpu="1",mode="nice"} 0.07
node_cpu_seconds_total{cpu="1",mode="softirq"} 0.28
node_cpu_seconds_total{cpu="1",mode="steal"} 0
node_cpu_seconds_total{cpu="1",mode="system"} 7.34
node_cpu_seconds_total{cpu="1",mode="user"} 6.3
node_cpu_seconds_total{cpu="2",mode="idle"} 10044.33
node_cpu_seconds_total{cpu="2",mode="iowait"} 0.05
node_cpu_seconds_total{cpu="2",mode="irq"} 0
node_cpu_seconds_total{cpu="2",mode="nice"} 0.03
node_cpu_seconds_total{cpu="2",mode="softirq"} 0.57
...略...

3.6.3 Metric类型

Prometheus的时序数据分为Gauge(仪表盘)，Counter(计数器)，Histogram(直方图)。

Gauge类型:

Gauge类型的指标用于展示瞬时的值，只有一个简单返回值，例如CPU、内存、硬盘容量等，用来反映目标在某个时间点的状态。

Counter类型

counter类型的指标与计数器一样，从0开始不断积累，趋势线上升或水平，如用户访问累积量、服务请求总量、错误总数等。

Histogram 类型

Histogram 统计数据的分布情况。比如最小值，最大值，中间值，中位数。75%，90%，92%，99.9% ，百分位值。特殊的 Metrics 数据类型，比例型数据，百分比估算数值。

如我们平时用的比较多的针对请求响应时间的90线、95线，对于90分为值也就是P90，我们简单的可以这样理解，假设有100个请求，按照响应时间从小到大排序，第90个请求的响应时间3000ms就是P90值，也就是说有90%的请求响应时间小于3000ms。

4、 promethues 服务自动发现

我们在添加客户端后，每次需要手动去重启peomethues 服务端，这种方式是基于静态配置。使用promethues 自动发现(动态配置)，则不需要重启服务端。

4.1 添加测试机器(以容器为例)

[root@prometheus ~]# docker images
REPOSITORY                         TAG       IMAGE ID       CREATED      SIZE
quay.io/prometheus/node-exporter   latest    173d3570a5af   3 days ago   22.7MB

[root@prometheus ~]# docker container run -dp 19100:9100 -v "/:/host:ro,rslave" --name=node_exporter2 quay.io/prometheus/node-exporter:latest --path.rootfs /host

4.2 编辑promethues.yml文件

[root@prometheus ~]# vim /usr/local/prometheus/prometheus.yml 
[root@prometheus ~]# cat /usr/local/prometheus/prometheus.yml
global:
  scrape_interval:     30s
  evaluation_interval: 30s

#基于文件实现动态配置
scrape_configs:
  - job_name: "auto_discovery_node_exporter"
    file_sd_configs:
    - files:
      - /usr/local/prometheus/discovery/node_exporter.yml
      #刷新间隔
      refresh_interval: 5s

#编辑自动发现文件
[root@prometheus ~]# mkdir -p /usr/local/prometheus/discovery
[root@prometheus ~]# vim /usr/local/prometheus/discovery/node_exporter.yml
[root@prometheus ~]# cat /usr/local/prometheus/discovery/node_exporter.yml
[
  {
    "targets":  ["192.168.200.15:19100"]
 # 可监控多个
 # "targets":  ["192.168.200.15:8080","192.168.200.15:18080"]
  }
]

4.3 重启promethues

# kill掉旧进程
[root@prometheus ~]# ps -ef|grep prometheus|grep -v grep|awk '{print $2}'|xargs -i kill -9 {}

# 重启promethues
[root@prometheus ~]# cd /usr/local/prometheus/
[root@prometheus prometheus]# nohup ./prometheus &>/var/log/prometheus.log &

后期就不用再次重启配置文件了，只需要修改/usr/local/prometheus/discovery/node_exporter.yml
promethues 会每隔5s读取文件(refresh_interval: 5s)

图片.png-108.3kB

4.4 cadvisor 容器的自动发现

4.4.1 cadvisor 容器介绍

docker stats 可以查看容器的运行状态，但是数据比较原始且没有界面，数据可视化还需要做大量的工作

[root@prometheus ~]# docker stats node_exporter2

CONTAINER ID   NAME             CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O   PIDS
7e3f17d58d01   node_exporter2   0.00%     11.84MiB / 3.682GiB   0.31%     14.7kB / 232kB   0B / 0B     5

CONTAINER ID   NAME             CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O   PIDS
7e3f17d58d01   node_exporter2   0.00%     11.84MiB / 3.682GiB   0.31%     14.7kB / 232kB   0B / 0B     5

CONTAINER ID   NAME             CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O   PIDS
7e3f17d58d01   node_exporter2   0.00%     11.84MiB / 3.682GiB   0.31%     14.7kB / 232kB   0B / 0B     5

4.4.2 cadvisor 容器启动

[root@prometheus ~]# docker run \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:rw \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --volume=/dev/disk/:/dev/disk:ro \
  --publish=18104:8080\
  --detach=true \
  --name=cadvisor \
  google/cadvisor:latest

4.4.3 cadvisor 使用介绍

cadvisor部分界面如下:

图片.png-127kB

grafana容器内CPU，内存，网络，磁盘信息

图片.png-145.3kB

图片.png-117.5kB

4.4.4 结合promethues 动态配置(file_sd_configs)使用

配置promethues 动态发现

[root@prometheus ~]# cat /usr/local/prometheus/discovery/node_exporter.yml
[
  {
    "targets":  ["192.168.200.15:19100","192.168.200.15:18104"]
  }
]

查看数据

图片.png-77.5kB

图片.png-164.9kB