DigitalOceanドロップレットでCPU使用率を監視する方法

1. 1. 1. はじめにメモリの量、キャッシュのサイズ、ディスクからの読み取りとディスクへの書き込みの速度、および処理能力の速度と可用性はすべて、インフラストラクチャのパフォーマンスに影響を与える重要な要素です。 この記事では、入門的なCPU監視の概念とアラート戦略に焦点を当てます。 2つの一般的なLinuxユーティリティuptimeとtopを使用して、CPUの負荷と使用率について学習する方法と、DigitalOceanアラートポリシーを設定して、ドロップレットのCPU。

前提条件

ここで説明する2つのユーティリティ、uptimeとtopは、ほとんどのLinuxディストリビューションのデフォルトインストールの一部として使用できます。 アラートポリシーなどのDigitalOcean機能を利用するには、監視が有効になっているDigitalOceanドロップレットが必要です。

ガイドDigitalOceanAgent for Monitoring をインストールして使用する方法では、新しいドロップレットでモニタリングを有効にする方法と、すでに実行されているドロップレットにモニタリングエージェントを追加する方法について説明します。

＃＃バックグラウンド

uptime、top、およびDigitalOceanモニタリングの詳細を掘り下げる前に、CPU使用率の測定方法と、どのようなパターンが望ましいかを検討します。

CPU負荷と CPU使用率

CPU負荷とCPU使用率は、コンピューターの処理能力の使用を確認する2つの異なる方法です。

この2つの主な違いを概念化するために、加工業者を食料品店のレジ係として、タスクを顧客として想像することができます。 CPU負荷は、顧客が次のレジ係が利用可能になるのを待つ単一のチェックアウトラインを持つようなものです。 負荷は、基本的に、レジにいる人を含め、列に並んでいる人の数のカウントです。 回線が長いほど、待機時間が長くなります。 対照的に、 CPU使用率は、レジ係がどれだけ忙しいかだけに関係し、何人の顧客が並んで待っているかはわかりません。

より具体的には、タスクはサーバーのCPUを使用するためにキューに入れられます。 キューの一番上に到着すると、一定の処理時間を受け取るようにスケジュールされます。 完了すると、終了します。 それ以外の場合は、キューの最後に戻ります。 いずれの場合も、次のタスクが順番に実行されます。

CPU負荷は、処理中のタスクを含む、スケジュールされたタスクのキューの長さです。 タスクは数ミリ秒で切り替わる可能性があるため、負荷の1つのスナップショットは、一定期間に取得された複数の読み取り値の平均ほど有用ではないため、負荷値は負荷平均として提供されることがよくあります。[ X217X]

CPU負荷は、CPU時間に対する需要の量を示します。 需要が高いと、CPU時間の競合やパフォーマンスの低下につながる可能性があります。

一方、 CPU使用率は、待機しているプロセスの数を認識せずに、CPUがどれだけビジーであるかを示します。 使用率を監視することで、時間の経過に伴う傾向を示し、急上昇を強調し、不要なアクティビティを特定するのに役立ちます。

非正規化値と正規化値

シングルプロセッサシステムでは、合計容量は常に1です。 マルチプロセッサシステムでは、データは2つの異なる方法で表示できます。 すべてのプロセッサの合計容量は、プロセッサの数に関係なく100 % rとしてカウントされ、これは正規化として知られています。もう1つのオプションは、各プロセッサを1つのユニットとしてカウントすることです。 -フル使用のプロセッサー・システムは200 % c apacityであり、フル使用の4プロセッサー・システムは400% capacityです。

CPUの負荷または使用量の数値を正しく解釈するには、サーバーに搭載されているプロセッサの数を知る必要があります。 ###CPU情報の表示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使用率は、システムとの対話性の応答性が低下するという代償を伴います。 多くの場合、計算量の多いアプリケーションやバッチジョブは、フルキャパシティーまたはほぼフルキャパシティーで一貫して実行するのが適切です。 ただし、システムがWebページを提供したり、SSHなどのサービスに応答性の高いインタラクティブセッションを提供したりすることが期待される場合は、アイドル状態の処理能力を利用できることが望ましい場合があります。

パフォーマンスの多くの側面と同様に、システム上のサービスの特定のニーズについて学習し、予期しない変更を監視することが、リソースを最適化するための鍵となります。

1. 1. CPUの監視システムのCPUステータスを洞察するためのツールは多数あります。 uptimeとtopの2つのコマンドを見ていきます。 どちらも最も一般的なLinuxディストリビューションのデフォルトのインストールの一部であり、CPUの負荷と使用率を調査するためにオンデマンドで一般的に使用されます。 次の例では、上記でプロファイルした2コアのドロップレットを調べます。 ### uptime uptimeコマンドから始めて、CPU負荷を確認します。これは、基本的なCPU負荷の平均のみを示していますが、システムに必要なシステムが少ないため、システムが対話型クエリにゆっくりと応答する場合に役立ちます。資力。

