如何监控DigitalOceanDroplets上的CPU使用情况

1. 1. 1. Introduction 内存量、缓存大小、磁盘读写速度以及处理能力的速度和可用性都是影响基础架构性能的关键因素。 在本文中，我们将重点介绍介绍性 CPU 监控概念和警报策略。 我们将描述如何使用两个常见的 Linux 实用程序 uptime 和 top 来了解您的 CPU 负载和利用率，以及如何设置 DigitalOcean 警报策略以通知您与相关的重大更改Droplet 的 CPU。

先决条件

我们讨论的两个实用程序 uptime 和 top 作为大多数 Linux 发行版的默认安装的一部分提供。 要利用警报策略等 DigitalOcean 功能，您需要启用监控的 DigitalOcean Droplet。

指南 How To Install and Use the DigitalOcean Agent for Monitoring 解释了如何在新的 Droplet 上启用 Monitoring，以及如何将 Monitoring Agent 添加到已经运行的 Droplet。

＃＃背景

在深入研究 uptime、top 和 DigitalOcean 监控的细节之前，我们将考虑如何测量 CPU 使用率以及需要什么样的模式。

CPU 负载对比 CPU 利用率

CPU 负载和 CPU 利用率是查看计算机处理能力使用情况的两种不同方法。

为了概念化两者之间的主要区别，我们可以将处理器想象成杂货店的收银员，将任务想象成顾客。 CPU 负载 就像有一条收银台，客户在此等待下一位收银员上门。 负载本质上是排队人数的计数，包括收银台的人数。 队伍越长，等待的时间就越长。 相比之下，CPU 利用率 只关心收银员的忙碌程度，不知道有多少顾客在排队等候。

更具体地说，任务排队以使用服务器的 CPU。 当一个人到达队列的顶部时，它被安排接收一定的处理时间。 如果完成，则退出； 否则返回队列末尾。 无论哪种情况，都将轮到下一个任务。

CPU负载是计划任务队列的长度，包括正在处理的任务。 任务可以在几毫秒内切换，因此负载的单个快照不如一段时间内多次读取的平均值有用，因此负载值通常以 负载平均值的形式提供。 X217X]

CPU 负载告诉我们对 CPU 时间的需求量。 高需求可能导致 CPU 时间争用和性能下降。

另一方面，CPU Utilization 告诉我们 CPU 的繁忙程度，而不知道有多少进程在等待。 监控利用率可以显示一段时间内的趋势，突出峰值，并帮助识别不需要的活动，

非归一化与归一化值

在单处理器系统上，总容量始终为 1。 在多处理器系统上，数据可以以两种不同的方式显示。 所有处理器的总容量计为 100% r，与处理器数量无关，这称为 归一化。 另一种选择是将每个处理器计为一个单元，因此 2 - 处理器系统完全使用时的容量为 200% c，4 处理器系统完全使用时的容量为 400% c，以此类推。

为了正确解释 CPU 负载或使用数据，我们需要知道服务器有多少处理器。 ###Displaying CPU Information 我们可以使用nproc 命令和--all 选项来显示处理器的数量。 如果没有 --all 标志，它将显示当前进程可用的处理单元的数量，如果有任何正在使用的处理器，它将少于处理器的总数。

nproc --all

Output of nproc2

在大多数现代 Linux 发行版上，我们还可以使用 lscpu 命令，它不仅显示处理器数量，还显示架构、型号名称、速度等等：

lscpu

Output of lscpuArchitecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             2
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Model name:            Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
Stepping:              2
CPU MHz:               1797.917
BogoMIPS:              3595.83
Virtualization:        VT-x
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              30720K
NUMA node0 CPU(s):     0,1
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm vnmi ept fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat

了解处理器的数量对于理解不同工具的 CPU 相关输出的实际含义非常重要。

1. 1. 1. 负载和利用率的最佳值是什么？ 最佳 CPU 利用率取决于服务器预期执行的工作类型。 持续的高 CPU 使用率是以降低系统交互性为代价的。 它通常适合计算密集型应用程序和批处理作业始终以或接近满容量运行。 但是，如果希望系统为网页提供服务或为 SSH 等服务提供响应式交互式会话，那么可能需要一些空闲的处理能力可用。

