Webエンジニアが知っておきたいインフラの基本 ~インフラの設計から構成、監視、チューニングまで~
- 作者: 馬場俊彰
- 出版社/メーカー: マイナビ
- 発売日: 2014/12/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (5件) を見る
システム監視とはなにか?
- 正常な状態を定義
- 正常な状態で無くなった時の対処方法を、監視項目毎に定義
- 正常な状態であることを監視する
- 正常な状態で無くなった時に復旧する。状況に応じて再発防止策を講じる
運用とは育てること
多くは望まず、適時育てていく
システム監視においては、確認したい項目を直接確認する
LAが高くなると応答時間が遅くなるからと言って、LAを監視することはよくない
相関があったとしても因果関係が成立しないときがあり、運用がややこしくなる
対応方法
- 連絡フローは整備しておく
- 誰にどう連絡し、その人がどのような権限をもっているのか?
- 連絡を受けたあとのボールのまわし方も決めておく
- ボールが回ってきたら、チャットで一声かけてから作業を開始するなど
- アラートに気づいた場合も同様
- 問題の切り分けはできるに越したことは無いが、復旧優先ならば、まずは復旧から
- 対応方法を決めるときは状況に応じて場合分けをしていくのが良い
- なんともいえない場合にやるべきかどうか悩む
- 応答時間が微妙に遅いとかなら、何秒以上かかるならどうするか? とか決める
復旧方法
- 重要なのは、方針定義・確認・復旧を繰り返して育てていくこと!
代表的な定番の監視項目
外形監視
内部監視
- CPU使用率
- LA
- ディスク使用量
- ディスクI/O使用量
- ディスクのレイテンシ
デバイスに対してデータ転送などを要求してから、その結果が返送されるまでの遅延時間のこと。
- ネットワークインターフェイス毎のトラフィック(IN/OUT)
- ローカルからのHTTP接続
- サービスに使うプロセスの監視(apache, mysqldなど)
- システム的に使うプロセスの監視(ntpd, snmpdなど)
それぞれのしきい値の決め方は最初は根拠がなくても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でもできるよ!
参考
- dstatの便利なオプションまとめ - Qiita
- Linux - topコマンドの使い方 - Qiita
- Fluentdが流行る理由がいま分かる、10の実践逆引きユースケース集 - Y-Ken Studio
障害対応中の心構え
- 落ち着いて
- 冷静に
- 大抵は事前に決めたとおりにすれば大丈夫。カンに頼らず事実とデータを見る
- 自説にこだわらない。見切り・諦めを早くする。思い/期待通りでなくてもがっかりするのはあとで
- 自分が知らないこと・知らない挙動があることを認識する
- ググって適当にコピペで満足しない。でも使えそうなら使う
- 水分、糖分、油分を摂る。深呼吸する
- 意識的に一歩引く
普段からロールプレイする
何が適切か判断できないうちは、判断できる人に見てもらう
発報事象と他の項目を確認
事後作業
- 一次対応、一時報告は迅速に。二次対応(根本対応)は翌営業日以降に
- 体力は有限
- 一次対応、一時報告はなるたけ少なく、小さくすることで迅速さを上げる
- 関係各位の心配をなるだけ早い段階で取り除く
