监控的基础理念

监控在企业中的重要性

追溯到监控不发达的时代，那时候基本数以一个出行基本靠走，安全基本靠狗

记得2006年我刚刚开始做运维的时候，哪里有什么自动化监控的概念

至少都是人工盯着，服务器大概2，3台的样子放在一个比较简陋的机房里，所有的服务区都接着单独的显示器运行着

每天上班第一件事就是走进去巡视以下，看看各种软件打印出来的输出信息是否有报错，如果有就拿个excel记录下再邮件发给老板想起来都觉得臊得慌

不过其实在那个年代也是没有办法 运维半身就很原始，各种运维技术都处于拓荒得阶段

如今得企业中 动不动运维就要负责成败上千甚至上万机器 没有高大上得方法是绝对支撑不起来这种规模得监控得

服务器随时随地都有可能出故障，出问题，需要被监控住，不管是虚拟机还是物理机还是各种软件，各种线上产品，操作系统，网络设备，办公环境，业务数据，用户体验

说句夸张点得话：现在连员工上个班 打卡机都得弄个监控，打卡机自己本身可能会坏，打卡记录还得被hr监控

各种监控啊~都是运维得事啊~

监控在企业中扮演着重要得监督者得角色，任何一个地方出现问题 我们都需要及时得知道 很多情况下企业对某种类型得监控 需要非常得敏感，例如用户正常访问这种业务级别得监控一旦出现了问题 需要在秒级得时间立刻知道不然就是毁灭性得灾难和损失尤其是针对那些大规模得企业

所以说 监控对于企业得重要性 不言而喻了

监控在运维工作中的比重

基础运维主要扮演者一个处理日常任务，及时救火 这样的角色

而监控的搭建和数据采集的工作 很多时候需要依赖于 运维开发的协助

不管是哪一种运维(哪怕你是运维架构师 运维专家) 在紧急的时候 人人都要扮演起 救火英雄的角色

而救火 指的是 及时的发现和解决 线上出现的各种故障 问题

那么为了要做到及时的发现问题，那么一个好的完善的监控系统就很自然的作为 运维工作中的第一优先级任务 一个最理想的 完整的 监控体系的搭建 有赖于如下几个方面的工作以及流程

监控分类

prometheus入门简介

prometheus是一个开源系统监控和报警的工具集合，有SoundCloud创建(http://soundclound.com/),自2012诞生后，至今已经有很多公司和组织开始使用它了，这个开源项目拥有大量的积极参与开发和建设的研发人员以及社区用户，目前已经是一个独立运行的开源的由各公司自行维护的监控项目。为了让项目更重试更清晰，2016年prometheus加入cloudnative computing fondation(CNCF),并且成为继Kubernets之后第二个加入该组织的成员

这个就是来自于官方的介绍

其中更多突出的还是这个项目基于开源的各种社区组织维护多重联合开发的这样一个特性 也就决定了这个项目必然是越来越好

认识prometheus监控的优质特性

基于time series时间序列模型

时间序列{time series X,Y}是一系列有序的数据。通常是等时间间隔的采样数据。

基于K/V的数据模型

Key/value这个键值的概念 咱们很熟悉{disk_size: 80G} 最大的好处就是数据格式简单速度快易维护开发

采样数据的查询 完全基于数学运算 而不是其他的表达式 并提供专有的查询输入console

这个特点很独特，所有的查询都基于数学运算公式，例如（增量(A) + 增量(B)) / 总增量(C) > 固定百分比

采用 http pull/push两种对应的数据采集传输方法

所有的数据采集 都基本采用http，而且分为pull push推和拉两种方法去写采集程序 方便

开源，且大量的社区成品插件

这个非常厉害，https://prometheus.io 很多prometheus社区开发的差距已经异常强大和完善 如果公司对监控要求不是特别高的话，默认的几个成品插件 装上就可以用到底了 监控成型速度太快了

push的方法非常灵活

pull push的方法往后会具体介绍，这里可以提一句

本身自带图形调试

prometheus查询语句本身就带了现成的图形成型界面 虽然最终肯定不能跟grafana的效果相比，但是 这种自带图形成图可以大大帮助运维做调式

最精细的数据采样