与性能的许多方面一样，了解系统上服务的特定需求并监控意外更改是优化资源的关键。

1. 1. Monitoring CPU 有许多工具可以深入了解系统的 CPU 状态。 我们将看两个命令，uptime 和 top。 两者都是最流行的 Linux 发行版的默认安装的一部分，通常用于按需调查 CPU 负载和利用率。 在接下来的示例中，我们将检查我们在上面描述的 2 核 Droplet。 ###uptime 我们将从 uptime 命令开始查看 CPU 负载，虽然它仅显示基本 CPU 负载平均值，但在系统响应交互式查询缓慢时会很有帮助，因为它需要很少的系统资源。

正常运行时间显示：

• 命令运行时的系统时间
• 服务器运行了多长时间
• 用户与机器的连接数
• 过去一分钟、五分钟和十五分钟的 CPU 平均负载。

 uptime

Output 14:08:15 up 22:54,  2 users,  load average: 2.00, 1.37, 0.63

在此示例中，该命令于下午 2:08 在已运行近 23 小时的服务器上运行。 运行 uptime 时连接了两个用户。 由于此服务器有 2 个 CPU，因此在运行命令前一分钟，平均 CPU 负载为 2.00 意味着在那一分钟内，平均有两个进程正在使用 CPU，并且没有进程在等待。 5 分钟的平均负载表明，在该间隔的某些时间段内，大约 60% of 时间有一个空闲处理器。 15 分钟的值表明还有更多的可用处理时间。 这三个数字一起显示了过去 15 分钟内负载的增加。

正常运行时间提供了对平均负载的有用概览，但为了获得更深入的信息，我们将转向顶部。 ###top 与 uptime 一样，top 在 Linux 和 Unix 系统上都可用，但除了显示预设历史间隔的负载平均值之外，它还提供周期性的实时 CPU 使用信息以及其他相关的性能指标。 而 uptime 运行和退出，top 停留在前台并定期刷新。

top

标题块 前五行提供有关服务器上进程的摘要信息：

Outputtop - 18:31:30 up 1 day,  3:17,  2 users,  load average: 0.00, 0.00, 0.00
Tasks: 114 total,   1 running, 113 sleeping,   0 stopped,   0 zombie
%Cpu(s):  7.7 us,  0.0 sy,  0.0 ni, 92.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.1 st
KiB Mem :  4046532 total,  3238884 free,    73020 used,   734628 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  3694712 avail Mem

• 第一行几乎与 uptime 的输出相同。 与 uptime 一样，会显示一分钟、五分钟和十五分钟的平均负载。 此行与uptime的输出唯一不同的是，行首显示的是命令名，top，每次top刷新数据。
• 第二行提供任务状态的摘要：进程总数，然后是其中有多少正在运行、休眠、停止或僵尸。
• 第三行告诉我们 CPU 利用率。 这些数字被标准化并显示为百分比（没有 % s 符号），因此该行上的所有值加起来应为 100% r，而与 CPU 数量无关。
• 标题信息的第四行和第五行分别告诉我们内存和交换的使用情况。

最后，标题块后面是一个表格，其中包含有关每个单独进程的信息，我们稍后会看一下。

在下面的示例标头块中，一分钟的平均负载比处理器数量多 0.77，这表明队列很短，等待时间很短。 CPU 总容量为 100% utilized，并且有大量可用内存。

Outputtop - 14:36:05 up 23:22,  2 users, load average: 2.77, 2.27, 1.91
Tasks: 117 total,   3 running, 114 sleeping,   0 stopped,   0 zombie
%Cpu(s): 98.3 us,  0.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.2 si,  1.3 st
KiB Mem :  4046532 total,  3244112 free,    72372 used,   730048 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  3695452 avail Mem
 . . . 

让我们更深入地看一下 CPU 行上的每个字段：

