드롭릿에서 CPU 사용을 모니터링하는 방법

소개

웹사이트나 애플리케이션이 평소보다 더 느리다고 가정해 보겠습니다. 문제 조사를 어떻게 시작합니까? 응용 프로그램이 느려지는 데는 여러 가지 원인이 있지만 때로는 서버의 CPU가 최대치에 도달했기 때문입니다. 이 안내서는 귀하가 그러한 경우인지 확인하는 데 도움이 될 것입니다.

모든 Linux 서버에서 가장 일반적으로 참조되는 두 가지 리소스 사용 지표인 CPU 사용률과 평균 로드를 이해하는 것부터 시작하겠습니다. 이 두 지표의 차이점을 살펴본 다음 uptime 및 top이라는 두 가지 명령줄 유틸리티를 사용하여 해당 값을 확인하는 방법을 살펴보겠습니다. 마지막으로 DigitalOcean Monitoring을 사용하여 시간 경과에 따라 이러한 메트릭을 추적하고 알림 정책을 설정하여 메트릭이 일반적인 값보다 높아지면 이메일이나 Slack으로 알림을 받는 방법을 살펴보겠습니다.

전제 조건

이 가이드를 따르려면 다음이 필요합니다.

모니터링이 활성화된 2코어 DigitalOcean Droplet. 새 Droplet에서 Monitoring을 활성화하거나 기존 Droplet에 Monitoring Agent를 추가하는 방법을 알아보려면 DigitalOcean Metrics Agent 설치 방법을 읽어보세요.
Droplet에 설치된 stress 유틸리티. apt 또는 dnf를 사용하여 배포 저장소에서 stress를 설치하세요.

이 가이드에 소개된 두 가지 명령줄 유틸리티인 uptime 및 top은 대부분의 Linux 배포판에서 기본적으로 사용할 수 있습니다.

배경

CPU 사용률과 부하 평균을 확인하고 추적하는 방법을 살펴보기 전에 개념적으로 살펴보겠습니다. 그들은 무엇을 측정합니까?

CPU 사용률 대 평균 로드

자주 확인하는 이 두 가지 지표는 둘 다 CPU와 관련이 있고 서버에 과부하가 걸렸을 때 높을 수 있기 때문에 때때로 혼동됩니다. 그러나 그들은 같은 것을 측정하지 않으며 항상 서로 직접적으로 연관되지 않습니다. CPU 사용률은 CPU가 현재 얼마나 바쁜지 알려주고, 평균 로드는 최근 과거에 평균적으로 CPU에서 대기하거나 실행 중인 작업 수를 알려줍니다. .

참고: CPU 작업 대기열은 1밀리초에서 다음 밀리초로 급격히 줄어들고 늘어날 수 있으므로 CPU 부하의 즉각적인 스냅샷은 별로 도움이 되지 않습니다. 그렇기 때문에 일반적인 명령줄 유틸리티는 로드 평균(일정 시간 간격 동안 소요된 CPU 로드의 평균)을 보고합니다.

식료품점의 출납원 역할을 하는 서버의 CPU와 고객 역할을 하는 작업을 상상해 보십시오. CPU 로드는 현재 금전 등록기에서 서비스를 받고 있는 사람들을 포함하여 줄을 서 있는 총 사람 수를 계산한 것입니다. CPU 사용률은 계산원이 얼마나 집중적으로 작업하고 있는지입니다.

물론 이 두 지표는 관련이 있습니다. 계산대 줄이 만성적으로 길어질 수 있는 분명한 이유 중 하나는 매장에 계산원이 너무 느리거나(또는 너무 적음) 있기 때문입니다. 그러나 다른 이유로도 회선이 백업될 수 있습니다. 고객이 품목에 대한 가격 확인을 요청하면 계산원은 다른 직원에게 그렇게 하도록 요청합니다. 계산원은 가격 확인을 기다리는 동안 다른 항목을 계속 스캔할 수 있지만 다른 항목을 스캔한 시간까지 수표가 반환되지 않으면(가격 확인원이 잠시 자리를 비웠을 수 있음) 계산원과 고객은 기다리고 있을 것입니다. 라인이 성장하는 동안 멍하니 있습니다. 이는 느리거나 사용할 수 없는 일부 I/O 장치(예: 디스크)에서 대기하는 작업과 같으며 실제로 I/O가 많은 워크로드는 평균 부하가 높지만 CPU 사용률이 낮을 수 있습니다.