大多数市面上的开源监控 采样也就能精确到 半分钟 一分钟的程度 prometheus理论上可以达到每秒采集！！而且可以自行定制频率

最新的高大上监控，很霸气，面试很有料

prometheus还是有一些不足有待于改进：

不支持集群化

被监控集群过大后 本身性能有一定瓶颈

中文支持不好，中文资料也很少

prometheus对于运维的要求

要求对操作系统有很深扎实的知识 不能知识浮在表面

对数学思维有一定的要求 因为他的基本的内核就是学习数学公式组成

对于监控的经验有很高的要求 很多时候 监控项需要很细的定制

prometheus各种图形展示

prometheus主界面

prometheus数学查询命令行展示

prometheus配置展示

prometheus targets展示(被监控节点)

prometheus + grafana 监控CPU展示

prometheus运行框架介绍

Prometheus Server

这部分是prometheus的服务端 也就是核心

prometheus本身是一个进程方式启动，之后以多进程和多线程实现监控数据收集 计算 查询 更新 存储的这样的一个C/S模型运行模式

本身的启动很简单，如果不带参数 不考虑后台运行的问题 那么默认prometheus启动

在下载完prometheus二进制包后解压，解压后./prometheus即可 之后默认监听端口9090端口 用来访问，当然我这里是把prometheus服务用脚本的方式启动启动之后使用chkconfig --add方式给加入到service里

/etc/rc.d/init.d/prometheus

#!/bin/bash
#
# /etc/rc.d/init.d/prometheus
#
#  Prometheus server
#
#  description: Prometheus server
#  processname: prometheus

# Source function library.
. /etc/rc.d/init.d/functions

PROGNAME=prometheus
PROG=/opt/prometheus/$PROGNAME
USER=root
LOGFILE=/var/log/prometheus.log
LOCKFILE=/var/run/$PROGNAME.pid

start() {
    echo -n "Starting $PROGNAME: "
    cd /opt/prometheus/
    daemon --user $USER --pidfile="$LOCKFILE" "$PROG &>$LOGFILE &"
    echo $(pidofproc $PROGNAME) >$LOCKFILE
    echo
}

stop() {
    echo -n "Shutting down $PROGNAME: "
    killproc $PROGNAME
    rm -f $LOCKFILE
    echo
}


case "$1" in
    start)
    start
    ;;
    stop)
    stop
    ;;
    status)
    status $PROGNAME
    ;;
    restart)
    stop
    start
    ;;
    reload)
    echo "Sending SIGHUP to $PROGNAME"
    kill -SIGHUP $(pidofproc $PROGNAME)
    ;;
    *)
        echo "Usage: service prometheus {start|stop|status|reload|restart}"
        exit 1
    ;;
esac

接下来看看prometheus的存储形式

翻译下官网对prometheus存储数据的介绍

prometheus采用的是time-series(时间序列)的方式 以一种自定义的格式存储在本地硬盘上

prometheus的本地t-s数据库会以每两个小时为间隔来分block存储，每一个块中又分为多个chunk文件，chunk文件是用来存放采集过来的数据的t-s数据，metadata和索引文件

index文件是对metrics(prometheus中一次k/v采集数据叫做一个metric)和labels(标签)进行索引 之后储存在chunk中 chunk是作为存储的基本单位，index and matadata是作为子集

prometheus平时是将采集过来的数据先都存放在内存中 以类似缓存的方式用于加速搜索和访问

当出现宕机时，prometheus有一种保护机制，叫做WAL 可以讲数据定期存入硬盘中 以chunk来表示，并在重新启动时用以恢复进入内存

Servevice Discovery

prometheus本身跟其他的开源软件类似 也是通过定义配置文件 来给prometheus本身规定需要被监控的项目和被监控节点

我们看下配置文件的模板

配置文件中规定了一个大的Job名字

之后在这个jobs名字下面 具体来定义要备监控的节点 以及节点上的具体的端口信息等等

那么如果prometheus配合了例如consul这种服务发现软件

prometheus的配置文件就不再需要人工去定义出来， 而是能自动发现集群中有哪些新机器以及新机器上出现了那些新服务可以被监控

采集客户端部分

prometheus的客户端主要有两种方式采集数据