• us, user: time running un-niced user processes 这个类别是指在没有明确调度优先级的情况下启动的用户进程。 更具体地说，Linux系统使用nice命令来设置进程的调度优先级，所以“un-niced”意味着nice没有被用来改变默认值。 user 和 nice 值说明了所有用户进程。 此类别中的高 CPU 使用率可能表示进程失控，您可以使用进程表中的输出来确定是否属于这种情况。
• sy, system: time running kernel processes 大多数应用程序都有用户和内核组件。 当 Linux 内核代表应用程序执行系统调用、检查权限或与设备交互等操作时，此处会显示内核对 CPU 的使用情况。 当一个进程在做自己的工作时，它将出现在上面描述的 user 图中，或者，如果它的优先级是使用 nice 命令显式设置的，则出现在 nice[ X187X] 下图。
• ni, nice: time running niceed user processes 和 user 一样，这是指不涉及内核的进程任务。 与 用户不同， 这些任务的调度优先级是明确设置的。 进程的niceness 级别在进程表的第四列中的标题NI 下指示。 niceness 值在 1 到 20 之间且消耗大量 CPU 时间的进程通常不是问题，因为具有正常或更高优先级的任务将能够在需要时获得处理能力。 但是，如果在 -1 和 -20 之间具有较高 niceness 的任务占用了不成比例的 CPU，它们很容易影响系统的响应能力并需要进一步调查。 请注意，许多以最高调度优先级（-19 或 -20 取决于系统）运行的进程是由内核生成的，以执行影响系统稳定性的重要任务。 如果您不确定所看到的进程，谨慎的做法是调查它们而不是杀死它们。
• id, idle：在内核空闲处理程序中花费的时间 这个数字表示CPU既可用又空闲的时间百分比。 当 user、nice 和 idle 数字加起来接近 100% 时，系统通常在 CPU 方面处于良好的工作状态。
• wa, IO-wait : 等待 I/O 完成的时间 IO-wait 图显示了处理器何时开始读取或写入活动并等待 I/O 操作完成。 NFS 和 LDAP 等远程资源的读/写任务也将计入 IO-wait。 与空闲时间一样，这里的峰值是正常的，但任何频繁或持续处于这种状态的时间都表明任务效率低下、设备速度慢或潜在的硬盘问题。
• hi : 服务硬件中断所花费的时间 这是从磁盘和硬件网络接口等外围设备发送到 CPU 的物理中断所花费的时间。 当 硬件中断 值较高时，可能是其中一个外围设备无法正常工作。
• si : 服务软件中断所花费的时间 软件中断是由进程而不是物理设备发送的。 与发生在 CPU 级别的硬件中断不同，软件中断发生在内核级别。 当 软件中断 值使用大量处理能力时，请调查正在使用 CPU 的特定进程。
• st：虚拟机管理程序从该虚拟机窃取的时间 “窃取”值是指当虚拟机管理程序为自己或不同的虚拟 CPU 提供服务时，虚拟 CPU 等待物理 CPU 的时间。 从本质上讲，此字段中的 CPU 使用量表示您的 VM 准备使用多少处理能力，但由于物理主机或其他虚拟机正在使用它，因此 不是 可用于您的应用程序。 通常，看到高达 10% f 或短暂时间段的偷窃值无需担心。 更长时间的大量窃取可能表明物理服务器对 CPU 的需求比它所能支持的要多。

现在我们已经查看了 top 的标题块中提供的 CPU 使用情况摘要，我们将查看其下方显示的进程表，注意 CPU 特定列.

进程表 服务器上运行的所有进程，无论处于任何状态，都列在摘要块下方。 下面的示例包括上一节中 top 命令中进程表的前六行。 默认情况下，进程表按 %CPU 排序，因此我们首先看到消耗 CPU 最多的进程。

Output
 PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
9966 sammy     20   0    9528     96      0 R  99.7  0.0   0:40.53 stress
9967 sammy     20   0    9528     96      0 R  99.3  0.0   0:40.38 stress
   7 root      20   0       0      0      0 S   0.3  0.0   0:01.86 rcu_sched
1431 root      10 -10    7772   4556   2448 S   0.3  0.1   0:22.45 iscsid
9968 root      20   0   42556   3604   3012 R   0.3  0.1   0:00.08 top
9977 root      20   0   96080   6556   5668 S   0.3  0.2   0:00.01 sshd
...

