O'Reilly Japan - 入門 監視
入門 監視 ―モダンなモニタリングのためのデザインパターン | Mike Julian, 松浦 隼人 |本 | 通販 | Amazon
読書感想文です。
メモ
監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。
- ツールに依存しても、監視の仕組みはよくなりません。
- 監視は全員がやるべき仕事であり、チームや部署内での役割ではありません。
- 素晴らしい監視とは、チェックボックスに「これは監視してます」とチェックを入れるだけで済むものではありません。
- 監視するだけでは壊れたものは直せません。
- 自動化が足りていないということは、何か重要なことを見落としている可能性を知るよい方法です。
「監視」5つの要素
- データ収集
- データストレージ
- 可視化
- 分析とレポート
- アラート
a = 稼働時間 / 総運用時間（総運用時間は、そのコンポーネントの稼働時間とダウンタイムの和）- アプリケーションを丸々 1 か月（43,800 分）運用したうち、93 分間のダウンタイムがあった（つまり稼働時間は 43,800 － 93 = 43,707）とすると、可用性は 99.7%
（43,707/43,800） - 可用性 100% は現実的ではない。ナインナイン（可用性 99.9999999%）の可用性とは、つまり年間ダウンタイムはおよそ 31秒
デザインパターン
- 組み合わせ可能な監視の仕組みは、モノリシックな仕組みよりも効果的です。
- ユーザ視点優先での監視によって、より効果的な可視化ができます。
- 監視の仕組みは、可能な限り自分で作るのではなく買うことを選びましょう。
- 常に改善し続けましょう。
よいアラートの仕組みを作る
- アラートにメールを使うのをやめよう。
- 手順書を書こう。
- 固定の閾値を決めることだけが方法ではない。
- アラートを削除し、チューニングしよう。
- メンテナンス期間を使おう。
- まずは自動復旧を試そう。
アラートの種類
- すぐに応答かアクションが必要なアラート
- これらは SMS、PagerDuty などのページャに送りましょう。これらは私たちの定義でいう本来のアラートです。
- 注意が必要だがすぐにアクションは必要ないアラート
- これらは社内のチャットルームに送るのが私の好みです。後日レビューするため、この種のアラートを受信して保存しておく小さな Web アプリケーションを作って成功したチームもありました。これらをメールで送るのもありですが、受信箱をいっぱいにしがちなので注意して下さい。他の方法があるならそちらの方がよいでしょう。
- 履歴や診断のために保存しておくアラート
- これらの情報はログファイルに送りましょう
手順書: これは何のサービスで、何をするものか
- 誰が責任者か。
- どんな依存性を持っているか。
- インフラの構成はどのようなものか。
- どんなメトリクスやログを送っていて、それらはどういう意味なのか。
- どんなアラートが設定されていて、その理由は何なのか
- 初心に戻りましょう。すべてのアラートは誰かがアクションする必要がある状態でしょうか。
- 1 か月間のアラートの履歴を見てみましょう。どんなアラートがあるでしょうか。どんなアクションを取ったでしょうか。各アラートの影響はどうだったでしょうか。削除してしまえるアラートはないでしょうか。閾値を変更できるでしょうか。監視の内容をより正確にするようにデザインし直せないでしょうか。
- アラートを完全に削除するために、どんな自動化の仕組みが作れるでしょうか。
インシデント
- インシデントの認識（監視が問題を認識）
- インシデントの記録（インシデントに対して監視の仕組みが自動でチケットを作成）
- インシデントの診断、分類、解決、クローズ（オンコール担当がトラブルシュートし、問題を修正し、チケットにコメントや情報を添えて解決済みとする）
- 必要に応じて問題発生中にコミュニケーションを取る
- インシデント解決後、回復力を高めるための改善策を考える
KPI
- ビジネス KPI は、非常に重要なメトリクスであり、アプリケーションやインフラの調子やパフォーマンスを示す先行指標です。
- 会社の中でこれらのメトリクスを特定し、追跡する方法を学びました。
- ビジネスメトリクスを技術指標に結び付ける方法を学びました。
アプリケーション監視
- メトリクスとログでアプリケーションを計測するのは、アプリケーションのパフォーマンスを把握し、トラブルシューティングする能力を高めるためにできる最も重要なことです。
- アプリケーションやインフラのリリースやパフォーマンスに関係することを追跡しましょう。
- 役立つアーキテクチャが限られているとは言え、/health エンドポイントパターンはなかなかよい方法です。
- 相当大規模にデプロイしているのでない限り、サーバレスあるいはマイクロサービスの監視は、他のアプリケーションと大きく違いはありません。分散トレーシングを始めるには、時間と労力をかけなければならないでしょう。
サーバー監視
- 標準的な OS メトリクスはアラートを送るのには適さないことがある理由と、それらの効果的な使い方。
- Web サーバ、データベースサーバ、ロードバランサなどといった、よく使うサービスの監視方法。
- サーバの観点からのロギング。
その他
- ネットワーク監視
- セキュリティ監視
参考
書評「入門 監視」雰囲気で監視をやっているすべての人にオススメ | DevelopersIO
「入門 監視」を読んだので要約する - Qiita
「入門 監視」読書会レポート vol.1 - リゾームのテックブログ
「入門 監視」読書会レポート vol.2 - リゾームのテックブログ
「入門 監視」読書会レポート vol.3 - リゾームのテックブログ
「入門 監視」読書会レポート vol.4 - リゾームのテックブログ
「入門 監視」読書会レポート vol.5 - リゾームのテックブログ
「入門 監視」読書会レポート vol.6 - リゾームのテックブログ
「入門 監視」読書会レポート vol.7 - リゾームのテックブログ
「入門 監視」読書会レポート vol.8 - リゾームのテックブログ
「入門 監視」読書会レポート vol.9 - リゾームのテックブログ
以上です～