目的
最近、業務で担当しているアプリの品質維持で悩んでいて、バグアラート以外の監視も検討している。とは言っても、自分が監視方法として思いつくのはfirebaseのツールを導入するやり方ばかりで、全体像を理解しないでツール導入しても効果がないのではと悩んでいた。
で、元々評判が良かった上に社内の人もおすすめしていたので手にとってみた。
浅く広く学ぶはじめの1冊目として、監視を専門にしていない自分には丁度よいボリュームで、アプリケーション監視に関わる部分を中心に流し読みした。
全体感はわかったので、実際に手を動かすときに細部を見ながら関連情報も漁ってみようと思う。
概要
監視手法と監視対象別に、概要と例が紹介されている本。
特定のツールに特化した内容ではない。
もしツールの選択肢がたくさんあるならこの本で得られた知識をもとに監視フローを検討し、そこにフィットするものを選定するという流れで仕組みを組んでいけそう
印象に残ったところ
- サービスの可用性は依存先以上に上がることはない
- 監視を整備するときに、まず着手すべきはユーザが触れる部分
- 監視のためのデータを集める方法はpull型とpush型に分類される。push型は必要なデータさえ送れば細かい設定を意識しなくて良いため、スケールしやすい
- 管理対象→フロントエンド、バックエンド、インフラ、KPI
- 万能で完全な一つのツールではなく、単一責務の複数のツールの組み合わせで監視用データを測定するのがトレンド
- 監視ツールを自分たちで作る選択肢も勿論ある。但し多くの場合はSaasのツールで十分
- 監視によってアラートが出た時の復帰方法も検討する
- 手順書には、それが必要になった時に人間がどう判断すべきかを記載する
- 人間の判断が不要な手順は自動で復帰する方法を検討すべき
- 増えたデータをどうする?
- 一定期間で削除
- 特定時間での平均値を送る
- データをどう活用する?
- フロントエンドの監視
- ロード時間をベースに考える
- 実際のユーザのデータを取得するか、CIなどで実行して測定するか?
- 自動データ取得ツールは、機能のコンテキストを意識して処理するわけではない。便利だが取得結果の活用方法は注意する
- ログでデータを取得する場合、そのログで必要データが全て取得できるとは限らない
- 必要データが含まれていない場合もある
- ログレベルを設定しても、そのレベルを設定した開発段階では先の有用性まで判断できないので、解決しづらい