tjinjin's blog

インフラ要素多めの個人メモ

運用監視まわりについて書いてみる

About

うまくまとまらなかったので放り投げることにした。

障害の検知

障害の種類

  • サービス利用不可障害
    • サイトにアクセスできない
    • 表示されない
    • 503とかってページが出る
  • パフォーマンス障害
  • アプリケーション障害
    • 特定の機能が利用できない

各種監視系サービスの守備範囲

外形監視

  • サービスの疎通状態を監視します
  • 基本的にはWebベースでの監視になります
  • 一般的には監視用のエンドポイントを作ります
  • 外形監視にも深さがあります
    • とりあえずアクセスできればいいというレベル
    • 実際に利用できる監視(例えば商品一覧サービスに対して想定するデータが帰ってくるというレベル)
  • 外形監視を手厚くすればするほど、サービスに負荷はかかります。まずは気づくということが大切なので、浅い監視でいいかと思います。
  • 外形監視での疎通確認方法

リソース監視

  • DBやサーバなどのワークロードを監視する
  • サービスのUtilization
  • リソース監視は障害発生時の調査や障害発生の予防に使うイメージ
    • disk使用量を予測検知する
    • CPUリソースが不足気味なので強くするなど

ログ監視

  • アプリケーションやミドルウェアが吐くエラーについて、特定のパターンを検知してアラートを上げる仕組みです
  • 作っているアプリケーションのログレベルをプロジェクトごとに合意し、このレベルであればアラートを上げて欲しい(何らかの対応が必要)という合意をしておくと良いです。
  • 特定のログが一定時間内に10件出た場合にアラートを出すなども作りによっては可能です

アプリケーションパフォーマンス監視

  • 通称APM
  • 特定のリクエストに対して、どこがパフォーマンス悪化の原因になっているかを突き止めることができます

各種サービスの守備領域について

気が向いたら書く

障害発生後の対応フローについて

  • 担当を決め、その担当が対応できない場合のエスカレーションフローを決めておくのが基本的に良いです
  • pagerdutyなどを使ってアラートのフローを整理しておくのがおすすめです
  • 通知先についてはアラートの緊急度に応じてどこに投げるかを決めておきましょう