pull 主动拉取的形式

push 被动推送的形式

pull:指的是 客户端(被监控机器)先安装各类已有exports在系统上，exporters以守护进程的模式 运行并开始采集数据

exporter 本身也是一个http_server可以对http请求作出响应返回数据

prometheus用pull这种主动拉的方式去访问每个节点上exporter并采样回需要的数据

push

指的是 在客户端安装这个官方提供的pushgateway插件

然后 使用我们运维自行开发的各种脚本 把监控数据组织成k/v的形式 metrics形式发送给pushgateway

之后pushgateway会再推送给prometheus

这种是一种被动的数据采集方式

Alertmanager报警部分

这个目前用的少

Prometheus监控数据格式

prometheus监控中 对于采集过来的数据统一称为metrics数据

mertrics 是一种对采样数据的总称

咱们来介绍一下metrics的几种主要的类型

Gauges

最简单的度量指标，只有一个简单的返回值， 或者叫瞬时状态，例如 我们想衡量一个待处理队列中任务的个数

用更简单的方式举个例子

例如：如果我要监控硬盘容量或者内存的使用量，那么就应该使用Gauges的metrics格式来度量

因为硬盘的容量或者内存的使用量 是随着时间的推移 不断的瞬时变化的

Counters

Counter就是计数器，从数据量0开始累积计算 在理想状态下 只能是永远的增长 不会降低

举个例子来说

比如对用户访问量的采样数据

我们的产品被用户访问一次就是1，过了10分钟后累积到100，过一天后累积到20000

Histograms

Histogram统计数据的分布情况，比如最小值，最大值，中间值，还有中位数，75百分位，90百分位的值

这是一种特殊的metrics数据类型，代表的是一种近似的百分比估算数值

 K/V的数据形式

我们   之前了解了metrics的概念和类型 prometheus的数据类型就是依赖于这种metrics的类型来计算的

而对于采集回来的数据类型 再往细了说 必须要以一种具体的数据格式 供我们查看和使用

那么我们来看一下 一个exporter给我们采集来的 服务器上的k/v形式metrics数据 当一个exporter被安装和运行在被监控的服务器上后 使用简单的curl命令 就可以看到exporter办公我们采集到metrics数据的样子，以k/v的形式展现和保存

如上图所示 curl之后的结果输出

带 # 的行是注释行 用来解释下面的k/v是什么采样数据

exporter的使用

官网Download | Prometheus 提供了丰富的成型exporters插件可以使用

下载首页其实就已经提供了很多很常用的exporters 这些exporters分别使用了不同的开发语言开发，有go，java，python，ruby等等

我们不关心社区组织 用什么语言做的开发 我们只要关心 如何下载和正确安装使用即可

大多数exporters 下载之后就提供了启动的命令 一般直接运行 带上一定的参数就可以了

pushgateway的概念介绍

之前说的exporter是首先安装在被监控服务器上运行在后台然后自动采集系统数据 ，本身又是一个HTTP_server 可以被prometheus定时http get取得数据属于pull的形式

如果把这个过程反过来 push的形式就是把pushgateway安装在服务端

pushgateway本身也是一个http服务器 运维通过写自己的脚本程序抓自己想要的监控数据 然后推送到pushgateway 再由pushgateway推送到prometheus服务端 是一个反过来的被动模式

一个问题？为什么已经有了那么强大的pull形式的exporter采集还需要一个pushgateway的形式呢

其实对这个问题的回答是：

exporter虽然采集类型已经很丰富了，但是我们依然需要很多自制的监控数据 非规则化的 自定制的

exporter由于数据类型采集量打 其实很多数据 或者说大部分数据 其实我们监控真的用不到 用pushgateway是定义一项数据就采集一种节省资源

一个新的自定义的pushgateway脚本开发远远比开发一个全新的exporter简单快的多的多的多

exporer虽然已经很丰富了，但是依然有很多的我们需要的采集形式，exporter无法提供， 或者说现有的exporter还不支持， 到那时如果使用pushgateway的形式 就可以任意灵活 想做什么都可以做到 而且极快

Prometheus初探和配置

之前我们说过，相对于较难的使用方法，prometheus其实安装的过程反而是异常的简单

