-
2021-06-11 23:39:33
每次发现系统变慢时,我们通常做的第一件事,就是执行 top 或者 uptime 命令,来了解系统的负载情况。
[root@xlucas1 ~]# uptime 10:39:24 up 16 min, 2 users, load average: 0.00, 0.01, 0.04
这个显示的含义是什么?
10:39:24 up #当前系统时间 16 min #系统运行时长 2 users #当前登录用户个数
而最后三个数字呢,依次则是过去 1 分钟、5 分钟、15 分钟的平均负载(Load Average)。
我们使用man uptime可以看到介绍
DESCRIPTION uptime gives a one line display of the following information. The current time, how long the system has been running, how many users are currently logged on, and the system load averages for the past 1, 5, and 15 minutes. This is the same information contained in the header line displayed by w(1). System load averages is the average number of processes that are either in a runnable or uninterruptable state. A process in a runnable state is either using the CPU or waiting to use the CPU. A process in uninterruptable state is waiting for some I/O access, eg waiting for disk. The averages are taken over the three time intervals. Load averages are not normalized for the number of CPUs in a system, so a load average of 1 means a single CPU system is loaded all the time while on a 4 CPU system it means it was idle 75% of the time.
从这里我们可以看出。uptime不是单位时间内的 CPU 使用率,而是指单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数,它和 CPU 使用率并没有直接关系。
所谓可运行状态的进程,是指正在使用 CPU 或者正在等待 CPU 的进程,也就是我们常用 ps 命令看到的,处于 R 状态(Running 或 Runnable)的进程。
不可中断状态的进程则是正处于内核态关键流程中的进程,并且这些流程是不可打断的,比如最常见的是等待硬件设备的 I/O 响应,也就是我们在 ps 命令中看到的 D 状态(Uninterruptible Sleep,也称为 Disk Sleep)的进程。
平均负载案例分析
1、环境准备
安装stress、sysstat和tress-ngyum install sysstat yum install -y epel-release yum install stress -y yum install stress-ng
stress 是一个 Linux 系统压力测试工具,这里我们用作异常进程模拟平均负载升高的场景。
而 sysstat 包含了常用的 Linux 性能工具,用来监控和分析系统的性能mpstat 是一个常用的多核 CPU 性能分析工具,用来实时查看每个 CPU 的性能指标,以及所有 CPU 的平均指标。
pidstat 是一个常用的进程性能分析工具,用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。场景一:CPU 密集型进程
[root@xlucas1 ~]# uptime 10:59:53 up 36 min, 3 users, load average: 0.01, 0.06, 0.05
首先,我们在第一个终端运行 stress 命令,模拟一个 CPU 使用率 100% 的场景
[root@xlucas1 ~]# stress --cpu 1 --timeout 600 stress: info: [2390] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd
接着,在第二个终端运行 uptime 查看平均负载的变化情况:
#-d 参数表示高亮显示变化的区域 [root@xlucas1 ~]# watch -d uptime 11:02:34 up 39 min, 5 users, load average: 0.88, 0.38, 0.17
在启动一个终端mpstat 查看 CPU 使用率的变化情况
[root@xlucas1 ~]# mpstat -P ALL 5 Linux 3.10.0-327.el7.x86_64 (xlucas1) 06/10/2021 _x86_64_ (8 CPU) 11:01:29 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 11:01:34 AM all 12.50 0.00 0.03 0.00 0.00 0.00 0.00 0.00 0.00 87.47 11:01:34 AM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 11:01:34 AM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 11:01:34 AM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 11:01:34 AM 3 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:01:34 AM 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 11:01:34 AM 5 0.00 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 99.80 11:01:34 AM 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 11:01:34 AM 7 0.00 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 99.80
从终端可以看出1 分钟的平均负载会慢慢增加到 1.00,而从终端三中还可以看到,正好有一个 CPU 的使用率为 100%,但它的 iowait 只有 0。这说明,平均负载的升高正是由于 CPU 使用率为 100%
底是哪个进程导致了 CPU 使用率为 100% 呢?你可以使用 pidstat 来查询
[root@xlucas1 ~]# pidstat -u 5 1 Linux 3.10.0-327.el7.x86_64 (xlucas1) 06/10/2021 _x86_64_ (8 CPU) 11:02:12 AM UID PID %usr %system %guest %CPU CPU Command 11:02:17 AM 0 147 0.00 0.20 0.00 0.20 2 kworker/2:0 11:02:17 AM 0 2391 99.80 0.00 0.00 99.80 3 stress 11:02:17 AM 0 2392 0.00 0.20 0.00 0.20 5 watch 11:02:17 AM 0 2539 0.00 0.20 0.00 0.20 7 pidstat
从这里可以明显看到,stress 进程的 CPU 使用率为 100%
场景二:I/O 密集型进程
首先还是运行 stress 命令,但这次模拟 I/O 压力,即不停地执行 sync
[root@xlucas1 sysstat]# stress-ng -i 1 --hdd 1 --timeout 600 stress-ng: info: [4284] dispatching hogs: 1 hdd, 1 io
还是在第二个终端运行 uptime 查看平均负载的变化情况:
[root@xlucas1 ~]# watch -d uptime 09:59:16 up 14 min, 5 users, load average: 2.02, 0.60, 0.25
[root@xlucas1 ~]# mpstat -P ALL 5 20 Linux 3.10.0-327.el7.x86_64 (xlucas1) 06/10/2021 _x86_64_ (8 CPU) Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 09:59:33 AM all 0.03 0.00 0.13 12.10 0.00 0.03 0.00 0.00 0.00 87.72 09:59:33 AM 0 0.21 0.00 0.63 75.57 0.00 0.21 0.00 0.00 0.00 23.38 09:59:33 AM 1 0.00 0.00 0.20 19.03 0.00 0.00 0.00 0.00 0.00 80.77 09:59:33 AM 2 0.00 0.00 0.00 4.41 0.00 0.00 0.00 0.00 0.00 95.59 09:59:33 AM 3 0.00 0.00 0.21 0.00 0.00 0.00 0.00 0.00 0.00 99.79 09:59:33 AM 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 09:59:33 AM 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 09:59:33 AM 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 09:59:33 AM 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
从这里可以看到,1 分钟的平均负载会慢慢增加到 2.02,其中一个 CPU 的系统 CPU 使用率升高到了 0.63,而 iowait 高达 75.57%。这说明,平均负载的升高是由于 iowait 的升高。
那么到底是哪个进程,导致 iowait 这么高呢?我们还是用 pidstat 来查询:
确实是[root@xlucas1 ~]# pidstat -u 5 20 Linux 3.10.0-327.el7.x86_64 (xlucas1) 06/10/2021 _x86_64_ (8 CPU) 09:59:45 AM UID PID %usr %system %guest %wait %CPU CPU Command 09:59:50 AM 0 74 0.00 0.20 0.00 0.00 0.20 3 rcuos/0 09:59:50 AM 0 183 0.00 0.40 0.00 0.00 0.40 1 kworker/1:1 09:59:50 AM 0 4285 0.00 16.80 0.00 0.00 16.80 0 stress-ng-hdd 09:59:50 AM 0 4286 0.00 3.60 0.00 0.00 3.60 2 stress-ng-io 09:59:50 AM 0 4287 0.00 3.20 0.00 0.00 3.20 1 kworker/u128:2 09:59:50 AM 0 4292 0.00 0.20 0.00 0.00 0.20 3 kworker/3:0 09:59:50 AM 0 4309 0.20 0.20 0.00 0.00 0.40 0 pidstat
场景三:大量进程的场景
当系统中运行进程超出 CPU 运行能力时,就会出现等待 CPU 的进程。比如,我们还是使用 stress,但这次模拟的是 32 个进程:
[root@xlucas1 ~]# stress -c 32 --timeout 600 stress: info: [4500] dispatching hogs: 10 cpu, 0 io, 0 vm, 0 hdd
由于系统只有 8 个 CPU,明显比 32 个进程要少得多,因而,系统的 CPU 处于严重过载状态,平均负载高达 26.64
[root@xlucas1 ~]# uptime 10:30:24 up 45 min, 5 users, load average: 26.64, 15.14, 13.18
接着再运行 pidstat 来看一下进程的情况:
[root@xlucas1 ~]# pidstat -u 5 20 Linux 3.10.0-327.el7.x86_64 (xlucas1) 06/11/2021 _x86_64_ (8 CPU) 11:35:13 AM UID PID %usr %system %guest %wait %CPU CPU Command 11:35:18 AM 0 6372 24.95 0.00 0.00 0.00 24.95 2 stress-ng-cpu 11:35:18 AM 0 6373 24.95 0.00 0.00 0.00 24.95 4 stress-ng-cpu 11:35:18 AM 0 6374 24.75 0.00 0.00 0.00 24.75 3 stress-ng-cpu 11:35:18 AM 0 6375 24.95 0.00 0.00 0.00 24.95 5 stress-ng-cpu 11:35:18 AM 0 6376 24.75 0.00 0.00 0.00 24.75 7 stress-ng-cpu 11:35:18 AM 0 6377 24.55 0.00 0.00 0.00 24.55 0 stress-ng-cpu 11:35:18 AM 0 6378 24.75 0.00 0.00 0.00 24.75 6 stress-ng-cpu 11:35:18 AM 0 6379 24.95 0.00 0.00 0.00 24.95 6 stress-ng-cpu 11:35:18 AM 0 6380 24.75 0.00 0.00 0.00 24.75 1 stress-ng-cpu 11:35:18 AM 0 6381 24.75 0.00 0.00 0.00 24.75 2 stress-ng-cpu 11:35:18 AM 0 6382 24.75 0.00 0.00 0.00 24.75 4 stress-ng-cpu 11:35:18 AM 0 6383 25.15 0.00 0.00 0.00 25.15 0 stress-ng-cpu 11:35:18 AM 0 6384 24.95 0.00 0.00 0.00 24.95 3 stress-ng-cpu 11:35:18 AM 0 6385 24.95 0.00 0.00 0.00 24.95 5 stress-ng-cpu 11:35:18 AM 0 6386 24.95 0.00 0.00 0.00 24.95 7 stress-ng-cpu 11:35:18 AM 0 6387 24.75 0.00 0.00 0.00 24.75 2 stress-ng-cpu 11:35:18 AM 0 6388 24.95 0.00 0.00 0.00 24.95 1 stress-ng-cpu 11:35:18 AM 0 6389 24.95 0.00 0.00 0.00 24.95 6 stress-ng-cpu 11:35:18 AM 0 6390 24.95 0.00 0.00 0.00 24.95 1 stress-ng-cpu 11:35:18 AM 0 6391 24.75 0.00 0.00 0.00 24.75 3 stress-ng-cpu 11:35:18 AM 0 6392 25.15 0.00 0.00 0.00 25.15 5 stress-ng-cpu 11:35:18 AM 0 6393 24.75 0.00 0.00 0.00 24.75 7 stress-ng-cpu 11:35:18 AM 0 6394 24.55 0.00 0.00 0.00 24.55 5 stress-ng-cpu 11:35:18 AM 0 6395 24.75 0.00 0.00 0.00 24.75 1 stress-ng-cpu 11:35:18 AM 0 6396 24.75 0.00 0.00 0.00 24.75 4 stress-ng-cpu 11:35:18 AM 0 6397 24.95 0.00 0.00 0.00 24.95 6 stress-ng-cpu 11:35:18 AM 0 6398 24.95 0.00 0.00 0.00 24.95 0 stress-ng-cpu 11:35:18 AM 0 6399 24.75 0.00 0.00 0.00 24.75 3 stress-ng-cpu 11:35:18 AM 0 6400 24.95 0.00 0.00 0.00 24.95 0 stress-ng-cpu 11:35:18 AM 0 6401 24.95 0.00 0.00 0.00 24.95 7 stress-ng-cpu 11:35:18 AM 0 6402 24.75 0.00 0.00 0.00 24.75 2 stress-ng-cpu 11:35:18 AM 0 6403 24.95 0.00 0.00 0.00 24.95 4 stress-ng-cpu 11:35:18 AM 0 6406 0.00 0.20 0.00 0.00 0.20 3 pidstat
[root@xlucas1 ~]# mpstat -P ALL 5 20 Linux 3.10.0-327.el7.x86_64 (xlucas1) 06/11/2021 _x86_64_ (8 CPU) 11:36:00 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 11:36:05 AM all 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:36:05 AM 0 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:36:05 AM 1 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:36:05 AM 2 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:36:05 AM 3 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:36:05 AM 4 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:36:05 AM 5 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:36:05 AM 6 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:36:05 AM 7 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
问题:
- iowait无法升高的问题,是因为案例中stress使用的是 sync() 系统调用,它的作用是刷新缓冲区内存到磁盘中。对于新安装的虚拟机,缓冲区可能比较小,无法产生大的IO压力,这样大部分就都是系统调用的消耗了。所以,你会看到只有系统CPU使用率升高。解决方法是使用stress的下一代stress-ng,它支持更丰富的选项,比如 stress-ng -i 1 --hdd 1 --timeout 600(–hdd表示读写临时文件)。
- pidstat输出中没有%wait的问题,是因为CentOS默认的sysstat稍微有点老,源码或者RPM升级到11.5.5版本以后就可以看到了。而Ubuntu的包一般都比较新,没有这个问题。
更多相关内容 -
linux中uptime命令的用法详细解析
2020-09-15 21:24:31以下是对linux中uptime命令的用法进行了详细的介绍,需要的朋友可以过来参考下 -
uptime
2021-03-27 07:20:35: :orange_square: 部分中断 这个软件库包含了开源的正常运行时间监测和状态页 ,搭载 。 借助 ,您可以获得自己不受限制的免费正常运行时间监控器和状态页面,该页面完全由GitHub存储库提供支持。... -
monitor-uptime:监视网站列表的状态
2021-02-07 19:15:50: :orange_square: 部分中断 此存储库包含的开源正常运行时间监控器和状态页面,由。 使用 ,您可以拥有自己的无限和免费的正常运行时间监控器和状态页面,完全由GitHub存储库提供支持。 我们将“用作事件报告,将... -
uptime命令 查看系统负载
2021-01-09 19:47:55Linux系统中的uptime命令主要用于获取主机运行时间和查询Linux系统负载等信息。 uptime命令可以显示系统已经运行了多长时间,信息显示依次为:现在时间、系统已经运行了多长时间、目前有多少登录用户、系统在过去的1... -
docker-uptime:Docker化的正常运行时间容器
2021-05-13 16:14:27docker-uptime Docker化的容器 用法 # Run MongoDB docker run -d --name mongodb mongo # Run Uptime and link MongoDB docker run -d -p 8082:8082 --name uptime --link mongodb:mongodb -i -t usman/docker-... -
Internet Uptime Monitor:监控您的互联网连接-开源
2021-04-26 10:27:24轻量级Windows服务,可监视您的Internet连接。 还有一个简单的GUI,用于检查连接的状态和正常运行时间。 该软件可对几个可靠的服务器(完全可配置)执行ping操作,以检查您的Internet连接是否已建立。 -
Uptime
2020-12-19 21:32:38Uptime⌘当前价格: 6⌘支持系统: OS X 10.10⌘开发者:⌘服务支持: 官方页面安全下载累计下载次数: 44A brand new application that allows you to see uptime of your computer. Have you ever been wondering how ...Uptime
⌘当前价格: 6
⌘支持系统: OS X 10.10
⌘开发者:
⌘服务支持: 官方页面
安全下载
累计下载次数: 44
A brand new application that allows you to see uptime of your computer. Have you ever been wondering how long has it been since the last restart of your machine? Now you can check it very fast from your navigation bar.
Features:
-allows you to see the uptime of your computer
Please note that this is an navigation bar application so after running it you can see uptime in navigation bar in the top of the screen.
****************
If you have any suggestions how to improve this app please contact us using this mail address: rozga.wojtek@gmail.com
If you like it please rate it on App Store, thanks!!
A brand new application that allows you to see uptime of your computer. Have you ever been wondering how long has it been since the last restart of your machine? Now you can check it very fast from your navigation bar.
Features:
-allows you to see the uptime of your computer
Please note that this is an navigation bar application so after running it you can see uptime in navigation bar in the top of the screen.
****************
If you have any suggestions how to improve this app please contact us using this mail address: rozga.wojtek@gmail.com
If you like it please rate it on App Store, thanks!!
-
Uptime标准-技术拓扑
2018-12-03 11:57:18Uptime标准-技术拓扑,2018年最新版本。 规定了不同TIER等级数据中心的配置要求。 -
Uptime Tier Standard Topology
2019-01-08 14:26:53按UPTIME分级描述满足不同要求的机电系统的冗余及系统架构 -
uptime-monitor:通过nodejs进行的正常运行时间监控。 包含网页!
2021-02-17 22:39:52使用NodeJS的运行时间监控器 这是用于监视我的服务器网络是否可用的项目。 这可以使用入站和出站。 特征 ping到特定地址 存储持续时间的运行时间历史记录 通过网页的正常运行时间历史记录 托多斯 ... -
Uptime:一个简单的Python脚本,用于监视一个或多个网站的状态
2021-05-15 07:15:19正常运行时间 一个简单的Python脚本,用于监视一个或多个网站的状态。 设置 Monitor.py脚本配置为在遇到非200状态时发送警报电子邮件。 电子邮件设置必须在smtp_config.py模块中进行配置。 设置如下: ... -
uptime-robot-api
2021-05-18 19:04:01与ES6编写的与Uptime Robot API交互的库。 特征 CRUD监控器 CRUD联系人 获取监视器列表 var Client = require ( 'uptime-robot-api' ) . Client ; var client = new Client ( 'u19921-b47e987f*********' ) ; ... -
UpTime系统已运行时间工具
2015-03-05 18:10:12软件简介: 在Win7/2008以后,使用Task Manager可以查看系统已运行...1. 增加UpTime及LastBoot的自订输出变数。 2. File选单增加重新启动程式功能,并只允许单一程式执行。 Snapshot: http://i.imgur.com/po54nit.png -
Linux uptime 命令
2021-07-08 15:33:27Linux uptime 命令 文章目录Linux uptime 命令uptime 命令使用uptime实现过程sysinfo系统调用说明sysinfo系统调用实现过程--待填坑 uptime 命令使用 输入uptime --help,可以看到当前输出以下信息: Usage: uptime ...Linux uptime 命令
uptime 命令使用
输入
uptime --help
,可以看到当前输出以下信息:Usage: uptime [options] Options: -p, --pretty show uptime in pretty format -h, --help display this help and exit -s, --since system up since -V, --version output version information and exit For more details see uptime(1).
-p
:说是以漂亮的格式显示正常运行时间。[mj] # uptime -p up 7 minutes
-s
:是输出系统启动时间?[mj] # uptime -s 1970-01-01 00:00:00
-V
:版本信息。[mj] # uptime -V uptime from procps-ng 3.3.15
默认的命令的话,就是输出启动时间,登录用户数量,过去1分钟,5分钟,15分钟的负载信息:
[mj] # uptime 00:11:58 up 11 min, 0 users, load average: 4.00, 3.24, 1.66
uptime实现过程
这个看一下
busybox
里面的busybox-1.29.1/procps/uptime.c
:主要是调用sysinfo()
系统调用来实现的获取启动时间和负载信息的过程,其他细节暂时略过。sysinfo系统调用说明
函数原型:
#include <sys/sysinfo.h> int sysinfo(struct sysinfo *info);
其中的
struct sysinfo
结构体如下:# Until Linux 2.3.16, sysinfo() used to return information in the following structure: struct sysinfo { long uptime; /* Seconds since boot */ unsigned long loads[3]; /* 1, 5, and 15 minute load averages */ unsigned long totalram; /* Total usable main memory size */ unsigned long freeram; /* Available memory size */ unsigned long sharedram; /* Amount of shared memory */ unsigned long bufferram; /* Memory used by buffers */ unsigned long totalswap; /* Total swap space size */ unsigned long freeswap; /* swap space still available */ unsigned short procs; /* Number of current processes */ char _f[22]; /* Pads structure to 64 bytes */ }; # Since Linux 2.3.23 (i386), 2.3.48 (all architectures) the structure is: struct sysinfo { long uptime; /* Seconds since boot */ unsigned long loads[3]; /* 1, 5, and 15 minute load averages */ unsigned long totalram; /* Total usable main memory size */ unsigned long freeram; /* Available memory size */ unsigned long sharedram; /* Amount of shared memory */ unsigned long bufferram; /* Memory used by buffers */ unsigned long totalswap; /* Total swap space size */ unsigned long freeswap; /* swap space still available */ unsigned short procs; /* Number of current processes */ unsigned long totalhigh; /* Total high memory size */ unsigned long freehigh; /* Available high memory size */ unsigned int mem_unit; /* Memory unit size in bytes */ char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding for libc5 */ };
可以看到,除了启动时间、负载信息外,还有一些内存相关的信息,但类似
free
的命令也可以查看到相关信息。所以这个系统调用使用还是比较简单的。
sysinfo系统调用实现过程–待填坑
在
linux-4.9.37/kernel/sys.c
里面,可以看到系统调用的定义:这里的过程也很简单,调用do_sysinfo()
获取系统信息后,拷贝到用户空间。do_sysinfo()
如下,就是调用内核各个模块提供的接口来获取各自的统计信息:
各类信息的获取需要待填坑啊~,其中平均负载的计算看资料还用到了
ewma
指数加权平均算法,后续有机会填坑吧。 -
uptime-monitor::chart_increasing:由GitHub Actions支持的正常运行时间监控器
2021-05-13 22:05:20:up_arrow: :chart_increasing: Upptime正常运行时间监控器 该存储库包含Upptime的GitHub Action。 :wrapped_gift: 贡献 该存储库用于Upptime的GitHub Action。 我们热爱贡献,因此请阅读...npx @upptime/uptime-monit -
如何给公司节约成本,搭建免费开源监控系统uptime-kuma
2022-03-03 15:59:24由于业务需要,我司的产品越来越多,api接口监控相对比较薄弱,对此要搭建HTTP(s)的监控系统,...最终找到对应的开源监控uptime-kuma,并且有以外惊喜,如果有其他的需求也可以按照此流程进行。 业务需求 1.开源、免由于业务需要,我司的产品越来越多,api接口监控相对比较薄弱,对此要搭建HTTP(s)的监控系统,之前一直使用第三方的监控系统,比如阿里云的云监控。
基本流程
1.了解需求。
2.通过各种途径了解有没有相关免费解决方案
3.本地搭建实施,评估上线。
4.上线部署 使用。
本文记录希望找到开源监控系统走的弯路,apimonitor和apitestplatform都有这样或者那样的问题。最终找到对应的开源监控uptime-kuma,并且有以外惊喜,如果有其他的需求也可以按照此流程进行。
业务需求
1.开源、免费
2.定时监控生产环境的接口链接,如果出现访问非200的、超时,则报警。
3.告警方式: 邮件、短信、钉钉群通知、电话等
4.支持本地Linux服务器部署
5.类似阿里云的“云监控”–站点监控,如图。第三方参考解决方案https://www.jiankongbao.com/
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w3s1ql3T-1646294341548)(images/image-20220302114059570.png)]
测试系统
服务器系统: Centos7
IP地址: 192.168.1.5
服务器已安装: nginx和docker
开源产品
在网上搜索、问同事和相关从业经验的人,是否有相关的监控产品。
一、系统监控产品apimonitor(项目已关闭)
apimonitor有api探测、api监控、http请求模拟、系统接口监控等功能,可以模拟http页面操作过程,并根据请求耗时和响应结果监控系统接口可用性和正确性。
开源地址: https://gitee.com/ecar_team/apimonitor
查看功能部分符合,但是需要二次开发,可以在此开源项目上开发
1.新增告警功能,通过邮件、短信、钉钉群通知等。
2.新增访问时长记录。
二、apitestplatform(亲测有bug)
一个web界面的接口自动化测试平台
git地址:https://github.com/342164796/apitestplatform
安装步骤
cd /data git clone https://github.com/342164796/apitestplatform cd apitestplatform/ 首次部署需要在settings.py文件里修改mysql的地址和账户名密码为自己的数据库地址 vi apitestplatform/settings.py 'default': { 'ENGINE': 'django.db.backends.mysql', 'HOST': "*.*.*.*", 'NAME': "apitestplatform", 'USER': "user", 'PASSWORD': "password", 'PORT': "3306", # 'CHARSET': 'utf8', # 'COLLATION': 'utf8_general_ci', } 2.初始化数据库,执行如下命令: python3.6 manage.py makemigrations python3.6 manage.py migrate python3.6 manage.py runserver
安装的踩坑记录
1.SyntaxError: invalid syntax
# python manage.py runserver File "manage.py", line 14 ) from exc ^ SyntaxError: invalid syntax python 版本太低,系统自带为2.7 升级安装 python3.6 # python -V Python 2.7.5 # python3.6 -V Python 3.6.8
2.Couldn’t import Djang
没有安装django
# python3.6 manage.py runserver Couldn't import Django. Are you sure it's installed and available on your PYTHONPATH environment variable? Did you forget to activate a virtual environment? 安装 Django 虚拟环境里用python3安django和uwsgi (如果用于生产的话,则需要指定安装和你项目相同的版本) pip3.6 install django pip3.6 install uwsgi
3.没有安装pymysql
再次报错: # python3.6 manage.py runserver ModuleNotFoundError: No module named 'pymysql' 解决: # pip3.6 install pymysql 再次报错: # python3.6 manage.py runserver ModuleNotFoundError: No module named 'django_crontab'
4.没有安装django-crontab
报错 django.db.utils.OperationalError: (2003, "Can't connect to MySQL server on '*.*.*.*' ([Errno -2] Name or service not known)") 解决: # pip3.6 install django-crontab
启动成功
# python3.6 manage.py runserver You have 29 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, base, contenttypes, sessions. Run 'python manage.py migrate' to apply them. March 02, 2022 - 10:31:01 Django version 3.2.12, using settings 'apitestplatform.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C.
启动成功
# python3.6 manage.py runserver Django version 3.2.12, using settings 'apitestplatform.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C.
nginx反向代理
server { listen 80; server_name apitest.test.me; #root /data/wwwroot/web/apitest.test.me/; access_log /data/wwwroot/log/apitest.test.me-access.log main_aliyun; error_log off; location / { proxy_pass http://127.0.0.1:8000; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } 绑定hosts访问 192.168.1.5 apitest.test.me
添加项目报错:
由于不太清楚报错的原因。放弃此开源项目。
三、开源监控uptime-kuma
继续百度搜索查找,在知乎的页面中找到一个@无为无谓 的回答,页面https://www.zhihu.com/question/23755976
他推荐了一个开源产品,uptime-kuma。
uptime-kuma地址:https://github.com/louislam/uptime-kuma
反向代理教程: https://github.com/louislam/uptime-kuma/wiki/Reverse-Proxy
演示网站:
https://demo.uptime.kuma.pet:27000/ 创建管理员账号,有10分钟的体验时间。
查看演示基本能满足需要,在本地搭建测试,功能都符合我的要求,居然还有惊喜,首先界面很精美,再次除了有基本的HTTP(S)的监控的,还有TCP端口监控、PING监控、HTTP(s)关键字监控、DNS监控、Push监控、Steam Game Server监控,功能相当多,重点是都是免费的,只要有服务器,或者局域网的虚拟机(可访问外网)就可以监控你的各种服务。
docker部署uptime-kuma
本次使用docker安装如果,需要非docker参考开源文档。
# mkdir -p /data/docker/uptime-kuma/data # docker run -d --restart=always -p 3001:3001 -v /data/docker/uptime-kuma/data:/app/data --name uptime-kuma louislam/uptime-kuma:1 # netstat -tunpl|grep 3001 tcp6 0 0 :::3001 :::* LISTEN 29542/docker-proxy-
访问:
http://192.168.1.5:3001 访问,创建管理员账号。
nginx代理访问
server { listen 80; server_name uptime.test.me; location / { proxy_pass http://localhost:3001; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; } } 绑定hosts访问 192.168.1.5 uptime.test.me
基本设置
设置里面功能还比较齐全,有外观设置,消息通知重点是消息通知有,邮件、钉钉、短信、飞书等等的第三方通知,相当齐全。
外观设置
通知设置
创建监控项
HTTPS监控图
端口TCP检测
关闭nginx,80端口:
systemctl stop nginx
报错:
重置密码
Docker环境
docker exec -it <container name> npm run reset-password
非Docker环境
# cd 项目目录 # npm run reset-password
https://github.com/louislam/uptime-kuma/wiki/Reset-Password-via-CLI
配置消息通知
Uptime Kuma提供多种的消息推送,详情请参考:https://github.com/louislam/uptime-kuma/issues/284
我这里需要Bark手机APP、配置邮件、钉钉群通知的演示,还有阿里云短信也是比较方便快捷的提醒。
配置Bark
Brak是苹果系统的一款推送软件。ios手机安装app,APP内可以获取推送地址: https://api.day.app/{密钥}/这里改成你自己的推送内容
https://api.day.app/{密钥}/这里改成你自己的推送内容
后面不能有中文,有测试测试会报错
点击“测试一下”收到消息
模拟测试
恢复测试:
钉钉群通知
了解更多:https://developers.dingtalk.com/document/robots/custom-robot-access
钉钉群获取WebHookUrl:假设为https://oapi.dingtalk.com/robot/send?access_token=abc123456
WebHookUrl:填写完整的地址、SecretKey则填写abc123456的值,我开始填写了错了,测试很久没有通过。
配置邮箱
如图配置,主机名、端口号、密码不是163的登录密码,需要在163邮箱后台开通开启IMAP/SMTP服务。获取授权密码。
测试发送邮件:
禁用身份验证
这是可选的,如果不禁用游客访问需要用户名和密码,但是你关掉后,就可以自由访问了。(后台后上角的设置,然后拉到最下面即可看到!)
设置Status Page
这个功能还是很重要的,可以把新建的监控服务放置到这个监控页面,这样就可以随时随地的看到每个系统的状态了。
点击右上角的Status Page,开始编辑,具体看图:
首页默认就会是这样的状态页。
-
linux uptime和系统负载
2021-05-13 03:29:42linux uptime命令用于显示系统已经运行了多长时间,它依次显示下列信息:现在时间、系统已经运行了多长时间、目前有多少登陆用户、系统在过去的1分钟、5分钟和15分钟内的平均负载。我们平进主机关心的是loadaverage... -
uptime1
2021-03-26 10:20:28: :orange_square: 部分中断 这个软件库包含了开源的正常运行时间监测和状态页 ,搭载 。 借助 ,您可以获得自己不受限制的免费正常运行时间监控器和状态页面,该页面完全由GitHub存储库提供支持。... -
Linux中的uptime命令详解
2021-05-13 03:30:13无选项uptime命令会显示一行信息,依次为:当前时间、系统已经运行了多长时间、目前有多少用户登录、系统在过去的1分钟、5分钟和15分钟内的平均负载。输出结果等同于top命令汇总区的第一行。2.命令格式uptime... -
Uptime-crx插件
2021-04-03 19:00:48跟踪浏览器uptime 浏览器上线跟踪器。 源代码可以在这里找到:https://github.com/aquilax/uldime-chrome。 随意混音和修改。 #changelog. v0.4切换到使用更稳定的chrome.storage.local API来存储启动时间。 V0.3... -
linux之uptime命令
2021-05-15 06:43:50名称: uptime使用权限: 所有使用者使用方式: uptime [-V]说明: uptime 提供使用者下面的资讯,不需其他参数:现在的时间系统开机运转到现在经过的时间连线的使用者数量最近一分钟,五分钟和十五分钟的系统负载...