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

• 監視とは複雑な問題をひとくくりにしたもの
  • コードレベルでのアプリケーション監視をしたいならAPM
  • クラウドインフラを監視するなら、サーバー監視ソリューション
  • スパニングツリーなら、ネットワーク用のツールが必要

単一の問題ではなく、何か一つのツールを入れれば解決というわけにもいかない

チェックボックス監視

• 監視項目を設定して、それをチェックしたらOKということはない

• システムの動作を完全に理解してないと、そのシステムで重要な監視項目を過不足なく列挙することは難しい

• アラートでOSメトリクスはあまり意味がない

  • CPU使用率が高いのは、サーバーが処理を果たしているということ。
  • 使用率が高いことでアラートをだされると深夜にたたき起こされる羽目になるが、その価値はない
  • メトリクス分析をして原因究明すれば十分であり、アラートは出さないべき

• メトリクスは高頻度で取得する

  • 複雑なシステムでは、数分や数秒でたくさんのことが起きる
  • 5分のメトリクスなどは意味がない
  • せめて60秒に一回のメトリクス取得に努める

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

組み合わせ監視

• 監視サービスのコンポーネント
  • データ収集
    • プッシュ
    • プル
      • ログ
        • 非構造化ログ
          • grepやtailで見やすい
        • 構造化ログ
          • 基本jsonで
          • key, valueが明確で見やすい
  • データストレージ
    • データの間引き(roll up)や有効期限切れ(age out)の設定をすることが大事
    • 圧縮したりすることで、容量を削減する
  • 可視化
    • ダッシュボードは一つのサービスや一つのプロダクトのために作成され、プロダクトを熟知している人の手によって作成されるべき
  • 分析とレポート
    • SLA
      • SLAはほとんどの場合願望や嘘
      • AWS EC2のSLAは1つのリージョンに対して、99.95%の可用性しか提供していない
  • アラート
    • アラートを出すことを監視の目的にしてはいけない
    • 収集しているメトリクスをアラートと1対1で対応させる必要はない

ユーザー視点での監視

• まず初めにユーザー視点から監視するとよい
  • ユーザーが気にするのはアプリケーションが動いているかどうか
  • 最も効果的に監視をできる方法はhttpのレスポンスコード(5xx)とレイテンシ
  • データベースサーバのCPU使用率が上昇しても、ユーザーが影響を受けないのであればそれは問題とは言えない

作るのではなく買う

• saasを導入する
• 作ってメンテしてをやると、それを行うエンジニアが生み出すべきだった機能開発などの機会損失などにもつながる
• それすらもsaasで提供しているサービスには届かない(saasを開発しているのは監視のプロ)

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

どうしたらアラートをよくできるか

アラートは二つ存在する

• 誰かをたたき起こすためのアラート

• 参考情報(FYI)としてのアラート

• 手順書を書こう

  • アラートが来た時に、すばやく自分の進むべき方向を示す。環境が複雑になってくると、チームの誰もが各システムを知ってるわけではなくなり、手順書が知識を広める良い方法になります
    • これは何のサービスで何をするものか
    • 誰が責任者か
    • どんな依存性をもっているか
    • どんなメトリクスやログを送っていて、それらはどういう意味なのか
    • どんなアラートが設定されていて、その理由は何なのか

• false alarmをチューニングする

  • システム構成に応じて、アラートをチューニングしていき、アラートが鳴りっぱなしになることを防ぐ

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

• リアルユーザー監視(real user monitoring: RUM)
  • google analyticsはrum
    • analytics.jsを用いてデータを計測する
• シンセティック監視(synthetic monitoring)
  • WebpageTest.org

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

• 内部アプリケーション監視

  • StatsDをライブラリとして埋め込む
    • CloudWatchなどで連携することもできる

• ビルドとリリースのパイプライン監視

• heathエンドポイントパターン

  • canary endpoint, status endpointともいう
  • エンドポイントの疎通確認にプラスして各データソースへのアクセスの疎通確認も行うことができる
    • sqlで一つのデータをテーブルからselect
    • redisからデータを取得できるかtest
  • エンドポイントが正常でないなら、503(service unavailable)を使う
  • デメリット
    • シンプルなメトリクスベースよりもエンジニアリング作業が多く発生する
  • ただ汎用性があってよい

• アプリケーションロギング

  • 何のログをとるべきか
  • 何かがおかしくなったときに、最初にする質問なにかを理解して初めて何のログをとるべきかがわかる
  • ディスクに書くべきかネットワークで送るべきか
    • ログはディスク上のファイルに書き込むのがよい
      • ネットワークが逆にボトルネックになったら本末転倒
  • サーバレス
    • StatDのような埋め込み系監視を追加する
  • マイクロサービス
    • 分散トレーシング

サーバー監視

CPU監視

• /proc/statに由来するもの
  • topコマンドで確認できる

メモリ

• /proc/meminfo

  • free -mで確認
  • buffer
    • ディスクの中で最近アクセスされたメタデータを保存
      • ディレクトリやパーミッションや中身
  • cached
    • 最近アクセスされたコンテンツ

• OOMKillerの呼び出しを監視する

  • メモリ使用が増えてきたときに、メモリを増やすためにプロセスを停止させる

• ネットワーク

  • ifconfig, ip

• ディスク

  • iostat, sysstat

• ロードアベレージ

  • CPUに処理してもらうのを待っているプロセスがいくつあるのかを平均で出す
  • /proc/loadavg = uptime

• SNMP

  • SNMPをサーバー監視に使うのはやめる
    • エージェント拡張が必要
    • セキュアではないプロトコルを動かす必要がある

• ウェブサーバー

  • コネクション数
    • keep-aliveによってリクエスト数=コネクション数ではなくなった
  • リクエスト数

• データベースサーバー

  • コネクション数
    • ここ見るのが一番わかりやすい
  • 秒間クエリ数(qps)
  • スロークエリ
  • レプリケーション遅延
  • IOPS
    • これは重要
    • ここを見ることで、タイムアウト設定などを加味できる
      ロードバランサー
  • フロントとバック両方の監視が必要
  • /healthエンドポイントパターンをロードバランサーのヘルスチェックに応用できる
    メッセージキュー
  • キューの長さ
    • 通常よりもメッセージが増えて込み合っているときに注意
  • 消費率
    • キューから取り出されて処理されたメッセージの比率

キャッシュ
- キャッシュから追い出されたアイテム数(evicted items)
- ヒット・ミス比率
DNS
NTP
DHCP
SMTP

スケジュールジョブの監視

- 失敗に気づきにくい
- デッドマン装置
    - バッチが起動していないことはバッチ内のログでは取得できない

ロギング

• 収集
  • syslogを使うのがよい
  • ただ、ツールで推奨されている方法で一貫性があるのであればそれでもよい
• 保存
  • どこかの収集サーバーに送りましょう
  • ただし、syslogサーバーに送ってはだめ
• 分析
  • splunkなどで統計分析もできる

セキュリティ監視

• auditログ
  • ユーザーの操作ログを通知することができる