准备

安装Prometheus之前我们必须先安装ntp时间同步(prometheus T_S对系统时间的准确性要求很高，必须保证本机时间实时同步)

以Centos7为例：

timedatectl set-timezone Asia/Shanghai

crontab定时同时时间

* * * * * ntpdate -u cn.pool.ntp.org

下载tar包

首先 我们去prometheus.io官网

下载版本包,这里我用的是prometheus-2.28.1.linux-amd64.tar.gz

解压后就这些了

Prometheus启动和后台运行

启动也很简单

./prometheus

之后默认运行在9090

浏览器可以直接打开访问 无账号密码验证(如果希望加上验证，可以使用类似apache httppass方式添加)

使用nginx的auth_basic实现prometheus安全认证

安装httpd-tools工具

yum -y install httpd-tools
cd /opt/
htpasswd -c .ht.passwd promauth

交互过程中，记住设定的密码，这里设定的密码是promauth，生成的passwd文件需要分发到所有需要使用验证功能的机器上。

配置启动prometheus

在配置文件加入要监控的exporter配置，targets要只想nginx上开放的端口，basic_auth要写刚刚设定的用户密码。

启动prometheus

./prometheus --config.file=prometheus.yml --web.listen-address=127.0.0.1:9090

exporter

在10.0.0.57上执行

./node_exporter

nginx配置

注意:

在需要认证的机器上，都要有前几部使用httpasswd生成的文件/opt/.ht.passwd，没有这个文件nginx会报错。

10.0.0.62上在nginx配置文件中添加认证配置

cat > /etc/nginx/conf.d/prom.conf << EOF
        server {
        listen 9000;
        location / {
            auth_basic "promauth";
            auth_basic_user_file "/opt/.ht.passwd";
            proxy_pass  http://localhost:9090/;
           }
    }
EOF

10.0.0.57上在nginx配置文件中添加认证配置

cat > /etc/nginx/conf.d/prom.conf << EOF
        server {
        listen 9000;
        location / {
            auth_basic "promauth";
            auth_basic_user_file "/opt/.ht.passwd";
            proxy_pass  http://localhost:9100/;
           }
    }
EOF

重载配置文件后，浏览器访问9000端口，ngx会验证用户信息，成功后请求转发到prometheus监听的9090端口上

查看prometheus的web页面上的targets可以看到10.0.0.57的信息。

如果状态为down，需要检查端口nginx代理，认证信息是否正确

接下来我们来简单看下Prometheusde 的主配置文件

my global config

前了两个全局变量

scrape_interval 抓取采样数据的时间间隔，默认是15秒去被监控机上采样一次

这个就是我们所说的prometheus的自定义数据采集频率了

evaluation_interval.监控数据规格的评估频率 这个参数是prometheus 多长时间会进行一次监控规则的评估

Alertmanager是prometheus的一个用于管理和发出报警的插件

我们这里对Alertmanager暂时先不做介绍，暂时不需要(我们采用4.0最新版的Grafana，本身就已经支持报警发出功能了 往后我们会学习到)

再往后 进入prometheus重要的配置采集节点的设置了

搭建expoerter采样数据

我们就选用企业中最常用的node_exporter这个插件

node_exporter之前介绍过，是一个以http_server方式运行在后台，并且持续不断采集linux系统中 各种操作系统本身相关的监控参数的程序 其采集量是很大很全的，往往默认的采集项目 就远超过你的实际需求

下载node_exporter从官网

Download | Prometheus

下载后解压缩 然后直接运行即可

Prometheus命令行使用扩展

prometheus命令行格式

这次我们选用一个新的key来做讲解，count_nestat_wait_connections(TCP wait_connect 数)

这个key值得一说的是 并不是由我们熟悉的node_exporter挖掘而来

而是我们自行定义并且使用bash脚本+pushgateway的方法推送到promrtheus server采集

pushgateway下载安装

Download | Prometheus

后台运行pushgateway

cd /opt/prometheus/pushgateway-1.6.0.linux-amd64
nohup ./pushgateway &

编辑prometheus主配置文件prometheus.yml

重启prometheus

访问Pushgateway

编写自定义脚本将监控数据推送给pushgateway

