はじめに
入門監視 を読みました。
大きく２部構成になっていて、監視におけるアンチパターン・デザインパターンの解説や、統計の基本的な説明、ビジネスにおける監視〜ネットワーク,セキュリティの監視など幅広い知識が書いてあるとても面白い本でした。 特に前半のアンチパターン・デザインパターンは、参考にしやすいものがまとめられていたので、読んで考えた内容を忘備録として書いていきます。あくまで個人の感想がメインなので、書籍の情報が気になる人はまず、書籍を読んでください。
監視のアンチパターン
ツール依存
ツールは銀の弾丸ではないということ。「監視」とは複雑な問題をひとくくりにしたものなので、一つのツールを使えば全ての問題が解決できるわけではない。ここを勘違いしてしまうと、大きいモニターにメトリクスを表示しただけで満足した気になってしまう、目的と手段が逆転してしまうことになってしまうのかもしれない。様々な問題を監視するので、利用するツールも問題の性質やメリデメを評価して、選定してあげる必要がある。
役割としての監視
プロダクトの監視チームを作ってしまうケース。プロダクトの理解が不足しているチームがそのプロダクトの監視するのは無理。ドメインの理解なしに開発ができないのと同じことだと思う。チーム全員が監視に責任を持つことが重要。
チェックボックス監視
偉い人のご機嫌取りのために機械的にただメトリクスをチェックすればよい訳ではない。システムが正常に動いているとはどういう意味かを改めて考えて数値化するとよいのではないか。
監視を支えにする
何か問題が起きたら監視しておしまい。根本的な解決になっていない。
手動設定
設定に時間がかかるので自動にすればストレスが減る。手動設定では運用のストレスが大きくなり、いつか形骸化してしまう。
監視のデザインパターン
組み合わせ可能な監視
アンチパターン「ツール依存」の対策になる。 複数のツールを組み合わせて監視すれば、問題一つ一つに対して最適な対策をうつことができる。ツールの交換容易性が向上するので、様々なツールを試験的に導入することもできそう。マイクロサービスの考え方に似てる。
ユーザ視点での監視
メモリ使用率やリクエスト数など細かい指標の監視に注目しがちだが、監視の最初のステップでは「ユーザがシステムを利用できる」かどうかについてを考慮することが重要。監視によって本来やりたかったことに対して、的はずれな監視をすることを防ぐ。
作るのではなく買う
監視の仕組みが成熟していないなら、まずはSaaSツールを導入して監視の基礎知識をチームで習得する。さらにSaaSを利用することで、余計な運用や開発コストが減り、プロダクトの開発に集中することができる。製品を利用した監視が要件に合わなくなってきて初めてツールの構築を考える。
継続的改善
ツールを導入して終わりじゃない。そもそも世に出ているツールは、要件を満たすために試行錯誤を繰り返したバックグラウンドがある。 ビジネス要件やシステム要件によってプロダクトが進化していくのに合わせて、プロダクトの監視の仕組みもよりよいものを目指して改善していくべき。
おわりに
後半のサーバ、ネットワーク監視の話は、コマンドの実例も交えながらになっていたので、もう一度必要になったら読み返したいと思います。
