読者です 読者をやめる 読者になる 読者になる

Webエンジニアが知っておきたいインフラの基本 #5 システム監視の基本

インフラ 読書メモ

システム監視とはなにか?

  • 正常な状態を定義
  • 正常な状態で無くなった時の対処方法を、監視項目毎に定義
  • 正常な状態であることを監視する
  • 正常な状態で無くなった時に復旧する。状況に応じて再発防止策を講じる

運用とは育てること

多くは望まず、適時育てていく

システム監視においては、確認したい項目を直接確認する

LAが高くなると応答時間が遅くなるからと言って、LAを監視することはよくない

相関があったとしても因果関係が成立しないときがあり、運用がややこしくなる

対応方法

  • 連絡フローは整備しておく
    • 誰にどう連絡し、その人がどのような権限をもっているのか?
    • 連絡を受けたあとのボールのまわし方も決めておく
      • ボールが回ってきたら、チャットで一声かけてから作業を開始するなど
      • アラートに気づいた場合も同様
  • 問題の切り分けはできるに越したことは無いが、復旧優先ならば、まずは復旧から
  • 対応方法を決めるときは状況に応じて場合分けをしていくのが良い
    • なんともいえない場合にやるべきかどうか悩む
    • 応答時間が微妙に遅いとかなら、何秒以上かかるならどうするか? とか決める

復旧方法

  • 重要なのは、方針定義・確認・復旧を繰り返して育てていくこと!

代表的な定番の監視項目

外形監視

  • HTTP(S)レスポンスコード、内容、応答時間、サイズ
  • POP、SMTPFTP等の死活、疎通、メール送受信やファイルPUT/GET
  • HTTPシナリオ

内部監視

  • CPU使用率
  • LA
  • ディスク使用量
  • ディスクI/O使用量
  • ディスクのレイテンシ
デバイスに対してデータ転送などを要求してから、その結果が返送されるまでの遅延時間のこと。

それぞれのしきい値の決め方は最初は根拠がなくてもOK

運用していく中でユーザへの影響がなければ緩和していく 逆に、ユーザへの影響があったのに、検知出来なければきつくしていく

監視事態が負荷を生まないように注意する

障害対応の流れ

  • 発報
  • 事象を確認
  • 一次対応
  • 発報事象と他の項目を確認
  • 事後作業
  • 収束

一次対応

  • 当たり前のことをきちんと冷静にやること
  • 操作ログを残す → scriptコマンド
  • promptに日時を出しておくと、あとで便利

状況確認コマンド

  • w : 稼働時間、ログインユーザ数、LAを確認
  • ss -lnp : ネットワーク接続数、接続元、実行プロセス、PIDを確認(実行プロセス、PIDはrootユーザのみ)
  • ps aufx : 実行中プロセスの確認
  • df -h : ディスク使用量の確認
  • top -b -d 1 -n 1 : CPU利用率、メモリ利用量、CPU利用率が高いプロセスの確認
  • top -b -d 1 -n 1 -a : メモリ利用量が高いプロセスの確認
  • dstat -taf 1 10 : CPU利用率、ネットワーク利用量、ディスクI/O量、ページング量の確認
  • mysqladmin processlist --verbose : 接続先IP・ポート、接続先DB、ステータス、SQLの確認

ログ集約は、fluentdが流行ってるけど、syslogでもできるよ!

参考

障害対応中の心構え

  • 落ち着いて
  • 冷静に
  • 大抵は事前に決めたとおりにすれば大丈夫。カンに頼らず事実とデータを見る
  • 自説にこだわらない。見切り・諦めを早くする。思い/期待通りでなくてもがっかりするのはあとで
  • 自分が知らないこと・知らない挙動があることを認識する
  • ググって適当にコピペで満足しない。でも使えそうなら使う
  • 水分、糖分、油分を摂る。深呼吸する
  • 意識的に一歩引く

普段からロールプレイする

何が適切か判断できないうちは、判断できる人に見てもらう

発報事象と他の項目を確認

  • 発報した事象が解決していることを確認
  • 他の監視項目に問題がないか全体を確認
    • 監視ツールのダッシュボード等を使って俯瞰できるように

事後作業

  • 一次対応、一時報告は迅速に。二次対応(根本対応)は翌営業日以降に
    • 体力は有限
  • 一次対応、一時報告はなるたけ少なく、小さくすることで迅速さを上げる
    • 関係各位の心配をなるだけ早い段階で取り除く