이제 가격 확인원이 점심 시간에 30분 동안 자리를 비웠다고 상상해 보십시오. 그동안 가격 확인이 필요한 고객이 몇 명 더 있습니다. (CPU가 디스크의 기능을 수행할 수 없는 것처럼 유휴 출납원은 스스로 가격 확인을 할 수 없다고 가정합니다.) 출납원은 이 모든 고객을 한쪽으로 치우고 나머지 고객을 통해 계산대를 비웁니다. 출납원은 현재 유휴 상태(~0% 사용률)이지만 모든 사람이 가격 확인원이 돌아올 때까지 기다리고 있기 때문에 그녀가 아직 계산을 완료할 수 없지만 여전히 그녀의 시간이 필요한 몇 명의 고객이 서 있습니다(제로 부하가 아님). 출납원에 대한 수요가 있지만 그녀는 바쁘지 않기 때문에 새로운 고객이 금전 등록기에 접근하면 즉시 서비스를 받을 것입니다.

계산원의 잘못이 아닌데도 대기 시간이 늘어나는 다른 식료품점 문제를 상상할 수 있지만 이러한 문제를 고려하면 CPU 사용률, 로드 평균, I/O 대기 및 CPU 스케줄링에 대한 보다 철저한 논의로 이어질 것입니다. 이러한 논의는 이 가이드의 범위를 벗어나므로 지금은 다음을 기억하세요.

로드 평균은 CPU 사용률에 대한 프록시가 아닙니다. 그것들은 같은 것이 아닙니다.
CPU 부하는 CPU 수요를 의미합니다. 성능이 낮은 CPU는 이러한 요구를 부풀릴 수 있지만 다른 것, 즉 I/O 대기도 마찬가지입니다. 로드 평균은 일반적으로 CPU 관련 메트릭으로 간주되지만 CPU에 관한 것만은 아닙니다. 그래서
더 많은 CPU를 추가하거나 더 빠른 CPU를 추가하여 높은 로드 평균을 항상 완화할 수는 없습니다.

그렇다면 서버는 이러한 메트릭을 어떻게 나타냅니까?

측정 단위

CPU 사용률은 시스템의 총 CPU 용량에 대한 백분율로 표시됩니다. 단일 프로세서 시스템에서 총 CPU 용량은 항상 100%입니다. 다중 프로세서 시스템에서 용량은 정규화 또는 비정규화의 두 가지 방식으로 나타낼 수 있습니다.

정규화된 용량은 프로세서 수에 관계없이 모든 프로세서의 결합된 용량을 100%로 간주함을 의미합니다. 2-프로세서 시스템의 두 CPU 사용률이 50%인 경우 정규화된 총 사용률은 50%입니다.

비정규화 용량은 각 프로세서를 용량이 100%인 단위로 계산하므로 프로세서가 2개인 시스템은 200%, 프로세서가 4개인 시스템은 용량이 400%인 식입니다. 2프로세서 시스템의 두 CPU 사용률이 모두 50%인 경우 비정규화 총 사용률은 100%(최대 200%의 절반)입니다. 2-프로세서 시스템에서 정규화되지 않은 수치.

로드 평균은 모든 CPU에서 대기 중이거나 현재 처리 중인 작업의 평균 수를 나타내는 십진수로 표시됩니다. 4-프로세서 시스템에는 4개의 프로세서 대기열이 있으며, 평균적으로 4개의 CPU가 대기열에서 대기 중인 작업 없이 각각 하나의 작업을 수행하는 경우 로드 평균은 4.0이 됩니다. 괜찮아요. 반면에 단일 프로세서 시스템에서 로드 평균이 4.0이면 더 문제가 됩니다. 이는 평균적으로 단독 프로세서가 대기열에서 대기 중인 3개의 작업과 함께 하나의 작업을 처리하고 있음을 의미합니다.

