作者：莫善

某互联网公司高级 DBA。

本文起源：原创投稿

*爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

一、背景介绍

运维工作中可能会遇到这么一个痛点，因线上机器根本都是单机多实例，有时候会呈现因为某个实例而影响了整个机器的性能。因短少过程级别的监控，预先想剖析是哪个实例跑满了系统资源往往比拟艰难。为了解决这一痛点，迫切希望实现过程级别的监控。

过程级别的资源监控，包含然而不限于CPU，内存，磁盘IO，网络流量。

二、后期筹备

经理解，有一个 process_exporter 能够实现过程监控，然而在理论调研及测试发现，该工具有些有余：

process_exporter https://github.com/ncabatoff/...
  • 监控的对象必须事后配置

咱们线上单台机器可能部署有20个实例，要么是将20个实例的配置放在一个 process_export ，要么是单个实例一个 process_export ，不论哪种形式部署 process_export 可能都有些麻烦，另外新加一个想监控的对象也须要从新保护一下 process_exporter 。

我心愿是增加待监控机器后能主动发现所有沉闷的过程。
  • 不能监控过程的网络状况

测试 process_exporter 发现只有 io、内存、cpu等应用状况，没找到网络监控的指标。

咱们线上机器很多还是千兆网卡，监控网络应用状况的需要更大。
  • 额定的需要

咱们的环境可能会有一些长期过程（不是常驻过程）。

三、需要实现

1、监控采集

最开始的思路很简略，就想着应用一些零碎工具间接读后果进行解析。然而领导感觉读取它们的采集后果可能略微重了一点，可能效率不高，达不到小粒度采集，所以想让我钻研一下间接抓取【/proc/pid/】上面运行态的数据，这种形式效率应该是最高的。然而在理论测试过程中发现，想要通过【/proc/pid/】来实现过程监控的计划真是困难重重，以至于起初临时放弃该计划了，不过还是想简略聊一下这个的测试历程。

[root process-exporter]# ls /proc/1attr       auxv    clear_refs  comm             cpuset  environ  fd      gid_map  limits    map_files  mem        mounts      net  numa_maps  oom_score      pagemap      personality  root   schedstat  setgroups  stack  statm   syscall  timers   wchanautogroup  cgroup  cmdline     coredump_filter  cwd     exe      fdinfo  io       loginuid  maps       mountinfo  mountstats  ns   oom_adj    oom_score_adj  patch_state  projid_map   sched  sessionid  smaps      stat   status  task     uid_map[root process-exporter]#
这个连贯比拟具体的介绍了【/proc/pid】上面的文件/目录 https://github.com/NanXiao/gn...

（1）CPU状态抓取

间接翻车，在【/proc/pid/】上面没找到CPU相干的状态数据。

有晓得的大佬请领导一下。

（2）MEM状态抓取

内存能够通过【/proc/pid/status】文件进行抓取。

$ grep "VmRSS:" /proc/3948/status VmRSS:    19797780 kB$

（3）io状态抓取

同理，io也能够通过【/proc/pid/io】文件进行抓取。

$ grep "bytes" /proc/3948/ioread_bytes: 7808071458816write_bytes: 8270093250560

（4）网络状态抓取

这个也间接翻车，在【/proc/pid/】上面倒是找到了跟网络相干的信息，比方【/proc/pid/net/dev】，还有【/proc/pid/netstat】。

起初认为dev这个文件是保留了过程级网络传输数据，然而发现这个文件记录的网络流量是整个网卡的，就是说【/proc/pid/net/dev】和【/proc/net/dev】这两个文件记录的网络流量字节数根本一样大。具体测试如下：

首先模仿两个网络传输的过程，因为我测试的机器是有NFS，所以间接从NFS拷贝到本地，就模仿了网络传输。

$  ps -ef|grep -- "cp -i -r"|grep -v greproot      66218 111973 12 17:14 pts/1    00:00:11 cp -i -r Backup_For_TiDB/15101/2022-06-20 /workroot      67099 122467 10 17:14 pts/2    00:00:09 cp -i -r Backup_For_TiDB/15001/2022-06-20 /work
过程号别离是 66218 67099

