最近障害対応をすることがあったのだが、
メトリックってどうやって読むんだ? ということになったので、
メモがてら残しておきます。

load average

load average はサーバー全体の負荷を考えるための指標です。
average と名の付く通り、これは平均を表していて、 System load/CPU Load といって、１CPUが実行待ちしているプロセスの数であり、それが単位時間(1分,5分,15分)当たりで平均でそれだけ存在しているか？
というのが大まかな定義です。

プロセスはCPUが実行可能な状態であれば即座に実行しようとするので、CPUにどれだけの負荷がかかっているかのを見るということになります。

例えば、シングルCPUのシステムで過去の1分のload averageが0.5、の場合は30秒はCPUは捌くプロセスが無くて待機中だった。言えます。 (処理の総量 < CPUの処理速度)

逆に単位時間1分のload averageが 5.05の場合だと、1分間に平均して、5個のプロセスが実行待ちであったといえ、その分だけプロセスを実行できなかったといえます。(処理の総量 > CPUの処理速度)

今回は、CPUが一つしかないという前提でしたが、今時のマルチCPUでも見方や考え方は同じです。もし実際にこの指標をみる場合は、監視するサーバーのCPU数を把握して確認しましょう。

また、注意として、load averageが高いからといってCPU負荷も一緒に高いとは限りません。これはIO処理に負荷がかかっていた場合、そもそもIOwaitの状態になってCPUは仕事ができません。なので、load averageが高い場合は cpu と disk(IO)の値を見るようにしましょう。

file system

これは、 シンプルにディスクサイズとその使用量 を表しています。

特にログやストレージサーバーのように何かのファイルを保存するといったサーバーであれば、
こまめに確認するなり、アラートを特定のディスク量を使用したらアラートを出すようすべきでしょう。

大抵の問題はディスクサイズを最大限使い切って、新しいログを吐けなかったり、ファイルをアップロードできないといった類なので、
特に↑のことを気に留めていれば問題ないかなと思います。

disk

ディスクの読み書き ようはI/Oです。
これは IOPS(1秒当たりの読み書き量)が使われます。

計算式としては
IOPS = 1/ (平均アクセス時間 + データ転送時間)

端的に言うと、　書きたい場所にアクセスして、実際にデータを書き込むという作業の時間が一秒間に何回できるかといった感じです。
これは、サーバーによって既に限界が決まっているものなので、サービスの想定する負荷に耐えられるか?
平常時、繁忙期、などの想定される負荷をさばけるかということを常に主眼に置きましょう。

また、レンタルサーバーとかだと、IOPS制限といって、一定期間に規定値を超えるIOがあった場合に制限を加えることがあるため、
そこも考えにおいて、負荷をさばけるか? といったことを考えましょう。

interface

ネットワーク帯域の使用量 の項目です。
単位は KB/秒
送信 tx
受診 rx

で表されています。

基本的に帯域には限界があります(帯域幅や使用量など)があるので、現在のサーバーではそれがどうなっているかを確認しましょう。
また、クラウドの場合だと従量課金制のため、帯域を使用するとガンガン料金が上がる可能性があるので、
料金の指標としても活用できると思います。

帯域とは

調べている最中にそもそも帯域とはんだっけ？となったので、そこらへんも書いておきます。

簡単に言うと 一度に送れるデータの量 みたいなものです。
昔の回線だと、この量が少なかったため、動画などの常にデータを送受信するタイプのものは一度に十分な量のデータを送ることができず、結果として速度がでないといったことが起こっていました。

帯域の単位

アナログ通信の場合だとHz
デジタル通信だとbps

おそらく現在の監視項目はbpsになると思います。
これは、単位時間(今回場合だと秒)にあたり最大どれだけの容量を送れるか? という計算式でこれが多ければ多いほど、
遅れるデータ量も増えるということになります。

帯域と通信速度

注意点として、 帯域と通信速度は全くの別物です。

帯域はどれだけ一度に運べるかという容量に相当します。
そして、これを実際に運べる速度(転送速度)が通信速度になります。

なので、厳密には別物ですが、帯域が広いと結果的に通信速度が早くなったようなケースはあります。
例えば大容量のファイルをダウンロードする場合、如何に通信速度が速かろうと帯域(一度に送るデータ容量)が小さいと時間がかかたりします。
逆に、帯域(一度に送れるデータ)が広く、通信速度の普通の場合、一度に処理できる量が増えているため結果的にダウンロードする時間が減ったということになったりします。

cpu

CPU使用率 を表します。

CPUがどこで使われているか、そもそもアイドル状態かという部分を見てそこから、原因を探る方がいいと思います。
cpuのグラフは以下の四つを主に見ることがいいそうです。

1. cpu.user (カーネル以外、つまりユーザーが使用した割合)
2. cpu.iowait (I/O待ちでアイドルになった時間の割合)
3. cpu.idle (待機状態だった時間の割合)
4. cpu.system (カーネルが私用した時間の割合)

平常時にどのくらいの割合にどのくらいで障害時はどうなっているのか?
といった推移、

load average は高い時に、cpu.iowaitの負荷はどうなっているのか?
cpu.userが高くなっていないか

といった形でcpuの処理の流れで考えていくことがよさそうです。

memory

メモリの使用率や空き を確認するための指標です。
一番の指標としてまず、 swapしていないか? ということですね。

あとはシンプル現在使用しているメモリ率をみて、そのプロセスは何なのか?
キャッシュに乗っているものはないか?

といった形で内訳から徐々に

• どのプロセスからの処理に負荷がかかっているのか?
• ちゃんとキャッシュが解放されているのか?

などを考えながら見るのがよさそうです。

最後に

重要なことは、どうゆう役割のサーバーかを頭に入れたうえでメトリックを見ることが重要だと思います。
ログやファイルアップロードがないサーバーでディスクサイズを確認しても不毛ですし、
ネットワーク通信が頻繁に発生しないDBにinterfaceの値を確認するのは意味がないと思います。

どういった役割から、見るべきメトリックを監視して、そこから平常時と異常時の差分を見ることが一番重要だと思います。

参考

https://blog.a-know.me/entry/2017/02/02/215641
https://www.storage-channel.jp/blog/iops.html
https://qiita.com/toshihirock/items/e2d187e91ee5446c7a69