入門監視を読んで、社内のドキュメントに書いたものをブログにも書く。
今回のは VM を対象。

• 監視俺的ベストプラクティス（VM編）
  • 前提
  • warning と critical の使い分け
    • ❌ warning を @here で通知する
    • ❌メールで通知受ける
  • CPU 使用率と、ディスク容量について
    • ❌ Load Average をトリガーにする
    • ディスク容量の監視
  • 自動復旧について
  • アラートメッセージは大事
    • 何故これを監視して、どう影響を与えて、どうやって復旧するのか
  • 監視すべきメトリクス
    • 1. レスポンスタイム 95 パーセンタイルで 5秒超え
    • 2. ステータスコード 5xx が n分間に m%
    • 3. プロセス死活監視
    • 4. ディスク容量
    • 5. MySQL の監視

監視俺的ベストプラクティス（VM編）

前提

• 監視ツールは１つに絞らなくていい
• クリティカルなものはサービス影響が出るものだけ
• 障害時に参考になりそうなものはグラフ化する
• できるだけユーザーに近いところを監視する
• アラートには絶対メモをつける
  • 影響、解決方法

warning と critical の使い分け

❌ warning を @here で通知する

warning 見たって対応しないでしょ？
アラート部屋に通知だけして、メンションは無しが良さそう

❌メールで通知受ける

Slack で良いじゃん？

メールでのアラートをやめたほうがいい5つの理由 | PagerDuty by Digital Stacks

CPU 使用率と、ディスク容量について

❌ Load Average をトリガーにする

LA は CPU の使用率を見るものとしては正しいが負荷がどうとかで見るのは間違い。
実行中のプロセスが多ければ必然的に LA も高くなる。
参考：https://www.techscore.com/blog/2017/12/08/how_is_load_average_calculated/

ディスク容量の監視

80% ≥ warning にするとあとで良いやってなる。
じゃあ 95% ≥ critical はどうでしょう。あと 5% でその VM は障害になるかもしれない！

DB は例外で考えても良いかも
DELETE + ALTER TABLE で容量を確保する際に、ALTER でコピー分の容量も必要なため 80 ≥ critical ぐらいが良さそう
（スレーブで一時的に停止できるなら、停止してからボリュームの拡張でも良さそう）

自動復旧について

例えばプロセスが落ちたトリガーのフックに、プロセスの再起動を仕込んだりする。
人間の手が不要で勝手にプロセスが立ち上がってくれる。

MySQL が OOM で該当プロセスが死んだ場合は注意
OOM は SIGKILL を発行するが、もし MySQL の設定が sync_binlog = 0 や doublewrite ≠ 1 の場合はプロセスは起動できてもレプリが死んでたりするので MySQL に関しては自動復旧しないことをオススメする。

アラートメッセージは大事

何故これを監視して、どう影響を与えて、どうやって復旧するのか

をアラートメッセージに書いとくのが重要。アラートを見た人（サービスの担当者が見ても対応ができる）

監視すべきメトリクス

1. レスポンスタイム 95 パーセンタイルで 5秒超え

コメント例

95パーセンタイルでレスポンスタイムが５秒を超えてる。
レスポンスタイムの影響は大きいよ。
何が原因かは調べてください。

平均値でレスポンスタイムを計測するのは間違い

2. ステータスコード 5xx が n分間に m%

コメント例

Apache(Tomcat）が HTTP 5xx を 1分間で 2% 以上レスポンスを返してる。
DB や Memcached、負荷等、何かが要因になってる可能性有り。

3. プロセス死活監視

mysql とか Apache とかサービスに影響あるもの

例えば API サーバーの１台のプロセスが死んだだけでサービスにクリティカルな影響を与えるとは限らないため、API サーバーのうち n/m が死んだらクリティカルにするっていうのも良い。もしくは Critical ではなく Warning で出すとか。ちなみに、Mackerel だとできない。

4. ディスク容量

≠ DB
warning ≥ 90
critical ≥ 95

コメント例

空き容量が残り 5% しかない
対応しないと障害になる可能性有り
主な対応方法は不要なファイルを削除していく、コマンド例は下記を参照
まずはルートから辿っていく
du -sh /* | sort -hr | head -n 10
更にそのディレクトリを辿ってく
du -sh /directory/* | sort -hr | head -n 10

= DB
warning ≥ 70
critical ≥ 80

ただ EC2 にしろ、OpenStack（Cinder）にしろ容量の拡張ができるので DB も 95 クリティカルでも良いかもしれない。

コメント例

DB の空き容量が残り 20% しかない
DELETE + ALERT TABLE ではコピー分の容量も必要なため 80 >= critical にしてる
メンテ無しでやるなら
レコードを削除して ALTER TABLE t1 ENGINE=InnoDB;
メンテが挟めるなら
適当にテーブル作って、select insert -> rename -> drop
詳細 https://bit.ly/31WIZLg

監視俺的ベストプラクティス（VM編）

5. MySQL の監視

5.1 レプリ遅延

critical ≥ 3
※ Mackerel でも取れるけど、Mackerel の計測間隔は最低１分なのでここを許容できるかどうか

コメント例

レプリ遅延が３秒以上遅れてる。
この閾値は３分間の平均値が３回連続でトリガーされる値で、継続的にレプリ遅延が発生中。
データの取得に不整合がある可能性有り。
今すぐできることはあらず。
解消されない場合、メンテを入れることも視野に入れてください。

5.2 スロークエリ

warning ≥ 10 （critical にしないのは、レスポンスタイムで賄えるから）
※ Mackerel でも取れるけど、Mackerel の計測間隔は最低１分なのでここを許容できるかどうか

コメント例

スロークエリが直近１分間で１０クエリ以上有り。
Table Locks Waited も多い場合、ロックの競合が起きてる可能性有り。クエリの見直しや、他の要因も考えられる。

5.3 コネクション数の割合

warning ≥ 70
critical ≥ 80

コメント例

Max Connections の使用率が 70% / 80% を超えた。
これが高負荷時でなら問題はなく閾値の調整を。
通常時に起きている場合は Max Connections の引き上げを検討して。
もし、Max Connections に当たると新規コネクションが貼れなくなるので普通に障害になる。