而后通过同时打印两个pid对应的【/proc/pid/net/dev】文件及零碎的【/proc/net/dev】文件做比照

$  cat /proc/66218/net/dev /proc/67099/net/dev /proc/net/dev |grep eth0 && sleep 1 && echo "------------------------" && cat /proc/66218/net/dev /proc/67099/net/dev /proc/net/dev|grep eth0  eth0: 364616462197417 249383778845    0    0    0     0          0         0 77471452119287 170038153309    0    0    0     0       0          0  eth0: 364616462197417 249383778845    0    0    0     0          0         0 77471452119287 170038153309    0    0    0     0       0          0  eth0: 364616462197417 249383778845    0    0    0     0          0         0 77471452119287 170038153309    0    0    0     0       0          0------------------------  eth0: 364616675318586 249383924598    0    0    0     0          0         0 77471456448161 170038229547    0    0    0     0       0          0  eth0: 364616675318586 249383924598    0    0    0     0          0         0 77471456449457 170038229571    0    0    0     0       0          0  eth0: 364616675318586 249383924598    0    0    0     0          0         0 77471456449835 170038229578    0    0    0     0       0          0$

能够看到，这三个【/proc/66218/net/dev】【/proc/67099/net/dev】 【/proc/net/dev】的eth0网卡的流量是一样的，就是说【/proc/pid/net/dev】理论也是零碎的流量开销，而不是单个过程对应的流量开销。

【/proc/pid/net/dev】这个不行就狐疑【/proc/pid/net/netstat】这个文件是我须要的，然而很好受，简直看不懂外面的信息，找了很多材料才大抵弄清楚外面的数据，最终发现也不是须要的数据。

/proc/pid/net/netstat的详情能够参考这里 https://github.com/moooofly/M...

最终还是斗争了，老老实实应用现成的工具进行采集吧。

top free ps iotop iftop等工具

2、数据分析

确定了采集形式后就是数据的剖析了，上面筹备挨个剖析一下。

（1）CPU

上面这几个是整机的状况

$ lscpu|grep 'NUMA node0 CPU(s)'|awk '{print $NF}'|awk -F'-' '{print $2+1}'  #机器CPU外围数$ uptime|awk -F'average: ' '{print $2}'|awk -F, '{print int($1)}'            #机器以后负载状况$ top -b -n 1|grep '%Cpu(s):' |awk '{print int($8)}'  #idle$ top -b -n 1|grep '%Cpu(s):' |awk '{print int($10)}' # iowait
这部分比较简单，间接记录即可。

上面是针对过程抓取CPU应用状况

$ top -b -n 1|grep -P "^[ 0-9]* "|awk 'NF==12 {    if($9 > 200 || $10 > 10) {        for (i=1;i<=NF;i++)            printf $i"@@@";        print "";    }}'  #过程应用CPU百分比，内存百分比，仅记录应用到cpu和内存的过程
这部分略微有点简单，后果会保留到top_dic字典。

这个操作的目标是想着记录过程的cpu内存应用状况，然而会发现top的详情外面并没有过程信息，所以还须要联合ps辅助一下，具体如下：

ps -ef|awk '{printf $2"@@@" ;for(i=8;i<=NF;i++) {printf $i" "}print ""}'
这部分后果会保留到ps_dic字典。只须要记录pid和过程详情即可，所以对ps做了剖析后最初的后果就是【pid@@@process_info】，最终top_dic和ps_dic通过pid关联

（2）MEM

上面是整机的状况

$ free |grep '^Mem:'|awk '{print int($2/1024/1024),int($3/1024/1024),int(($2-$3)/1024/1024)}'

上面是针对过程抓取MEM应用状况

#过程应用MEM百分比在cpu局部就曾经采集

内存这块是为了不便并没有应用proc上面的运行态数据，如果从proc上面采集须要遍历所有pid，感觉比拟麻烦，还不如间接通过top采集一次来的不便（还是顺便采集）。然而也有一个弊病，最终计算过程应用内存大小会多一个操作，即须要依据MEM百分比对其进行计算换成具体字节数。