로드 평균 값은 정규화되지 않습니다. 어떤 도구도 4프로세서 4작업 사례를 로드 평균이 1.0으로 보고하지 않습니다. 평균적으로 실행 중이거나 CPU를 기다리는 총 4개의 작업이 있는 경우 로드 평균은 항상 4.0이 되지만 CPU는 많습니다.

따라서 탐색하려는 메트릭을 이해하려면 먼저 서버에 있는 CPU 수를 알아야 합니다.

얼마나 많은 CPU가 있습니까?

2코어 Droplet이 있다는 것을 이미 알고 있지만 --all 옵션과 함께 nproc 명령을 사용하여 모든 서버의 프로세서 수를 표시할 수 있습니다. --all 플래그가 없으면 nproc는 현재 프로세스에 사용 가능한 처리 장치의 수를 표시합니다. 이 수는 사용 중인 프로세서의 총 수보다 적습니다. .

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 사용률 및 로드 평균에 대한 최적 값은 무엇입니까?

서버의 최적 CPU 사용률은 해당 역할에 따라 다릅니다. 일부 서버는 CPU를 최대한 활용하도록 되어 있습니다. 다른 사람들은 그렇지 않습니다. 통계 분석 또는 암호화 작업을 수행하는 애플리케이션 또는 배치 작업은 전체 용량 또는 거의 최대 용량에서 CPU에 지속적으로 부담을 줄 수 있지만 웹 서버는 일반적으로 그렇지 않습니다. 웹 서버가 CPU를 최대한 활용하고 있는 경우 CPU가 더 많거나 더 빠른 서버로 무심코 업그레이드하지 마십시오. 그보다는 CPU 주기를 갉아먹는 맬웨어나 기타 제멋대로인 프로세스(합법적이든 아니든)가 없는지 확인해야 합니다.

어떤 서버에서든 CPU 사용률이 100%(정규화됨)로 지속되는 것을 원하지는 않지만 연산 집약적인 애플리케이션의 경우 100% 바로 아래에 머무르는 것이 적절합니다. 그렇지 않은 경우 필요한 것보다 더 많은 CPU 성능을 보유하고 있을 수 있으며 서버 다운그레이드(또는 더 적은 수의 서버 사용)로 비용을 절약할 수 있습니다.

로드 평균의 최적 값은 CPU 수 이하입니다. 2프로세서 시스템의 로드 평균이 2.0 미만으로 유지되는 한 CPU 시간 경합이 거의 발생하지 않는다는 것을 확신할 수 있습니다. (대기열은 짧은 시간 동안 거의 확실하게 팽창합니다.)

가동 시간으로 부하 평균 확인

uptime 명령은 로드 평균을 확인하는 빠른 방법입니다. 시스템이 명령줄에서 느리게 응답하는 경우(즉, 높은 로드로 인해)에도 가볍고 빠르게 실행되기 때문에 도움이 될 수 있습니다.

uptime 명령은 다음을 표시합니다.

시스템 시간
서버가 실행된 시간
현재 로그인한 사용자 수
지난 1분, 5분, 15분 동안의 로드 평균

 uptime

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

이 예에서 명령은 거의 23시간 동안 가동된 서버에서 오후 2시 8분에 실행되었습니다. 두 명의 사용자가 로그인했습니다. 첫 번째 로드 평균 수치인 2.00은 1분 로드 평균입니다. 이 서버에는 2개의 CPU가 있으므로 부하 평균 2.00은 uptime이 실행되기 전 1분 동안 평균적으로 2개의 프로세스가 CPU를 사용하고 대기 중인 프로세스가 없음을 의미합니다. 5분 로드 평균은 해당 간격 동안 약 60%의 시간 동안 유휴 프로세서가 있었음을 나타냅니다. 15분 값은 사용 가능한 CPU 시간이 더 많았음을 나타냅니다. 세 수치는 함께 지난 15분 동안 CPU 수요의 증가를 보여줍니다.

