入門 監視を読んだ
はじめに
システムを継続して動作させ、改善していく上で、重要なプロセスの1つが監視だと思います。このブログではその監視についてのチップがまとめられている「入門 監視」についてまとめます。なお、このブログはあくまで私自身の理解を自分の言葉でまとめるものなので、正しい知識を得たい方は、入門監視を購入されることを強くおすすめします。 また、入門監視は二部構成になっていますが、このブログでは第Ⅰ部 についてまとめます。
章構成
章の構成は以下のようになっています
第Ⅰ部 監視の原則
第Ⅱ部 監視戦略
- 5章 ビジネスを監視する
- 6章 フロントエンド監視
- 7章 アプリケーション監視
- 8章 サーバ監視
- 9章 ネットワーク監視
- 10章 セキュリティ監視
- 11章 アセスメントの実行
前述の通り、第Ⅰ部をまとめます。
第Ⅰ部 監視の原則
まず、第一部では関しの原則について述べられていました。監視のアンチパターンから始まり、利用すべきデザインパターン、監視に対する組織としての動き方、そして、監視で得られるデータの利用方法まで関しの基礎について書かれています。
1章監視のアンチパターン
監視のアンチパターンとして以下の
- ツールを目的とする
- 監視を役割としておく
- チェックリストを作り考えなく監視を継続させる
- 監視を頼りに開発を行なう
- 監視設定を手作業で行なうこと
ツールを目的とする
監視で何を達成したいかよりも、ツールを導入することを目的とする組織が多いことについて言及されていました。監視は単純な問題ではなく、何か一つツールを入れたからすべての目的が達成されるとは限りません（何にでも言えることかもしれませんが）。監視を行なう際は何を何のために監視したいのかを考え、その考えにあったツールを導入する必要があります。 監視のツールが増えすぎ、環境が複雑になっていくことに対して恐れを抱く人が多いが、実はさほど問題にならないということがこの章では述べられていました。
また、どこかの組織でうまく行った監視ツールや手順をそのまま自分の組織やチームに導入してもうまく行くはずが無いことも言及されていました。
監視を役割として置く
監視に対して責務を追う専門家を置く組織は多くありますが、これはあまりうまく行かないことが述べられていました。その理由は、監視の対象を知っているのはあくまで開発を行っているエンジニアであり、つまり、「何を何のために監視するのか」を把握できるのは開発を行っているエンジニアであるということです。そのために、チームの監視に対しての知識水準がある程度高くある必要性が述べられていました。
また、役割としての監視とは別に、セルフサービスの監視ツールを他のチームに提供するチームの有用性は述べられていました。しかし、そのチームはあくまで、監視のツールを作ることが役割で、あるアプリケーションに対する監視のシステムそのものを構築することが無いことも述べられていました。
監視のチェックリストを作り考えなく監視を継続させる
一般的な監視のチェックリストを作り、監視を行なう背景などを考えずにそのチェックリストに従うだけの監視は、うるさく、信頼できない監視を作ることにつながり、監視が無いよりもひどいことになると述べられていました。このアンチパターンに陥っている兆候としては以下のような状態があると述べられていました。
- 色々記録はしているが、システムがダウンした原因がわからない
- 誤検知が多すぎて、監視を無視するようになる
- メトリクスを5分以上長い間隔で監視している
- メトリクスの履歴を保存していない
監視を頼りに開発を行なう
アプリケーションが壊れた際に、その壊れた部分に対して監視を追加し、それに頼って開発を進めるのがアンチパターンの一つであることが述べられていました。監視はあくまでの問題を通知するのに長けており、問題を解決するための手段では無いことが述べられていました。問題の根本の解決は監視とは別に行なう必要があることが述べられていました。
監視ではなく、テストとCIで問題の修正を行なうのが良いかと感じました。
監視設定を手作業で行なうこと
手動で監視の設定を行なうことは、他のインフラ設定と同様にアンチパターンであり、可能な限りコード化、自動化を行なう必要があることが述べられていました。
2章 監視のデザインパターン
監視をより良くしていくための活動や戦略のデザインパターンがこの章では述べられていました。具体的には以下のような項目について述べられていました。
- 組み合わせが可能な監視を行なう
- ユーザ視点で監視を行なう
- はじめは買うことを検討する
- 継続的に改善する
組み合わせが可能な監視を行なう
All in Oneの監視システムを導入するのではなく、監視の目的に合わせて複数のソフトウェア組み合わせプラットフォームを作ることが重要であると述べられています。これはUnixの哲学にも準ずるものであると述べられていました。
組み合わせの監視をプラットフォームを作成することで、一つのツールに依存することなく、必要に応じてコンポーネントを入れ替えることも可能であることが挙げられます。
組み合わせるコンポーネントには以下のようなものがあります。
- データの収集
- 収集の方法ではPush型とPull型がある
- collectedなどはPush型のコンポーネントの例である
- 収集対象はログとメトリクスがあ
- メトリクスはカウンタ（増加していく値）とゲージ（ある時点の値）にわけられる
- ストレージ
- 時系列データベース（Time Series Database）を用いる
- Grahiteなどが例である
- 保存データの解像度などは時間が立つごとに間引いたりしデータ容量が圧迫しないようにする
- 可視化
- 収集したデータを人間に理解しやすい形に可視化する
- Grafanaなどが有名です
- 分析とレポート
- SLA（Service Level Agreement）などに活かすために監視で得たデータを用いて分析を行なうことがある
- アラート
- 監視はアラートを行なうためにあるわけでな無い
- アラートは結果の一つでしか無い
ユーザ視点で監視を行なう
監視はユーザの視点から考え始めることが良いと述べられています。アプリケーションの詳細な実装はユーザは気にせずまずはアプリが"動いているか否か"を気にします。ここに対して効果的な監視はレスポンスコードとリクエスト時間を使うことが効果的です。
はじめは買うことを検討する
サービス開始時などには、SaaSのサービス等を利用することを検討するのが良いと述べられていました。その理由として以下のものが挙げられていました。
- 自分で環境を構築するより安い
- 監視の専門家が常にいるとは限らない
- プロダクトの開発に集中できる
プロダクトの成長とともにSaaSでは対応できない独自のニーズが出てきた際にはじめて独自の監視システムを構築していくことが良いと述べられていました。
継続的に改善する
監視は何年も改善を加えていくことによって完成することが述べられています。
一度作れば完成ではなく状況や目的の変化に合わせて監視をリファクタリングする必要があります。
3章 アラート、オンコール、インシデント管理
この章ではより良いアラートを作り、そのアラートに対する組織としての動き方、アラートの管理の仕方などがまとめられました。
- より良いアラートをつくるために
- オンコール
- インシデント管理
- ふりかえり
より良いアラートを作るために
4章 統計入門
この章では監視を行なう上での統計基礎知識が述べられました。具体的には以下のような統計手法が紹介されていました。
- MeanとAvarage
- 中央値
- 周期性
- 分位数（パーセントタイル）
- 標準偏差