（3）磁盘

上面是整机的磁盘应用状况

$ df|grep ' " + part + "'|awk '$2 > 1024 * 1024 * 50 && /^\//{print $1,int($2/1024/1024),int($3/1024/1024),int($4/1024/1024)}'  #磁盘应用状况
须要数据盘的挂载点，如果没有配置挂载点会记录整个机器的所有挂载点（大于50GB的挂载点）的应用状况。

上面是针对过程抓取io应用状况

$ iotop -d 1 -k -o -t -P -qq -b -n 1|awk -F' % ' '    NR>2{        OFS="@@@";        split($1,a," ");        if(a[5] > 10240 || a[7] > 10240 ) {            print a[1],a[2],a[5]a[6],a[7]a[8],$NF;        }    }    NR<3{        print $0;    }'|awk '    {        if(NR==1){            print $1,$2,$6,$13;        } else if(NR==2) {            print $1,$2,$5,$11;        } else {            print $0;        }    }'
这个采集也略微有点简单，后果会保留到iotop_dic字典，通过pid和top_dic和ps_dic这两个字典关联。须要留神的是，在理论测试过程中发现，局部过程的详情十分长，所以为了防止数据冗余，过程信息会记录到独自的表【tb_monitor_process_info】，并记录该串的md5值且将md5作为惟一键，这样能够防止空间的节约。在展现的时候仅须要通过md5值作为关联条件即可。

咱们须要对后果做剖析并加工成咱们须要的，我感觉有用的就是【工夫】【pid】【读io】【写io】【过程信息】，以及对于io访问量少的过程间接过滤掉。

综上，过程级别的cpu，内存，io应用状况的采集数据上报给server端大略是上面这样：

    {        "19991":{            "cpu":"50.0",            "mem":"12.5",            "io_r":"145",            "io_w":"14012",            "md5":"2932fb739fbfed7175c196b42021877b",            "remarks":"/opt/soft/mysql57/bin/mysqld --defaults-file=//work/mysql23736/etc/my23736.cnf"        },        "58163":{            "cpu":"38.9",            "mem":"13.1",            "io_r":"16510",            "io_w":"1245",            "md5":"c9e1804bcf8a9a2f7c4d5ef6a2ff1b62",            "remarks":"/opt/soft/mysql57/bin/mysqld --defaults-file=//work/mysql23758/etc/my23758.cnf"        }    }

（4）网络

网络的监控有点好受，没法基于pid做剖析，只能通过ip:port剖析来回的流量。

上面是整机的网络应用状况

$ iftop -t -n -B -P -s 1 2>/dev/null|grep Total |awk '    NR < 3 {        a = $4;        if ($4 ~ /MB/) {            a = ($4 ~ /MB/) ? 1024 * int($4) "KB" : $4;        } else if ($4 ~ /GB/) {            a = ($4 ~ /GB/) ? 1024 * 1024 * int($4) "KB" : $4;        }        a = (a ~ /KB/) ? int(a) : 0        print $2, a;    }    NR == 3 {        b = $6;        if ($6 ~ /MB/) {            b = ($6 ~ /MB/) ? 1024 * int($6) "KB" : $6;        } else if ($6 ~ /GB/) {            b = ($6 ~ /GB/) ? 1024 * 1024 * int($6) "KB" : $6;        }        b = (b ~ /KB/) ? int(b) : 0        print $1, b;    }'

上面是过程级别的网络应用状况

$ iftop -t -n -B -P -s 2 -L 200 2>/dev/null|grep -P '(<=|=>)'|sed 'N;s/\\n/,/g'|awk 'NF==13{    if($4 ~ /(K|M|G)B/ || $10 ~ /(K|M|G)B/) {        if(($4 ~ /KB/ && int($4) > 10240) ||            ($10 ~ /KB/ && int($10) > 10240) ||            ($4 ~ /MB/ && int($4) > 10240) ||            ($10 ~ /MB/ && int($10) > 10240) ||            ($4 ~ /GB/ || $10 ~ /GB/)) {                print $2,$4,$8,$10            }        }    }'
这部分比拟麻烦的是单位换算及计算。这部分会将后果保留到iftop_dic。

