入門 監視 書評

入門　監視　書評

入門監視を読んだ。
お風呂に入りながら２−３hくらいで、読み終えることができた。
Webシステムの開発や、Webサービスの提供に関わるエンジニアであれば読んでおいて間違いなさそう。
読み終わってから早速チームのメンバーにお勧めした。

以下、個人的に刺さったフレーズ集。

１章　監視のアンチパターン

• いくつならツールが多すぎると言えるか

  • 例えば データベースを監視する3つのツールがそれぞれ別の情報を提供するなら、おそらく問題ありません

• 監視とは複雑な問題をひとくくりにしたもの

  • 他人に変化を共用するのは、統合の試みを台無しにする最悪の方法です

• アンチパターン２：役割としての監視

  • 監視とは役割ではなくスキルであり、チーム内の全員がある程度のレベルに至っておくべきです

• アラートに関しては、OSのメトリクスはあまり意味がない

  • CPUやメモリ使用率のような低レベルなメトリクスではなく、「なぜ動いているか」を基準にアラートを送ることが有益である

• アンチパターン４：監視を支えにする

  • 問題の修正を忘れてはいけません

• アンチパターン５：手動設定

  • 監視は自動化すべきです

２章　監視のデザインパターン

• 監視サービスのコンポーネント

  • データ収集
  • データストレージ
  • 可視化
  • 分析とレポート
  • アラート

• デザインパターン４：継続的改善

  • 明日は世界レベルになるであろう仕組みも、１年後にはそうでない可能性があります
  • 業界が進歩するに従って、２年あるいは３年で監視の仕組みを再構築しなおすことになるかもしれません

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

• 振り返り
  • 重大なサービス停止などのインシデントに対しては、きちんとした振り返り（postmortem）が重要です

５章　ビジネスを監視する

• 会社のビジネスKPIを見つける
  • アプリケーションが動いていることをどうやって知らせたらよいでしょうか？　何をチェックしていますか？　どう動いていたらよいのでしょうか？
  • アプリケーションのKPIは何ですか？　なぜそのKPIを使っているのですか？　そのKPIはどんなことを教えてくれますか？

７章　アプリケーション監視

• サーバレスまたはFunction-as-a-Service

  • StatsDを使えばよいのです

• マイクロサービスアーキテクチャを監視する

  • GoogleのDapper論文
  • Zipkin
  • 分散トレーシングの仕組みは 一意なリクエストIDを「タグ付け」し リクエストがどのサービスにアクセスしたか 各サービスでどのくらいの時間を過ごしたかが分かります