「入門監視」まとめ

「入門監視」を読了したので内容をざっくりまとめてみました。

感想

• アプリケーション監視を考える際にユーザからみて「動いているか」という視点から考えていくことは重要そう
• 読んでみて結構アンチパターン(アラート疲れの話やオンコールの話など)を見たことあるなと感じた
• 可視化については詳細には書かれていないが重要な気がするので勉強したい
• フロントエンドの章を読んで、ユーザからどう見えるのか(ページの表示速度など)は重要そう

---

第一部 監視の原則

第一章 監視のアンチパターン

• まず、何を監視したいのかから考える。
  • ツールから考えてもよい仕組みは出来上がらない。
  • 監視は複雑な問題を一括りにしたものなので複数のツールを組み合わせる。
• チーム全員で監視を行う。
  • 監視には様々な分野での専門性(例えばネットワークや構成管理など)が必要。
  • 監視専門のメンバーに全ての責任を押し付けない。
• アプリケーションが「動いている」を定義して「動いている」かどうかを監視する。
  • CPUの使用率が高くてもアプリケーションが動いていれば問題はないはず。
• メトリクスをもっと高頻度で取得する。
  • 例えば５分間隔でメトリクスを取得した場合、３０秒ごとにレイテンシが跳ね上がった場合に見逃してしまう。
• 監視設定は自動化する。ノードを増やすなどのスケーリングをした際に対応できなくなる。

第二章 監視のデザインパターン

専門化されたツールを複数使い、それらを疎に結合させて監視「プラットフォーム」を作る。
構成要素は以下の５つ。(すべてを一つのツールで賄うのはアンチパターン)

• データ収集 (pull型とpush型があり、多くはpush型の方がスケーラブル)
  • pull型: 監視サービスがリモートノード対して、ノード情報を送るように要求
  • push型: クライアントが監視サービスに対して、ノード情報を送りつけてくる
• データストレージ
  • ログの保存はディスク容量とデータ読み出し時間とのトレードオフ
  • 必要に応じて一定期間で「間引き」(roll up)するなどを行う
• 可視化
  • 以下の本がおすすめらしい。
    • Information Dashboard Design
    • The Visual Display of Quantitative Information
• 分析とレポート
• アラート

進め方

ユーザの視点から監視を追加していく。第１章でも述べた「動いている」かを監視する。
大企業でない限り、外部サービスを使ったほうがコストを抑えられ、性能もSaasの方が上になります。
仕様変更や組織の成熟に合わせて監視の仕組みも改善していく必要がある。

第三章 アラート、オンコール、インシデント管理

• アラートの改善しよう
  • アラートをメールで送信するのをやめる
    • 量が多いとアラート疲れが起きるのでレベルによって使い分ける
      • SMS
      • チャット
      • ログ
  • 手順書を作成する
  • 固定の閾値で決めるのをやめる
    • グラフの傾きを使うなど
  • 必要なアラート以外は削除する
  • メンテナンス時はアラートを止める
  • 自動復旧できるものは自動化する
• オンコール (障害時に呼び出し対応を受ける人)の改善
  • 不要なアラートを減らしシステムの回復性や安定性を改善していく
  • オンコール担当者はローテンション (担当者一人は大変)
  • 重大なインシデントについてはきちんと振り返りを行う

第四章 統計入門

• 平均 (移動平均など、スパイクを平滑化する効果)
• 中央値 (大きな偏りがある場合に効果的)
• 周期性 (データがパターンを繰り返す)
• 分位数 (パーセンタイルがよく使われる)
• 標準偏差 (平均からどの程度離れているか、正規分布じゃないとダメ)

第２部 監視戦略

第五章 ビジネスを監視する

• ビジネスKPI
  • 月次経常収益
  • 顧客当たりの収益
  • 課金顧客の数
  • ネットプロモータスコア (ユーザ満足度)
  • 顧客生涯価値
  • 顧客当たりのコスト
  • 顧客獲得単価
  • 顧客の解約数
  • アクティブユーザ数
  • バーンレート
  • ランレート
  • TAM (Total addressable market)
  • 粗利