这个采集也略微有一点简单，须要对后果做剖析并加工成咱们所须要的。我认为有用的就是【出ip:port】【进口流量】【回ip:port】【入口流量】。最初过程网络应用状况的采集数据上报给server端大略是上面这样子。

{    "net":{        "speed":"1000",        "send":"7168",        "receive":"8192",        "Total":"16384",        "time":"2022-06-29 20:16:20",        "iftop" : {            "192.168.168.11:55746":[                {                    "remote":"192.168.168.13:18059",                    "out":"7.94KB",                    "in":"307KB"                }            ],            "192.168.168.11:60090":[                {                    "remote":"192.168.168.13:18053",                    "out":"6.73KB",                    "in":"307KB"                }            ]        }    }}

至此，所有采集项的监控数据都曾经拿到了，上面就是将数据入库了。

3、数据入库

监控数据分析了当前，就是将其记录下来，本我的项目采纳 MySQL 来保留数据，其中未免波及一些二次剖析，以及注意事项，这里不筹备介绍，放在注意事项局部进行介绍。

4、数据展现

实现了数据分析，数据记录，最初的工作就是将数据展现进去，供运维人员在须要的时候随时查看剖析，本我的项目采纳 grafana 将数据展现进去，这个局部有些注意事项，这里也不筹备介绍，放在注意事项进行介绍。能够先来看个效果图：

四、注意事项

应用 python3 实现代码局部，所有注意事项的解决方案也是仅针对 python3 语法来实现的。

1、ssh环境

数据的采集是通过rpc实现，然而 server 端对 client 的治理都是依赖 ssh ，所以必须保障 server 到所有的 client 都能 ssh 免密登录。

2、长连贯

跟 MySQL 的通信，倡议应用长连贯。尤其是须要监控的机器个数比拟多，如果是短连贯会频繁跟 MySQL 进行创立连贯开释连贯，存在肯定的不必要开销。

def f_connect_mysql(): #建设连贯    """    建设连贯    """    state = 0    try :        db = pymysql.connect(monitor_host, monitor_user, monitor_pass, monitor_db, monitor_port, read_timeout = 2, write_timeout = 5) #连贯mysql    except Exception as e :        f_write_log(log_opt = "ERROR", log = "[ 建设连贯失败 ] [ " + str(e) + " ]", log_file = log_file)        db = None            return dbdef f_test_connection(db):    """    测试连贯    """    try:        db.ping()    except:        f_connect_mysql()    return dbdef f_close_connection(db):    """    敞开连贯    """    try:        db.close()    except:        db = None    return db
须要留神，如果是多线程的话倡议每个线程保护一个连贯，或者增加互斥锁，这样能够防止局部异样。

3、做减法

因为咱们是基于机器去做的过程监控，难免会呈现很多被监控的对象（一台机器上千个服务也不是不可能），在测试过程中没有发现这个问题影响很大，然而在实际上线后发现，如果不优化这个局部会导致 metrics 太多，grafana 的渲染很慢，所以对于不必要的采集记录，能够在采集的时候就过滤掉，能肯定水平防止 client 到 server 端的网络开销，也能缩小磁盘空间的开销，还晋升 grafana 的出图效率。

优化后，在配置文件提供了配置项，只有当过程应用系统资源满足阈值才会被采集。

4、超时机制

（1）操作 MySQL 的超时

既为了代码的健壮性，也是为了程序的继续、稳定性都倡议加上超时参数，能够防止因为一些极其场景导致读数或者写数卡住。

（2）采集数据的超时

生产环境的复杂性，什么都可能产生，即使是一条简略到不能再简略的命令也可能呈现卡住，所以加上超时机制吧。这里须要留神，在增加超时机制的时候发现有些问题，具体测试如下：