vim /usr/local/waiting_connection.sh

#!/bin/bash
instance_name=`hostname -f` # instance_name 取出主机名

if [ $instance_name == "localhost" ];   #要求主机名不能是 localhost，没法区分
then
echo "Mush FQDN hostname"
exit 1
fi

#For waitting connections

label="count_netstat_wait_connections"  # 定义 prometheus 命令行标签

count_netstat_wait_connections=`netstat -anpt | grep -i wait | wc -l`   #定义一个新的数值，统计 TCP_WAIT 的连接数

echo "$label:$count_netstat_wait_connections" # 输出格式：key/value(标签:取出的数值)


echo "$label  $count_netstat_wait_connections" | curl --data-binary @-  http://192.168.168.11:9091/metrics/job/pushgateway/instance/$instance_name

#最后把 key/value 推送给 pushgateway
#curl --data-binary : 将 HTTP POST请求中的数据发送给 pushgateway 服务器，与用户提交HTML表单时浏览的行为完全一样。
#HTTP POST 请求中的数据为纯 二进制数据。

手动执行脚本

sh  /usr/local/waiting_connection.sh

只显示结果，不报错就代表脚本编写是成功的

将自定义脚本放入crontab定时中

重新访问pushgateway

至此自定义监控项count_nestat_wait_connections已经添加完成

把count_nestat_wait_connections这个key直接输入prometheus命令行之后得到最原始的数据输出

我们来学习命令行的过滤

看下图显示:

后面的{}的部分 属于标签

标签：也是来自于 采集数据， 可以自定义也可以直接使用默认的exporter提供的标签项

上面的这几个标签中 最重要的是 exported_instance 指明 是那台被监控服务器，"heroes_assemble"是测试服务器的机器名

使用{}进行第一步过滤

count_netstat_wait_connections{exported_instance="heroes_assemble"}

过滤除了精确匹配之外 还有模糊匹配

count_netstat_wait_connections{exported_instance=~"sw.*"}

会把所有机器名中带有 sw的机器都显示出来

数值过滤

比如我只想找出主机名为heroes_assemble并且wait_connection数量大于3的

count_netstat_wait_connections{exported_instance="heroes_assemble"} > 3

rate函数的使用

rate函数可以说是 prometheus提供的 最重要的函数之一

简单翻译下官网给出的解释:rate函数 是专门搭配counter类型数据使用的函数 它的功能是按照设置一个时间段，取counter在这个时间段中的 平均每秒的增量

这里举例 使用的 node_exporter key node_network_receive_bytes_total

rate(node_network_receive_bytes_total[1m])

node_network_receive_bytes_total 本身是一个counter类型 字面意思 也很好理解 网络接受字节数

咱们之前也学习过了对于这种持续增长的 counter数据，直接输入key是没有任何意义的 我们必须要以获取单位时间内增量的方式来进行加工才能由意义

node_network_receive_bytes_total 被rate( [1m])包上后 就可以获取到在1分钟时间内，平均每秒的 增量

这样以来 数据就变得有意义了

sum函数的学习

sum就是取合，sum会把结果集的输出 进行总加合

拿rate(node_network_receive_bytes_total[1m])显示的结果集举例

从上面图的返回的中不难看出， 有多台多个网卡都返回了这个监控数据

当我们使用sum()包起来以后就变成这样了

变成一条线了，等于是给出了所有机器的每秒请求量

topk()函数的学习

定义: 取前几位的最高值

Gauge类型的使用

topk(3, count_netstat_wait_connections)

Counter类型的使用

topk(3,rate(node_network_receive_bytes_total[5m]))

这个函数 还是比较容易理解的， 根据给定的数字 去数值最高>=x的数值

count()函数的学习

定义:把数值符合条件的输出数目进行加合

举个列子

找出当天当tcp等待数大于200的机器数量

这个函数在实际工作中还是很有用的

一般用它进行一些模糊的监控判断

比如说 企业中有集群环境中的100台服务器，那么当只有10台机器cpu高于80%的时候，这个时候不需要报警 但是当高于80% cpu的服务器数量超过30台的时候那么就会触发报警

当然prometheus 提供的函数远不止于此，对其他函数感兴趣的朋友可以去官网继续学习