• ビジネスKPIはアプリケーションやインフラの調子を表す先行指標
  • 検索機能が遅いや壊れている場合に検索回数が減るなど
• KPIはアプリケーションをよく知っている人と話をすることで見えてくる

第六章 フロントエンド監視

• 遅いアプリケーションはビジネスに悪影響がある
  • 表示が遅いことで離脱・コンバージョンの低下が発生する
  • ページが表示されるのを4秒までに抑える
  • 静的アセットのサイズに影響される
• フロントエンド監視の２つのアプローチ
  • リアルユーザ監視 (real user monitoring)
    • GAとか
  • シンセティック監視 (synthetic monitoring)
    • WebpageTest.orgとか
• DOMの監視
  • メトリクス
    • Navigation Timing API
    • Speed Index
  • ロギング
• 監視の仕組みをCIへ組み込んでロードが許容時間に収まるようにする

第七章 アプリケーション監視

• アプリケーションのメトリクス
  • スロークエリ
  • 外部APIの接続時間
• アプリケーションロギング
  • 何のログをとるか以下から考える
    • 障害時に最初に何を見るか
    • トラブルシューティングや仕組みの説明時にあったら便利な情報
  • ログはディスクに書き込みを行い、定期的に外部に送信するようにする (都度送るとリソース問題になる)
• healthエンドポイントパターン
  • アプリケーションの状態を取得するエンドポイントを用意する
• ビルドとリリースのパイプラインのメトリクス
  • 「何が」「いつ」「誰が」デプロイしたかわかると不具合調査などに有用
• マイクロサービス
  • 分散トレーシング(distributed tracing)
    • リクエストにIDを付けてすべてのサービスを回る

第八章 サーバ監視

OSの標準的なメトリクス

CPU

• 使用率 メモリ
• OOMKiller (killed process をgrepするとよいかも？)
  • メモリが不足している場合にプロセスを強制的に kill する ネットワーク
• インターフェースに対する
  • オクテット数 (IN/OUT)
  • エラー数 (IN/OUT)
  • ドロップ数 (IN/OUT) ディスク
• iowait (CPUがディスク待ちした時間)
• await (ディスク処理のリクエスト発行時間)
• %util (ディスクの使用率) ロードアベレージ (CPU処理待ちのプロセス数)

サーバの役割による監視項目

Webサーバ

• 秒間リクエスト数 (request per second[req/sec])
• ステータスコード DBサーバ
• コネクション数
• 秒間クエリ数
• スロークエリ
• レプリケーションの遅延監視
• IPOS (ディスクIOの速度) ロードバランサ
• バックエンドサーバのhealthcheck メッセージキュー
• キューの長さ (queue length)
• 章比率 (consumption rate) キャッシュ
• キャッシュから追い出されたアイテム数 (evicted items)
  • 頻繁に発生する場合は、キャッシュ領域足りてないかも
• ヒット・ミス比率 (hit/miss ratio) スケジュールジョブ
• デッドマン装置 (dead man’s switch)
  • 一定時間内に処理が終わらない場合に通知などを行う仕組み

その他: DNS/NTP/DHCP/SMTP

ロギング

• 収集
  • ログ出力するものの設定を変更してログ出力をsyslogに送るようにする
  • syslogの設定を変更してディスク上のログファイルをsyslogへ取り込む
• 保存
  • ログサーバに送るまたはSaas監視ツールへ送る
• 分析
  • 以下を分析してみる
    • HTTPレスポンス
    • sudoの使用
    • SSHログイン
    • cronジョブの結果
    • MySQLやPostgreSQLのスロークエリ

第九章 ネットワーク監視

SNMPを利用して以下の監視を行う (辛いらしい)

• 帯域幅 (bps)
• スループット (実際のパフォーマンス/秒間ビット)
• レイテンシ (パケットのやり取りにかかる時間)
• エラー
• ジッタ (レイテンシの振れ幅など)

構成管理

• 設定変更の追跡

セキュリティ監視

• ユーザ、コマンド、ファイルシステムの監査
  • auditd
• ホスト型侵入検知システム (HIDS)
  • rkhunter
• ネットワーク侵入検知システム (NIDS)