이 유틸리티는 로드 평균에 대한 유용한 정보를 제공하지만 더 자세한 정보를 보려면 top을 살펴보겠습니다.

top으로 CPU 사용률 확인

uptime과 마찬가지로 top은 Linux 및 Unix 시스템 모두에서 사용할 수 있지만 uptime과 동일한 로드 평균을 표시하는 것 외에도 전체 시스템 및 프로세스별 수치를 모두 제공합니다. CPU 사용률, 메모리 사용량 등을 위해. uptime이 실행되고 종료되는 반면 top은 대화형입니다. 시스템 리소스 사용량에 대한 대시보드를 표시하고 전면에 유지되며 q를 눌러 종료할 때까지 몇 초마다 새로 고쳐집니다.

top을 실행하기 전에 Droplet에 작업할 항목을 제공하세요. 다음 명령을 실행하여 CPU에 약간의 부담을 줍니다.

stress -c 2

이제 Droplet에 대한 다른 터미널을 열고 top을 실행합니다.

top

이렇게 하면 리소스 활용 요약과 모든 시스템 프로세스 테이블을 보여주는 대화형 화면이 나타납니다. 먼저 상단의 요약 정보를 살펴보겠습니다.

헤더 블록

다음은 top의 처음 다섯 줄입니다.

Outputtop - 22:05:28 up  1:02,  3 users,  load average: 2.26, 2.27, 2.19
Tasks: 109 total,   3 running, 106 sleeping,   0 stopped,   0 zombie
%Cpu(s): 99.8 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.2 st
MiB Mem :   1975.7 total,   1134.7 free,    216.4 used,    624.7 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   1612.0 avail Mem

첫 번째 줄은 uptime의 출력과 거의 동일합니다. uptime과 마찬가지로 1분, 5분 및 15분 로드 평균이 표시됩니다. 이 줄과 uptime의 출력 사이의 유일한 차이점은 줄의 시작 부분에 명령 이름 top이 표시되고 시간이 top 때마다 업데이트된다는 것입니다. 는 데이터를 새로 고칩니다.

두 번째 줄은 모든 시스템 작업의 상태를 요약합니다. 즉, 전체 프로세스 수와 실행 중, 잠자기, 중지 또는 좀비 중 몇 개가 이어집니다.

세 번째 줄은 CPU 사용률에 대해 알려줍니다. 이 수치는 정규화되어 % 기호 없이 백분율로 표시되므로 CPU 수에 관계없이 이 줄의 모든 값을 합하면 100%가 됩니다. top을 실행하기 직전에 -c(CPU) 옵션으로 stress 명령을 시작했기 때문에 첫 번째 수치인 us 또는 사용자 프로세스 - 100%에 가까워야 합니다.

네 번째와 다섯 번째 줄은 각각 메모리와 스왑 사용량에 대해 알려줍니다. 이 가이드는 메모리 및 스왑 사용량을 탐색하지 않지만 필요할 때 사용할 수 있습니다.

이 헤더 블록 다음에는 잠시 후에 살펴볼 각 개별 프로세스에 대한 정보가 포함된 테이블이 옵니다.

아래 예제 헤더 블록에서 1분 로드 평균은 프로세서 수를 .77만큼 초과하여 약간의 대기 시간이 있는 짧은 대기열을 나타냅니다. CPU가 100% 활용되고 여유 메모리가 충분합니다.

Output
top - 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 라인의 각 필드를 자세히 살펴보겠습니다.

우리, 사용자: un-niced 사용자 프로세스를 실행하는 시간

sy, 시스템: 커널 프로세스 실행 시간

ni, nice: niced 사용자 프로세스 실행 시간