CPU% 以百分比值表示，但未标准化，因此在这个双核系统上，当两个处理器都充分利用时，进程表中所有值的总和应为 200%。

注意： 如果您希望查看标准化值，可以按 SHIFT + I，显示将从 Irix 模式切换到 Solaris 模式。 这将显示相同的信息，在服务器的 CPU 总数上取平均值，因此使用的数量不会超过 100%。 当我们切换到 Solaris 模式时，我们会收到一条简短的消息，即 Irix 模式已关闭，并且我们的压力过程的值将从接近 100% each 切换到大约 50% each。

Output  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
10081 sammy     20   0    9528     96      0 R 50.0  0.0   0:49.18 stress
10082 sammy     20   0    9528     96      0 R 50.0  0.0   0:49.08 stress
 1439 root      20   0  223832  27012  14048 S  0.2  0.7   0:11.07 snapd
    1 root      20   0   39832   5868   4020 S  0.0  0.1   0:07.31 systemd

到目前为止，我们已经检查了两个 Linux 命令，它们通常用于查看 CPU 负载和 CPU 利用率。 在下一节中，我们将研究可用于 DigitalOcean Droplets 的免费 CPU 监控工具。

用于 CPU 利用率的 DigitalOcean 监控

默认情况下，当您在控制面板中单击 Droplet 名称时，所有 Droplet 都会显示带宽、CPU 和磁盘 I/O 图：

这些图表可视化每个资源在过去 6 小时、24 小时、7 天和 24 小时内的使用情况。 CPU 图提供 CPU 利用率信息。 深蓝色线表示用户进程使用 CPU。 浅蓝色表示系统进程使用 CPU。 图表上的值及其详细信息已标准化，因此总容量为 100% r，而与虚拟内核的数量无关。

这些图表可让您了解您的使用情况是间歇性变化还是持续性变化，并且有助于发现服务器 CPU 使用模式的变化。

除了这些默认图表，您还可以在 Droplet 上安装 DigitalOcean Agent 以收集和显示其他数据。 代理还允许您为系统设置警报策略。 如何安装和使用 DigitalOcean Agent for Monitoring 可以帮助您进行设置。

安装代理后，您可以设置警报策略以通知您有关资源使用情况。 您选择的阈值将取决于工作负载。

1. 1. 1. 示例警报

监控变化：CPU 高于 1% 如果您使用 Droplet 主要用于集成和浸泡测试代码，您可能会设置一个略高于历史模式的警报，以便检测是否有新代码推送到服务器增加了 CPU 使用率。 对于上图中 CPU 从未达到 1% 的图表，5 分钟内 1% 的 CPU 使用阈值可以提供有关影响 CPU 使用的基于代码的更改的早期警告。

在大多数系统上，这个阈值很可能完全不合适，但是通过调整持续时间并将阈值设置为略高于当前平均负载，您可以及早了解新代码或新服务何时影响 CPU 利用率。

监控紧急情况：CPU 利用率超过 90% 您可能还想设置一个远高于平均值的阈值，您认为该阈值很关键，需要立即进行调查。 例如，如果某台服务器在五分钟的时间间隔内持续使用 50% 的 CPU 使用率突然飙升至 90%，您可能需要立即登录以调查情况。 同样，阈值特定于系统的工作负载。

1. 1. 结论 在本文中，我们探讨了 uptime 和 top 这两个常见的 Linux 实用程序，可以深入了解 Linux 系统上的 CPU，以及如何使用 DigitalOcean Monitoring 查看历史Droplet 上的 CPU 利用率，并提醒您注意变化和紧急情况。

• 要了解有关 DigitalOcean 监控的更多信息，请参阅 DigitalOcean 监控简介
• 有关在标准、高内存和高 CPU 计划之间进行选择的指导，请参阅 为您的应用程序选择合适的 Droplet 。
• 如果您正在寻找更细粒度的监控服务，您可能想了解更多有关使用特定工具的信息，例如 Zabbix、Icinga 和 TICK 或查看DigitalOcean Monitoring教程的完整列表。