稼働時間の表示：

• コマンドが実行された時点のシステム時刻
• サーバーが実行されていた時間
• ユーザーがマシンに接続した回数
• 過去1、5、および15分間のCPU負荷の平均。

 uptime

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

この例では、コマンドは、ほぼ23時間稼働していたサーバーで午後2時8分に実行されました。 uptimeの実行時に、2人のユーザーが接続しました。 このサーバーには2つのCPUがあるため、コマンドが実行される前の1分間のCPU負荷平均は2.00であり、その1分間に平均して2つのプロセスがCPUを使用し、待機しているプロセスはありません。 5分間の平均負荷は、その間隔の一部で、約60% ofの時間アイドル状態のプロセッサがあったことを示しています。 15分の値は、さらに多くの利用可能な処理時間があったことを示します。 3つの図を合わせると、過去15分間の負荷の増加がわかります。

稼働時間は、負荷の平均を一目で確認するのに役立ちますが、より詳細な情報を取得するために、トップに戻ります。 ### top uptimeと同様に、topはLinuxシステムとUnixシステムの両方で使用できますが、事前設定された履歴間隔の負荷平均を表示するだけでなく、定期的なリアルタイムのCPU使用率情報やその他の情報を提供します。関連するパフォーマンスメトリック。 uptimeが実行および終了するのに対し、topはフォアグラウンドに留まり、定期的に更新されます。

top

ヘッダーブロック最初の5行は、サーバー上のプロセスに関する要約情報を提供します。

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と同様に、1分、5分、および15分の平均負荷が表示されます。 この行とuptimeの出力の唯一の違いは、行の先頭にコマンド名topが表示され、topが更新するたびに時刻が更新されることです。データ。
• 2行目は、タスクの状態の概要を示しています。プロセスの総数に続いて、実行中、スリープ中、停止中、またはゾンビの数が続きます。
• 3行目は、CPU使用率について示しています。 これらの数値は正規化され、パーセンテージ（% s記号なし）で表示されるため、CPUの数に関係なく、この行のすべての値の合計は100% rになります。
• ヘッダー情報の4行目と5行目は、それぞれメモリとスワップの使用状況を示しています。

最後に、ヘッダーブロックの後に、個々のプロセスに関する情報を含むテーブルが続きます。これについては、後で説明します。