id, idle: 커널 유휴 처리기에서 보낸 시간

wa, IO-wait: I/O 완료를 기다리는 시간

안녕, 하드웨어 인터럽트: 하드웨어 인터럽트 서비스에 소요된 시간

si, 소프트웨어 인터럽트: 소프트웨어 인터럽트 서비스에 소요된 시간

st, steal: 하이퍼바이저가 이 VM에서 훔친 시간

이제 top의 헤더에 제공된 CPU 사용량 요약을 살펴보았으므로 CPU별 열에 주의하면서 그 아래에 나타나는 프로세스 테이블을 살펴보겠습니다.

프로세스 테이블

다음은 일부 예제 top 출력에서 프로세스 테이블의 처음 6줄입니다.

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 열로 정렬되므로 가장 많은 CPU 시간을 소비하는 프로세스가 맨 위에 표시됩니다.

%CPU 값은 백분율 값으로 표시되지만 헤더의 CPU 사용률 수치와 달리 프로세스 테이블의 값은 정규화되지 않으므로 이 2코어 시스템에서 모든 프로세스 테이블의 값은 두 프로세서가 완전히 활용될 때 최대 200%가 되어야 합니다.

참고: 여기에서 정규화된 값을 보려면 SHIFT+I를 눌러 디스플레이를 Irix 모드에서 Solaris 모드로 전환하십시오. 이제 %CPU 값의 합계는 100%를 초과하지 않습니다. Solaris 모드로 전환하면 Irix 모드가 꺼져 있다는 간단한 메시지가 표시되며 이 예에서는 stress 프로세스의 값이 각각 거의 100%에서 각각 약 50%로 전환됩니다. .

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

다음과 같은 다양한 키 입력을 사용하여 top과 서버의 프로세스를 대화식으로 제어할 수 있습니다.

SHIFT-M 메모리 사용량에 따라 프로세스를 정렬합니다.
SHIFT-P CPU 사용량별로 프로세스를 정렬합니다.
k, 프로세스 ID(PID) 및 신호가 뒤따르며 제어할 수 없는 프로세스를 종료합니다. PID를 입력한 후 기본값인 15(SIGTERM) 신호를 먼저 시도합니다. 9(SIGKILL)를 함부로 사용하지 마십시오.
r 다음에 프로세스 ID를 붙여 프로세스를 재조정(재지정)합니다.
c는 짧은 설명(기본값)과 전체 명령 문자열 간에 명령 설명을 전환합니다.
d는 top에 있는 수치의 새로 고침 간격을 변경합니다.

그리고 더 많은. 자세한 내용은 top의 매뉴얼 페이지(man top)를 참조하세요.

지금까지 로드 평균 및 CPU 사용률을 조사하는 데 일반적으로 사용되는 두 가지 Linux 명령을 살펴보았습니다. 이러한 도구는 유용하지만 짧은 시간 동안 서버의 상태를 엿볼 수만 있습니다. 그곳에 앉아서 top을 볼 수 있는 시간은 얼마 남지 않았습니다. 서버 리소스 사용의 장기적인 패턴을 더 잘 파악하려면 일종의 모니터링 솔루션이 필요합니다. 다음 섹션에서는 추가 비용 없이 DigitalOcean Droplets에 사용할 수 있는 모니터링 도구에 대해 간략하게 살펴보겠습니다.

DigitalOcean 모니터링으로 시간 경과에 따른 지표 추적

기본적으로 모든 Droplet은 제어판에서 Droplet 이름을 클릭할 때 대역폭, CPU 및 디스크 I/O 그래프를 표시합니다. 이 세 그래프를 얻기 위해 DigitalOcean Agent를 설치할 필요는 없습니다.

