運用監視まわりについて書いてみる
About
うまくまとまらなかったので放り投げることにした。
障害の検知
障害の種類
- サービス利用不可障害
- サイトにアクセスできない
- 表示されない
- 503とかってページが出る
- パフォーマンス障害
- 遅い
- 重い
- バッチ処理が終わらないなど
- アプリケーション障害
- 特定の機能が利用できない
各種監視系サービスの守備範囲
外形監視
- サービスの疎通状態を監視します
- 基本的にはWebベースでの監視になります
- 一般的には監視用のエンドポイントを作ります
- 外形監視にも深さがあります
- とりあえずアクセスできればいいというレベル
- 実際に利用できる監視(例えば商品一覧サービスに対して想定するデータが帰ってくるというレベル)
- 外形監視を手厚くすればするほど、サービスに負荷はかかります。まずは気づくということが大切なので、浅い監視でいいかと思います。
- 外形監視での疎通確認方法
リソース監視
- DBやサーバなどのワークロードを監視する
- サービスのUtilization
- リソース監視は障害発生時の調査や障害発生の予防に使うイメージ
- disk使用量を予測検知する
- CPUリソースが不足気味なので強くするなど
ログ監視
- アプリケーションやミドルウェアが吐くエラーについて、特定のパターンを検知してアラートを上げる仕組みです
- 作っているアプリケーションのログレベルをプロジェクトごとに合意し、このレベルであればアラートを上げて欲しい(何らかの対応が必要)という合意をしておくと良いです。
- 特定のログが一定時間内に10件出た場合にアラートを出すなども作りによっては可能です
アプリケーションパフォーマンス監視
各種サービスの守備領域について
気が向いたら書く
障害発生後の対応フローについて
- 担当を決め、その担当が対応できない場合のエスカレーションフローを決めておくのが基本的に良いです
- pagerdutyなどを使ってアラートのフローを整理しておくのがおすすめです
- 通知先についてはアラートの緊急度に応じてどこに投げるかを決めておきましょう