以下のヘッダーブロックの例では、1分間の平均負荷がプロセッサ数を0.77超えており、待機時間が少しある短いキューを示しています。 合計CPU容量は100% uティル化されており、十分な空きメモリがあります。

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：ニックのないユーザープロセスの実行時間このカテゴリは、明示的なスケジューリング優先度なしで開始されたユーザープロセスを指します。 具体的には、Linuxシステムはniceコマンドを使用してプロセスのスケジューリング優先度を設定します。したがって、「un-niced」はniceがデフォルト値の変更に使用されなかったことを意味します。 userおよびniceの値は、すべてのユーザープロセスを説明します。 このカテゴリのCPU使用率が高い場合は、プロセスが暴走している可能性があります。プロセステーブルの出力を使用して、これが当てはまるかどうかを確認できます。
• sy、システム：カーネルプロセスの実行時間ほとんどのアプリケーションには、ユーザーコンポーネントとカーネルコンポーネントの両方があります。 Linuxカーネルがシステムコールの作成、アクセス許可の確認、アプリケーションに代わってデバイスとの対話などを行っている場合、カーネルによるCPUの使用状況がここに表示されます。 プロセスが独自の作業を行っている場合、プロセスは上記の userの図に表示されます。優先度がniceコマンドを使用して明示的に設定されている場合はnice[ X187X]次の図。
• ni、nice：niceedユーザープロセスの実行時間 user と同様に、これはカーネルを含まないプロセスタスクを指します。 userとは異なり、これらのタスクのスケジューリング優先度は明示的に設定されました。 プロセスの良さのレベルは、ヘッダーNIの下のプロセステーブルの4番目の列に示されています。 通常以上の優先度のタスクは必要なときに処理能力を得ることができるため、CPU時間を多く消費する1〜20のniceness値を持つプロセスは一般に問題ではありません。 ただし、-1から-20の間の高いレベルのタスクが、不均衡な量のCPUを使用している場合、それらはシステムの応答性に簡単に影響を与える可能性があり、さらに調査する必要があります。 システムに応じて-19または-20の最高のスケジューリング優先度で実行される多くのプロセスは、システムの安定性に影響を与える重要なタスクを実行するためにカーネルによって生成されることに注意してください。 表示されているプロセスについてよくわからない場合は、プロセスを強制終了するのではなく、調査することをお勧めします。
• id、idle：カーネルアイドルハンドラーで費やされた時間この数値は、CPUが使用可能でアイドル状態であった時間の割合を示します。 user 、 nice 、および idle の合計値がほぼ100％の場合、システムは一般にCPUに関して正常に動作しています。
• wa、IO-wait：I /O完了を待機する時間IO-waitの図は、プロセッサが読み取りまたは書き込みアクティビティを開始し、I/O操作が完了するのを待機していることを示しています。 NFSやLDAPなどのリモートリソースの読み取り/書き込みタスクもIO待機にカウントされます。 アイドル時間と同様に、ここでのスパイクは正常ですが、この状態での頻繁または持続的な時間は、非効率的なタスク、低速のデバイス、または潜在的なハードディスクの問題を示唆しています。
• hi：ハードウェア割り込みの処理に費やされた時間これは、ディスクやハードウェアネットワークインターフェイスなどの周辺機器からCPUに送信される物理的な割り込みに費やされた時間です。 ハードウェア割り込みの値が高い場合、周辺機器の1つが正常に動作していない可能性があります。
• si：ソフトウェア割り込みの処理に費やされた時間ソフトウェア割り込みは、物理デバイスではなくプロセスによって送信されます。 CPUレベルで発生するハードウェア割り込みとは異なり、ソフトウェア割り込みはカーネルレベルで発生します。 ソフトウェア割り込みの値が多くの処理能力を使用している場合は、CPUを使用している特定のプロセスを調査してください。
• st：ハイパーバイザーによってこの仮想マシンから盗まれた時間「スティール」値は、ハイパーバイザーがそれ自体または別の仮想CPUにサービスを提供している間に仮想CPUが物理CPUの待機に費やす時間を示します。 基本的に、このフィールドのCPU使用量は、VMが使用できる処理能力を示しますが、物理ホストまたは別の仮想マシンによって使用されているため、アプリケーションでは使用できません。 一般に、最大10% fまたは短時間のスティール値が表示されることは心配する必要はありません。 長期間の大量のスティールは、物理サーバーがサポートできるよりも多くのCPUを必要としていることを示している可能性があります。

topのヘッダーブロックで提供されるCPU使用率の概要を確認したので、CPU固有の列に注目して、その下に表示されるプロセステーブルを確認します。 。

プロセステーブルサーバーで実行されているすべてのプロセスは、どの状態でも、サマリーブロックの下に一覧表示されます。 以下の例には、上記のセクションのtopコマンドのプロセステーブルの最初の6行が含まれています。 デフォルトでは、プロセステーブルは％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％はパーセント値として表示されますが、正規化されていないため、この2コアシステムでは、両方のプロセッサが完全に使用されている場合、プロセステーブルのすべての値の合計が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

これまで、CPU負荷とCPU使用率を調べるために一般的に使用される2つのLinuxコマンドについて説明してきました。 次のセクションでは、DigitalOceanDropletsで追加費用なしで利用できるCPU監視ツールについて説明します。

CPU使用率のDigitalOceanモニタリング

デフォルトでは、コントロールパネルでドロップレット名をクリックすると、すべてのドロップレットに帯域幅、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％を超えているまた、平均よりはるかに高いしきい値を設定することもできます。これは、重要と見なされ、迅速な調査が必要なしきい値です。 たとえば、5分間隔で50％のCPU使用が持続したサーバーが、かなり定期的に90％まで急上昇した場合は、すぐにログインして状況を調査することをお勧めします。 この場合も、しきい値はシステムのワークロードに固有です。

1. 1. 結論この記事では、uptimeとtop、Linuxシステム上のCPUに関する洞察を提供する2つの一般的なLinuxユーティリティ、およびDigitalOceanMonitoringを使用して履歴を確認する方法について説明しました。ドロップレットのCPU使用率、および変更や緊急事態を警告します。

• DigitalOcean Monitoringの詳細については、DigitalOceanMonitoringの概要を参照してください。
• 標準、高メモリ、および高CPUプランのいずれかを選択するためのガイダンスについては、アプリケーションに適したドロップレットの選択を参照してください。
• よりきめ細かい監視サービスをお探しの場合は、 Zabbix 、 Icinga 、TICKなどの特定のツールの使用について詳しく知るかレビューしてください。 DigitalOceanMonitoringチュートリアルの完全なリスト。