作者:莫善
某互联网公司高级 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/1
attr 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 wchan
autogroup 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/io
read_bytes: 7808071458816
write_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 grep
root 66218 111973 12 17:14 pts/1 00:00:11 cp -i -r Backup_For_TiDB/15101/2022-06-20 /work
root 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 db
def f_test_connection(db):
"""测试连贯"""
try:
db.ping()
except:
f_connect_mysql()
return db
def 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 linux
Type "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.returncode
0
>>>
【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.returncode
127
>>>
执行命令前先加一个 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 -a
Linux 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-release
CentOS Linux release 7.4.1708 (Core)
其余版本没有测试过,不确定是否能用。
(2)零碎工具
监控数据采集依赖于操作系统工具,次要依赖如下:
awk,grep,sed,tr,md5sum
top,iftop,iotop
df,free,lscpu,uptime
ip,netstat
rsync,python3
cd,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/git
cd /opt/soft/git
git 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.log
11 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 工作,所以防止因为环境变量问题导致脚本执行报错,须要定义一下 path
python3 = /usr/local/python3 #python3 装置目录
py3env = /opt/soft/rpc_for_monitor/py37env #python3 虚拟环境目录,工程自带了一个虚拟环境,能够间接用(前提是脚本目录没有变更)[MSM]
wx_url = xxxx #企业微信报警 url,告警性能须要用户本人批改一下并测试(如果是告警机器人 url+key,能够间接配上就能用,本例就是通过企业微信机器人发送告警)[Monitor] #寄存监控数据的 MySQL 的配置
mysql_host = xxxx
mysql_port = xxxx
mysql_user = xxxx
mysql_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_monitor
mysql < 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 渲染性能问题,所以减少了采集阈值性能,所以局部面板的监控数据可能会没有(该时间段的过程没有满足采集阈值的数据)。
九、写在最初
本文所有内容仅供参考,因各自环境不同,在应用文中代码时可能碰上未知的问题。如有线上环境操作需要,请在测试环境充沛测试。