こちら。
監視に興味を持ち始めていましたので、読みました。
読んでみて
監視の基本の原理原則的なものを幅広く抑えられていました。
私には、監視の「か」の字をわかっているかと言われたら危うい感じだったので、初歩から標準のことを知ることができたと思っています。
なので、ある特定の部分の監視のことで。。。みたいな具体的な悩みを持って、それを解決するためにこの本を読もうとしていると少し検討違いになってしまうと思いました。
また、ある程度仕事の中で監視をやってきて経験を積まれている方からしても、そこまで奥深いことが書いているわけではないので、読んだら「なんだ当たり前なことばかりじゃねーか」みたいになってしまうのかなと思いました。（基本がとても整理されている本だと思うので、復習みたいにはなるのかもしれない）
どんな構成だったのか
目次はいろんなwebページにも書いてありますが、
- 監視の原則
- 監視の戦略
と大きく二つに分かれていて
監視の原則では
など、について書かれていました。
こちらは、「今から目の前のシステムの監視の設定、実装をしていくぞ！」というわけではなく、
「監視とはなんなのか？」
「今までの監視の悪いところをあげ、こうした方がいい的な」
など、監視の実装を始める前の基本的な考え方をアンチパターンとデザインパターンから説明されていました。
監視の戦略では、
- ビジネスKPI
- フロンエンド
- アプリケーション
- サーバー
- ネットワーク
- セキュリティ
など、各領域ごとに監視のパターンが書かれていました。
色々なwebサービスがある中で、フロントエンド監視も見逃してはいけないものと取り上げられていました。
印象に残っていること（というよりも覚えていること）
読んだのにもう忘れている。。。
結構当たり前なことですが、印象に残っていたり、まだ忘れていないことを羅列していきます。
whatから始めない
アンチパターンで述べられていました。
まず、ツール依存が結構多いらしいということ。
「このツールを使えば、OKでしょ。使おう」的なwhatが最初から来てしまい、結局導入した監視によって何も効率的な恩恵を受けられないというもの。
ツールを検証目的で色々試すのはOKだと思いますが、あの会社もあの会社もいいと言っていたから導入するのではなく、目的やワークフローに合っているかの見極めをちゃんとした上で導入なんだと教えられました。
自動化しましょう
このへんのアンチパターンは前職時代と結構紐付きながら読んでいました。。。
まさに「このコマンドを実行して、次にこのコマンドを。。。」みたいな手順書が溢れていましたので、
そういうのは自動化してプロダクトに集中しましょう。
導入は時間をかけて（かけすぎはよくない）、導入後は自動化してコストかけない
こんな感じにできると良さそうですね。
過去の値も必要
KPIに関することをやっていたので、少し引っかかりました。
今はある時点でのデータしか取って来ていないので、過去の値と時系列に見れるようにしたら、周期性が出て分析できたり、、、
この本でそこまで強く言ってないですが、時系列データ、過去のデータを蓄積してみないと原因もわからないと言ってました。
作るのではなく買う
これは企業の規模やフェーズに依存する話でした。
- スタートアップみたいに規模の小さいところだったら、監視サービスを簡単に導入してプロダクトに集中すべき
- 大企業になったら、独自の課題が出てしまい、監視サービスでは解決できない。そうしたら、自作する
企業が大きくなるにつれて監視への課題は変わってくるので、そうなったら、自作した方がいい（するしかない）ですが、そうでもなければ、わざわざコストを払って自作する必要ないので、その辺の塩梅はちゃんと判断しましょうということでした。
ついでに、監視の仕組みは1度作って終わりではなく、絶えず変化していくので、その都度、会話・判断・実装が必要です。
監視は単一の問題ではない
非常に大きな問題の塊であるため、1つのツールで解決できるものではないと述べられていました。
書籍では、それぞれ専門的なツールが増えるのは構わない的な形で書かれていました。（使用するものが多くなって複雑になってしまうことに対して恐れることが多いようです） 増えることがいいことではなく、1つの統合ツールで解決できない問題を解決するのであれば、上記のようにツールが増えても構わないということだそうです。
それぞれのツールが疎結合になっていれば、あるツールだけワークフローに合わなくなったりしたら、それだけ削除して新しいものに置き換えればいいと、組み合わせ可能な監視プラットフォームの構築を推奨していました
組み合わせ可能な監視を構成する要素
- データ収集
- データストレージ
- 可視化
- 分析とレポート
- アラート
優先すべきは外側から
どこから監視をしていくのかという問いです。
OSのメトリクスなどももちろん有用ですが、まずはユーザーに近いところから着手すべきだと（ちゃんと動いているのかなど）
本書ではOSのメトリクスがちょいちょいと批判されていました。
それが不必要なものではということを言っているわけではなく、 例えば、CPU使用率が急上昇したとしても、ユーザーが使用するのに影響を与えているわけではないのであれば、アラートを上げて動かなくてもいいということでした。
この本の場合、どこを重視するかという点においてユーザーに関わる部分、つまりアプリケーションが動いているかという部分が重要になっているため、OSのメトリクスは上記の重要な部分とは関連性が薄いということで優先度が低くなるというものでした。
なので、この辺は企業や状況によって変わるような気がします。
ちなみにOSのメトリクスに関する話しは付録Cで @songmuさんのお酒に例えた話しがわかりやすく、「直接の原因であり、コントロール可能な数値を監視すべき」という言葉でとても腑に落ちました。
外側からという考えに従うと、個人的にはユーザーに関わる部分、ビジネスに関わる部分に対しては優先的に動けるようにしたいと思いました。
フロントエンドも重要
昔からの慣習なのか、この辺の監視の意識が薄いようです。
ただ、ページが表示されるまでの時間がかかってしまうとユーザーが離れてしまうという実績は様々な企業からたくさん出ているので、この領域の監視は見逃せないものだと思い知らされました。
個人的にはフロントエンドの開発をしたりはしているのですが、この辺に重きを置いて開発したりしたことはなかったので、今度休日に少し遊んでみようと思いました。
さいごに
個人的に、ネットワーク監視は、ほぼ経験したことがなかったので、少し頭に入りづらいことが多かったです。
今度こちらも休日に遊んでみようと思いました。
