精华内容
下载资源
问答
  • uptime的讲解
    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-ng

    yum 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命令的用法进行了详细的介绍,需要的朋友可以过来参考下
  • uptime

    2021-03-27 07:20:35
    : :orange_square: 部分中断 这个软件库包含了开源的正常运行时间监测和状态页 ,搭载 。 借助 ,您可以获得自己不受限制的免费正常运行时间监控器和状态页面,该页面完全由GitHub存储库提供支持。...
  • : :orange_square: 部分中断 此存储库包含的开源正常运行时间监控器和状态页面,由。 使用 ,您可以拥有自己的无限和免费的正常运行时间监控器和状态页面,完全由GitHub存储库提供支持。 我们将“用作事件报告,将...
  • Linux系统中的uptime命令主要用于获取主机运行时间和查询Linux系统负载等信息。 uptime命令可以显示系统已经运行了多长时间,信息显示依次为:现在时间、系统已经运行了多长时间、目前有多少登录用户、系统在过去的1...
  • docker-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-...
  • 轻量级Windows服务,可监视您的Internet连接。 还有一个简单的GUI,用于检查连接的状态和正常运行时间。 该软件可对几个可靠的服务器(完全可配置)执行ping操作,以检查您的Internet连接是否已建立。
  • Uptime

    2020-12-19 21:32:38
    Uptime⌘当前价格: 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:18
    Uptime标准-技术拓扑,2018年最新版本。 规定了不同TIER等级数据中心的配置要求。
  • UPTIME分级描述满足不同要求的机电系统的冗余及系统架构
  • 使用NodeJS的运行时间监控器 这是用于监视我的服务器网络是否可用的项目。 这可以使用入站和出站。 特征 ping到特定地址 存储持续时间的运行时间历史记录 通过网页的正常运行时间历史记录 托多斯 ...
  • 正常运行时间 一个简单的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*********' ) ; ...
  • 软件简介: 在Win7/2008以后,使用Task Manager可以查看系统已运行...1. 增加UpTime及LastBoot的自订输出变数。 2. File选单增加重新启动程式功能,并只允许单一程式执行。 Snapshot: http://i.imgur.com/po54nit.png
  • Linux uptime 命令

    2021-07-08 15:33:27
    Linux 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指数加权平均算法,后续有机会填坑吧。

    展开全文
  • :up_arrow: :chart_increasing: Upptime正常运行时间监控器 该存储库包含Upptime的GitHub Action。 :wrapped_gift: 贡献 该存储库用于Upptime的GitHub Action。 我们热爱贡献,因此请阅读...npx @upptime/uptime-monit
  • 由于业务需要,我司的产品越来越多,api接口监控相对比较薄弱,对此要搭建HTTP(s)的监控系统,...最终找到对应的开源监控uptime-kuma,并且有以外惊喜,如果有其他的需求也可以按照此流程进行。 业务需求 1.开源、免

    由于业务需要,我司的产品越来越多,api接口监控相对比较薄弱,对此要搭建HTTP(s)的监控系统,之前一直使用第三方的监控系统,比如阿里云的云监控。

    基本流程

    1.了解需求。

    2.通过各种途径了解有没有相关免费解决方案

    3.本地搭建实施,评估上线。

    4.上线部署 使用。

    本文记录希望找到开源监控系统走的弯路,apimonitor和apitestplatform都有这样或者那样的问题。最终找到对应的开源监控uptime-kuma,并且有以外惊喜,如果有其他的需求也可以按照此流程进行。

    mianfei-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
    

    image-20220302191408547

    添加项目报错:

    image-20220302191630117

    由于不太清楚报错的原因。放弃此开源项目。

    三、开源监控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分钟的体验时间。

    image-20220303095626971

    查看演示基本能满足需要,在本地搭建测试,功能都符合我的要求,居然还有惊喜,首先界面很精美,再次除了有基本的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 访问,创建管理员账号。

    image-20220303095955001

    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
    

    基本设置

    设置里面功能还比较齐全,有外观设置,消息通知重点是消息通知有,邮件、钉钉、短信、飞书等等的第三方通知,相当齐全。

    image-20220303100108350

    外观设置

    image-20220303100124220

    通知设置

    image-20220303100147192

    创建监控项

    image-20220303101158956

    HTTPS监控图

    image-20220303101238140

    端口TCP检测

    image-20220303103938780

    关闭nginx,80端口:

    systemctl stop nginx
    

    报错:

    image-20220303104845202

    重置密码

    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

    image-20220303143854247

    我这里需要Bark手机APP、配置邮件、钉钉群通知的演示,还有阿里云短信也是比较方便快捷的提醒。

    配置Bark

    Brak是苹果系统的一款推送软件。ios手机安装app,APP内可以获取推送地址: https://api.day.app/{密钥}/这里改成你自己的推送内容

    https://api.day.app/{密钥}/这里改成你自己的推送内容
    

    image-20220303135120761

    后面不能有中文,有测试测试会报错

    image-20220303135219785

    点击“测试一下”收到消息

    image-20220303135341440

    模拟测试

    image-20220303140013934

    恢复测试:

    image-20220303140125375

    钉钉群通知

    了解更多:https://developers.dingtalk.com/document/robots/custom-robot-access

    钉钉群获取WebHookUrl:假设为https://oapi.dingtalk.com/robot/send?access_token=abc123456

    WebHookUrl:填写完整的地址、SecretKey则填写abc123456的值,我开始填写了错了,测试很久没有通过。

    image-20220303153135776

    配置邮箱

    如图配置,主机名、端口号、密码不是163的登录密码,需要在163邮箱后台开通开启IMAP/SMTP服务。获取授权密码。

    image-20220303152548306

    测试发送邮件:

    image-20220303152834582

    禁用身份验证

    这是可选的,如果不禁用游客访问需要用户名和密码,但是你关掉后,就可以自由访问了。(后台后上角的设置,然后拉到最下面即可看到!)

    image-20220303143355330

    设置Status Page

    这个功能还是很重要的,可以把新建的监控服务放置到这个监控页面,这样就可以随时随地的看到每个系统的状态了。

    点击右上角的Status Page,开始编辑,具体看图:

    image-20220303143512692

    首页默认就会是这样的状态页。

    image-20220303143559272

    展开全文
  • linux uptime和系统负载

    2021-05-13 03:29:42
    linux uptime命令用于显示系统已经运行了多长时间,它依次显示下列信息:现在时间、系统已经运行了多长时间、目前有多少登陆用户、系统在过去的1分钟、5分钟和15分钟内的平均负载。我们平进主机关心的是loadaverage...
  • uptime1

    2021-03-26 10:20:28
    : :orange_square: 部分中断 这个软件库包含了开源的正常运行时间监测和状态页 ,搭载 。 借助 ,您可以获得自己不受限制的免费正常运行时间监控器和状态页面,该页面完全由GitHub存储库提供支持。...
  • 无选项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 提供使用者下面的资讯,不需其他参数:现在的时间系统开机运转到现在经过的时间连线的使用者数量最近一分钟,五分钟和十五分钟的系统负载...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 82,914
精华内容 33,165
关键字:

Uptime