ちゃんるいすのブログ

オタクエンジニアの雑記

俺的監視ベストプラクティス


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

監視俺的ベストプラクティス(VM編)

前提

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

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パーセンタイルでレスポンスタイムが5秒を超えてる。 レスポンスタイムの影響は大きいよ。 何が原因かは調べてください。

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

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

コメント例

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

3. プロセス死活監視

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

例えば API サーバーの1台のプロセスが死んだだけでサービスにクリティカルな影響を与えるとは限らないため、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 の計測間隔は最低1分なのでここを許容できるかどうか

コメント例

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

5.2 スロークエリ

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

コメント例

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

5.3 コネクション数の割合

warning ≥ 70 critical ≥ 80

コメント例

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