Python 3.7.4 (default, Sep  3 2019, 19:29:53) [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linuxType "help", "copyright", "credits" or "license" for more information.>>> import datetime,subprocess>>> s_time = datetime.datetime.now()>>> res = subprocess.run("echo $(sleep 10)|awk '{print $1}'",shell=True,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,encoding="utf-8",timeout=2)省略了很多谬误输入subprocess.TimeoutExpired: Command 'echo $(sleep 10)|awk '{print $1}'' timed out after 2 seconds>>> e_time = datetime.datetime.now();>>> >>> print(s_time)2022-06-23 13:05:37.886864>>> print(e_time)2022-06-23 13:05:48.353889>>> print(res)Traceback (most recent call last):  File "<stdin>", line 1, in <module>NameError: name 'res' is not defined>>>

能够看到【subprocess.run】设置了两秒超时，然而两秒后没有抛出异样并完结执行，从执行工夫看s_time跟e_time相差11秒，然而整个执行后果是异样的（res都没有后果），就是说并没有起到料想的超时成果（料想的成果是到超时阈值后终止执行，返回异样）。

如果操作命令是简略的命令就没事，比方将【echo $(sleep 10)|awk '{print $1}'】改成【sleep 10】，这个超时机制就失常。

针对这个超时机制可能会呈现生效的状况，在代码外面间接用系统命令timeout代替了。

5、返回值

如果操作命令带管道等简单命令，返回值可能并不可信。具体测试如下

>>> res = subprocess.run("echoa|awk '{print $1}'",shell=True,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,encoding="utf-8",timeout=2)>>> res.returncode0>>>
【echoa|awk '{print $1}'】管道右边的操作是谬误的，所以整个返回后果应该是非零（预期是这样），然而这里返回了0。起因是在管道操作的场景，bash默认状况是仅获取最初一个管道的执行返回状态码，例如【comm1|comm2|comm3】，如果comm1执行胜利，comm2执行失败，然而comm3执行胜利，那整个返回状态就是执行胜利。

解决方案如下

>>> res = subprocess.run("set -o pipefail;echoa|awk '{print $1}'",shell=True,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,encoding="utf-8",timeout=2)>>> res.returncode127>>>
执行命令前先加一个set -o pipefail，对于set -o的解释能够参考上面的形容。
-o    If set, the return value of a pipeline is the value of the last (rightmost) command to exit with a non-zero status, or zero if all  com‐mands in the pipeline exit successfully.  This option is disabled by default.

五、工作原理

1、server

  • 线程1

这个线程会做三个事件：

（1）在server重启的时候会去读【tb_monitor_version】表，判断以后版本号跟MySQL记录的版本号是否统一，如果不统一就会去更新MySQL记录的版本号。而后将【tb_monitor_host_config】表所有istate=2的节点更新为istate=1。

（2）治理client上线下线，每30s去读一次【tb_monitor_host_config】表，将须要上线的节点或者须要下线的节点进行保护。istate=1示意须要上线，就会去部署监控脚本（降级就更新代码），并更新为istate=2，istate=0示意须要下线，会去下线该client节点并更新为istate=-1。

（3）治理client状态，每30s去读一次【tb_monitor_host_config，tb_monitor_alert_info，tb_monitor_host_info】表（三表关联），将最近两分钟没有上报的client且最近5min没有被告警的节点统计进去并告警。

  • 线程2

这个线程做两个事：

（1）期待client上报监控数据，而后进行二次剖析并写到MySQL中。

（2）返回以后版本号给client。

2、client

client端会做三个事件

（1）六线程并行去采集【机器cpu】【机器内存】【机器磁盘】【机器网络】【过程网络】【过程io，过程cpu，过程内存】。采集结束后，主线程会进行剖析并上报给server端。

（2）在上报过程中如果遇到间断三次server都是异样状态就会将server异样记录（防止多个client同时告警）到【tb_monitor_alert_info】表发送告警。

（3）上报实现后会判断本人的版本号跟server端返回的版本号是否统一，如果不统一就会退出程序，期待crontab拉起，以此实现降级。

server端实现代码更新，在重启server的时候会将新代码同步到各个client。

3、MySQL

MySQL的作用是存版本信息，client ip配置，监控数据，以及告警状态等。

4、grafana

grafana的作用是从MySQL读取监控数据并展现进去。

5、alert

采纳企业微信的机器人作为告警通道。

六、应用限度

1、零碎环境

（1）操作系统版本及内核。

$ uname -aLinux 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux$ cat /etc/redhat-releaseCentOS Linux release 7.4.1708 (Core)
其余版本没有测试过，不确定是否能用。

（2）零碎工具

监控数据采集依赖于操作系统工具，次要依赖如下：

awk,grep,sed,tr,md5sumtop,iftop,iotopdf,free,lscpu,uptimeip,netstatrsync,python3cd,ssh,timeout
server端到client要有免密登录。

2、软件环境

软件版本可能存在兼容性问题，所以其余版本不确定是否能用，请各自测试调试。

（1）Python环境

3.7.4

（2）MySQL版本

5.7.26

（3）grafana版本

8.3.1 倡议小版本也要统一。 https://dl.grafana.com/enterp...

七、应用介绍

1、部署server

（1）clone我的项目
mkdir -p /opt/soft/gitcd /opt/soft/gitgit clone https://gitee.com/mo-shan/rpc_for_process_monitor.git
依赖Python3环境，倡议3.7.4，要求python3在PATH外面，装置过程略。
（2）部署server
cp -r /opt/soft/git/rpc_for_process_monitor /opt/soft/rpc_for_monitor  #留神这里的目录是有区别的, 次要是心愿开发环境跟理论部署的目录不一样, 防止失误cd /opt/soft/rpc_for_monitor


$ tree -L 2.├── conf│   └── config.ini                  #配置文件├── img                             #疏忽│   ├── all-info.png│   ├── cpu-info.png│   ├── disk-info.png│   ├── grafana-data-source-1.png│   ├── grafana-data-source-2.png│   ├── grafana-data-source-3.png│   ├── grafana-data-source-4.png│   ├── grafana-data-source-5.png│   ├── grafana-data-source-6.png│   ├── grafana-data-source-7.png│   ├── mem-info.png│   ├── net-info.png│   └── process-info.png├── init                            #初始化文件│   ├── grafana.json                #grafana配置模板│   ├── init.sql                    #mysql建表语句│   └── requirements.txt            #python3依赖的模块├── lib                             #库文件│   ├── Config.py                   #解析config.ini│   ├── ConnectMySQL.py             #连贯并操作mysql│   ├── globalVar.py                #全局变量│   ├── Public.py                   #公共函数│   └── __pycache__├── LICENSE├── logs                            #日志目录│   └── info.log                    #日志文件├── py37env                         #虚拟环境，要求在/opt/soft/rpc_for_monitor/py37env下能力应用（activate等文件的门路写死了）│   ├── bin│   ├── include│   ├── lib│   └── pip-selfcheck.json├── README.md                       #帮忙文档├── rpc.py                          #主程序├── start_server.sh                 #server端的启动脚本└── state                           #疏忽    └── state.log11 directories, 28 files
（3）配置server
vim conf/config.ini #依据理论状况进行编辑
如果须要变更我的项目目录，须要将【lib/Config.py】文件的变量【config_file】也改一下。
[global]version       = 1.1   #版本号, 通过这个变量管制server和client的代码，如果server发现这个配置跟表里保留的版本不统一就认为代码进行了变更，就会将新代码传到client，client如果发现自己的版本和server版本不一样会进行重启，以此达到降级成果。interval_time = 30    #监控采集粒度单位是秒，即30秒一次，这个不是齐全准确的30s一次retention_day = 30    #监控数据保留天数，即30天log_file = /opt/soft/rpc_for_monitor/logs/info.log #日志文件script_dir = /opt/soft/rpc_for_monitor             #脚本目录，不倡议变更mount_part    = /work  #数据盘挂载点, 也能够不配置，置为空，然而不能删除这个配置项log_size      = 20     #日志文件大小（MB）限度，超过这个值就会删除历史日志[RULE] cpu = 200    #采集的阈值，200示意某个过程应用cpu大于等于200%才会被采集mem = 10     #采集的阈值，10示意某个过程应用内存大于等于10GB才会被采集io  = 10240  #采集的阈值，10240示意某个过程应用io（读写有一个就算）大于等于10MB才会被采集net = 10240  #采集的阈值，10240示意某个过程应用网络（进出有一个就算）大于等于10MB才会被采集[CLIENT]path = xxxx  #预约义一下操作系统的path，因为client会保护一个cront工作，所以防止因为环境变量问题导致脚本执行报错，须要定义一下pathpython3 = /usr/local/python3 #python3装置目录py3env = /opt/soft/rpc_for_monitor/py37env #python3虚拟环境目录，工程自带了一个虚拟环境，能够间接用（前提是脚本目录没有变更）[MSM]wx_url  = xxxx   #企业微信报警url，告警性能须要用户本人批改一下并测试（如果是告警机器人url+key，能够间接配上就能用，本例就是通过企业微信机器人发送告警）[Monitor]  #寄存监控数据的MySQL的配置mysql_host      = xxxxmysql_port      = xxxxmysql_user      = xxxxmysql_pass      = xxxx省略局部不倡议变更的配置
所有目录不倡议批改, 要不然须要变更的中央太多，容易出错。

2、部署 MySQL

装置MySQL略，倡议的版本：5.7
（1）新建必要的账户
用MySQL管理员用户登录并操作。
create user 'monitor_ro'@'192.%' identified by 'pass1'; #明码请依据理论状况变更grant select on dbzz_monitor.* to 'monitor_ro'@'192.%';create user 'monitor_rw'@'192.%' identified by 'pass2';grant select,insert,update,delete on dbzz_monitor.* to 'monitor_rw'@'192.%';
monitor_ro用户给grafana应用, monitor_rw用户是给程序写入监控数据的（server端写数据，client上报给server）。所以留神的是，monitor_ro用户要给grafana机器受权，monitor_rw用户要给所有监控对象受权，这个目标是用来管制当server失联了，第一个发现的client就会向表里写一条告警记录并告警，防止其余client反复操作。
（2）初始化MySQL
用MySQL管理员用户登录并操作。
cd /opt/soft/rpc_for_monitormysql < init/init.sql
所有表放在dbzz_monitor库下
(dba:3306)@[dbzz_monitor]>show tables;+----------------------------+| Tables_in_dbzz_monitor     |+----------------------------+| tb_monitor_alert_info      |   # 告警表, 触发告警就会在外面写入一条记录, 防止同一时间屡次告警。| tb_monitor_disk_info       |   # 磁盘信息表，多个盘会记录多条记录| tb_monitor_host_config     |   # client配置表，须要采集监控的机器配置到这外面就行| tb_monitor_host_info       |   # 零碎层面的监控记录到这外面| tb_monitor_port_net_info   |   # 端口级别的网络监控会记录到这外面| tb_monitor_process_info    |   # 这外面是记录了过程信息，全局的| tb_monitor_process_io_info |   # 这里是记录的过程的io监控数据| tb_monitor_version         |   # 记录版本号，及版本号变更工夫+----------------------------+6 rows in set (0.00 sec)(dba:3306)@[dbzz_monitor]>
所有表都有具体的正文，请看表的建表正文。

3、配置client

配置客户端很简略，只须要往MySQL表外面写入一条记录。

use dbzz_monitor;insert into tb_monitor_host_config(rshost,istate) select '192.168.168.11',1;  #多个机器就写多条记录，server端会有后盾线程定时扫描tb_monitor_host_config#如果有待增加的client就会进行部署#如果须要下线监控节点间接将istate状态改成0即可
这里有个限度条件，这个client端曾经有python3环境，否则会报错。

4、部署grafana

装置略。

grafana版本：8.3.1，倡议小版本也要统一。 https://dl.grafana.com/enterp...

这部分波及到grafana的配置，所有的配置都曾经导成json文件，用户间接导入即可。

具体的操作如下。
（1）新建DataSource

新建一个数据源


须要抉择MySQL数据源

数据源的名称要求写【dba_process_monitor】，如果跟grafana配置不统一可能会有影响。

（2）导入json配置
$ ll init/grafana.json -rw-r--r-- 1 root root 47875 Jun 23 14:28 init/grafana.json

本配置是在grafana 8.3.1 版本下生成的。须要留神一下版本，不同版本可能不兼容。如果版本不统一导入会导致出图失败，须要用户本人重新配置grafana，出图的sql能够参考一下grafana配置文件的rawSql的配置【grep rawSql init/grafana.json】。

  • 倡议1：【Lagend】的配置都改成【as table】，要不然如果指标太多显示进去的会很乱
  • 倡议2：抉择单位的时候对于不心愿进行转换的能够选【Custom unit】属性
  • 倡议3：【Stacking and null value】属性倡议设置为【null as zero】

5、启动server

将server端的启动脚本配置到crontab中，能够起到守护过程的作用。

echo "*/1 * * * * bash /opt/soft/rpc_for_monitor/start_server.sh" >> /var/spool/cron/root
client端不必管，server启动当前会主动去治理client。

配置实现后，期待一分钟查看日志【/opt/soft/rpc_for_monitor/logs/info.log】，能够看到相似上面的日志。

[ 2022-06-30 15:13:01 ] [ INFO ] [ V1.1 Listening for '0.0.0.0:9300' ][ 2022-06-30 15:13:04 ] [ INFO ] [ 新加监控节点胜利 ] [ 192.168.168.11 ][ 2022-06-30 15:13:11 ] [ INFO ] [ 监控数据上报胜利 ] [ 192.168.168.11 ]
端口默认是9300，能够通过批改【/opt/soft/rpc_for_monitor/start_server.sh】这个文件就行变更监听端口。

6、效果图

（1）主页面

总共有五个ROW，后面四个是机器级别的监控图，process是过程的监控图。
（2）CPU页面

整个机器的CPU应用状况。
（3）内存页面

整个机器的内存应用状况。
（4）磁盘页面

整个机器的磁盘应用状况，如果没有定义具体的挂载点，会采集所有的挂载点。
（5）网络页面

整个机器的网络应用状况。
（6）过程页面

会看到具体的过程对系统资源的应用状况。须要留神，因在采集的时候做了过滤，所以监控数据并不一定是间断的，所以倡议配置grafana的【null as zero】，这样展现监控图的时候是间断的，而不是很多点。另外某个指标可能为空，这也是失常景象。

八、注意事项

  • server，client端肯定要有python3环境。
  • 如果有多个server，在启动server的时候就要指定多个（用逗号隔开），要不然在部署client的时候只会配上单个server，配置多个的益处就是如果第一个宕机/异样，client会上报给其余的server。
  • server在运行过程中能够增加client，只须要在【tb_monitor_host_config】表增加istate为1的记录即可。同理，如果下线的话就更新istate为0即可，运行中的istate为2，下线后的istate为-1。
  • 该工具有告警性能（如果配置），server挂了（client间断三次都连不上server），会由第一个发现的client记录到MySQL外面，并发送告警，如果client挂了，server会发现并告警（超过两分钟未上报告警数据）。
  • 如果须要降级代码，只须要测试好新代码，确认无误后，更新到server的部署脚本目录，而后kill掉server过程即可，期待crontab拉起就行了，client端的代码不必人为进行更新。须要留神，新代码肯定要记得批改配置文件的版本号，要不然server端不会发现版本不统一，也就不会下发相干工作去更新client的代码。
  • 如果须要批改部署目录请依据理论状况批改【conf/config.ini】【lib/Config.py】，留神这时候自带的虚拟环境将不能应用了。强烈不倡议变更目录构造或者目录名。
  • 因思考到MySQL性能问题及grafana渲染性能问题，所以减少了采集阈值性能，所以局部面板的监控数据可能会没有（该时间段的过程没有满足采集阈值的数据）。

九、写在最初

本文所有内容仅供参考，因各自环境不同，在应用文中代码时可能碰上未知的问题。如有线上环境操作需要，请在测试环境充沛测试。