Query functions | Prometheus

企业级监控数据采集方法

prometheus下载安装

上面的篇幅已经讲过了，就不多说了，就是从官网上下载二进制安装包，然后解压压缩包，拿二进制文件直接执行就算启动了

不过 我们作为合格的运维工程师，对生产环境上运行的软件 更多考虑一些更合理的运行模式

我们需要让prometheus_server 运行在后台而不是前端

这里推荐两种方法

第一种，安装screen工具，放入后台运行

yum install screen      #安装screen工具
screen                  # 进入后台
./prometheus           #进入解压目录，直接执行二进制文件
screen -ls             #显示被放入后台运行的进程
screen -r $pid         #观察进程执行前端输出

screen 也有不好的地方:

不够正规化，总觉得是个临时办法

screen -l 提供的后台列表不够人性化 很多时候你记不住那个是那个

很容易被误关闭 操作的时候 ctrl + ad /ctrl +d不小心操作错了 直接就退出出去了

第二种，使用daemonize 放入后台方式

daemonize unix系统后台守护进程管理软件

优点:更加正规 后台运行更稳定 

git clone https://github.com/bmc/daemonize.git
sh configure && make && sudo make install

daemonize -c /opt/prometheus /opt/prometheus/up.sh

-c 是指定运行路径

/opt/prometheus/up.sh是运行路径下的一个启动脚本

下面就是这个启动脚本的内容

#!/bin/bash
/opt/prometheus/prometheus --web.listen-address="0.0.0.0:9090" --web.read-timeout=5m --web.max-connections=512 --storage.tsdb.retention=15d --storage.tsdb.path="data/" --query.max-concurrency=20 --query.timeout=2m

我们来看下 ./prometheus z在实际企业运行时 启动参数的合理配置

--web.read-timeout=5m

请求链接的最大等待时间 防止太多的空闲链接占用资源

--web.max-connections=512

最大链接数

--storage.tsdb.retention=15d

prometheus开始采集数据后台 会存在内存中和磁盘中 对于保留期限的设置很重要 太长的话硬盘和内存都吃不消，太短的 要查历史数据就是没有了 企业中设置15天为宜

--storage.tsdb.path="data/"

存储数据路径这个也很重要不要随便放在一个地方就执行 会把/根目录塞满了

--query.max-concurrency=20

--query.timeout=2m

上面这两项是对用户执行prometheus 查询时候的优化设置 防止太多的用户同时查询 也防止单个用户执行过大的查询而一直不退出

node_exporter下载安装和后台运行

这个和prometheus也是一样的 这里就不再演示了

企业级监控数据采集脚本开发实践

pushgateway的介绍

pushgateway是另外一种采用被动推送的方式 获取监控数据的prometheus插件

在上面的篇幅中已经做过介绍了，它是可以单独运行在任何节点上的插件 然后通过用户自定义开发脚本把需要监控的数据发送给pushgateway 然后pushgateway再把数据推送给prometheus server

pushgateway的安装和运行和配置

这个上面的篇幅已经讲到过了，这里就不再多说了

自定义编写脚本的方法 发送pushgateway采集

这个上面上面篇幅中说抓取TCP waiting_connection 瞬时数量的时候就已经说过了

使用pushgateway的优缺点

pushgateway这种自定义的采集方式非常的快速而且极其灵活几乎不受到任何约束

其实我个人 还是非常希望使用pushgateway来获取监控数据的 各类的exporter虽然琳琅满目 而且默认提供的数据很多了已经 一般情况下 我们在业务中只安装node_exporter 和DB_exporter两个 其他种类的监控数据我倾向于使用pushgateway的方式采集

pushgateway虽然很灵活 但是也是存在一些短板的 我们对官网上讲的做了两点总结

1）pushgateway 会形成一个单点瓶颈，假如好多个脚本同时发送一个pushgateway的进程 如果这个进程没了 那么监控数据也就没了

2）pushgateway 并不能对发送过来的脚本采集数据进行更智能的判断 假如脚本中间采集出问题了 那么有问题的数据pushgateway一样照单全收 发送给prometheus

上述文档从b站大米运维课堂整理,结合自己的一些实操,喜欢的话帮忙点个关注