이 그래프는 지난 1시간, 6시간, 24시간, 7일 및 14일 동안 각 리소스의 사용을 시각화하는 데 도움이 됩니다. CPU 그래프는 CPU 사용률 정보를 제공합니다. 진한 파란색 선은 사용자 프로세스의 CPU 사용을 나타냅니다. 하늘색은 시스템 프로세스에서 CPU를 사용하고 있음을 나타냅니다. 그래프의 값과 세부 정보는 가상 코어 수에 관계없이 총 용량이 100%가 되도록 정규화됩니다.

그래프를 통해 사용량이 간헐적으로 변하는지 지속적으로 변하는지 확인할 수 있으며 서버 CPU 사용량 패턴의 변화를 파악하는 데 도움이 됩니다.

이러한 기본 그래프를 보완하기 위해 Droplet에 DigitalOcean Agent를 설치하여 로드 평균, 디스크 사용량 및 메모리 사용량과 같은 추가 데이터를 수집하고 표시할 수 있습니다. 에이전트를 사용하면 시스템에 대한 경고 정책을 설정할 수도 있습니다. DigitalOcean Agent for Monitoring 설치 및 사용 방법 설정에 도움이 될 수 있습니다.

에이전트가 설치되면 리소스 사용량에 대해 알리도록 경고 정책을 설정할 수 있습니다. 선택하는 임계값은 서버의 일반적인 워크로드에 따라 다릅니다.

참고: DigitalOcean Monitoring Agent를 설치할 때:

CPU 사용률에 대해 하나의 값만 표시됩니다. 더 이상 시스템 대 사용자 공간 활용이 표시되지 않습니다.
에이전트를 설치하기 전의 모든 메트릭 기록을 잃게 됩니다.

경고 예

변화 모니터링: CPU 1% 이상

주로 테스트 코드를 통합하고 소킹하기 위해 Droplet을 사용하는 경우 서버에 푸시된 새 코드가 CPU 사용량을 증가시켰는지 감지하기 위해 기록 패턴보다 약간 높은 경고를 설정할 수 있습니다. CPU가 1%에 도달하지 않는 위의 그래프에서 5분 동안 1% CPU 사용 임계값은 CPU 사용에 영향을 미치는 코드 기반 변경에 대한 조기 경고를 제공할 수 있습니다.

DigitalOcean Control Panel 왼쪽의 MANAGE 메뉴에서 Monitoring을 클릭합니다. 리소스 경고 탭(기본적으로 강조 표시됨)에서 리소스 경고 생성을 클릭합니다. 양식을 작성하고 리소스 알림 생성을 클릭합니다.

대부분의 시스템에서 이 임계값은 완전히 부적절할 가능성이 높지만, 몇 주 전의 CPU 그래프를 검토하여 정상적인 워크로드 동안 일반적인 CPU 사용률을 결정할 수 있다면 정상 사용률보다 약간 높은 임계값으로 경고를 생성하고 학습할 수 있습니다. 새 코드 또는 새 서비스가 CPU 사용률에 영향을 미칠 때 초기에.

비상 상황 모니터링: CPU 사용률 90% 이상

또한 중요하다고 생각하고 신속한 조사가 필요한 평균보다 훨씬 높은 임계값을 설정할 수도 있습니다. 예를 들어, 5분 간격으로 CPU 사용률이 50%를 유지하던 서버가 갑자기 갑자기 90%까지 올라가는 경우 즉시 로그인하여 상황을 조사할 수 있습니다. 다시 말하지만 임계값은 시스템의 작업 부하에 따라 다릅니다.

결론

이 기사에서는 Linux 시스템의 CPU 사용률 및 평균 로드에 대한 통찰력을 제공하는 두 가지 일반적인 Linux 유틸리티인 uptime 및 top과 DigitalOcean을 사용하는 방법을 살펴보았습니다. Droplet의 과거 CPU 사용률을 확인하고 변경 사항 및 긴급 상황을 알리기 위해 모니터링합니다. DigitalOcean 모니터링에 대해 자세히 알아보려면 설명서를 읽어보십시오.

워크로드에 필요한 Droplet 종류를 결정하는 데 도움이 필요하면 올바른 Droplet 계획 선택을 읽어보세요.