「入門 監視」を読んだ
- 作者: Mike Julian,松浦隼人
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/01/17
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
読んだ目的、モチベーション
- 所謂インフラの監視だけでなく、アプリケーションレイヤーの監視も対象にしていて面白そうだったため。
- 監視はツール等は使ったりしてるが、そもそもどういう基準で原則的として監視すべきかなどの見識がなく、それを補うため。
全体の感想
- ユーザ的な観点で動いているかどうかという原点に立って、何を監視すべきか判断するという考えは面白かった。
- そこから、ビジネスや事業、会社のコンプライアンスなどから何が必要なのかブレークダウンしていく感覚も全体感が掴めてよかった。
- ただし、個々の細かい個別のところまでは流石に行き届いてなかった(本書の目的外でもある)。
- 監視ツールに関してそこまで興味がなかったが、nagiosがここまでオワコンのような扱いを受けてるとは思わなかった。
- マイクロサービスはサービス全体としての健全性の監視も難しそうだなという印象を受けた。
- 導入してみたいと思ったのもあった。
目次
内容
1章 監視のアンチパターン
- ツールでも銀の弾丸はなく、専門性に応じて複数のツールを導入すべき。
- 種類が多くても、出来ることが異なるなら導入すべき
- 成功している企業が導入しているツールを導入したからといって、成功する訳ではない。
- どのような規模や文化で運用されていて、なぜ導入されたかの理解が重要。
- Prometheus - Monitoring system & time series databaseはgoogle社内の監視ツールのBorgmonにインスパイアされたオープンソース
- メトリクスをもっと高頻度で取得しよう
- 最低1分間隔で取得しないと、見逃すので意味ない
- 手動設定はアンチパターン
- 自動化しないと、ノード増やしたりしたときに対応しなくなり、役に立たないものになりスケールできない。
2章 監視のデザインパターン
監視サービスのコンポーネント
- データ収集
- pull型とpush型に分類できて、多くはpush型の方がスケーラブル
- pull型: 中央サービスがスケジュール監視して、リモートノードに対してノードの情報を送るように要求
- push型: syslogなどで、クライアントが定期的にpush
- サーバが増えても、処理等をログ管理サーバ側にまとめやすい。
- ログ形式はJSONなどで構造化すると使いやすい
- pull型とpush型に分類できて、多くはpush型の方がスケーラブル
- データストレージ
- 可視化
- デザインパターン2:ユーザ視点での監視
- OSの標準的なメトリクスを計測するだけでは、役に立たないので、実際に動いてるかどうかを監視すべき。
- デザインパターン3:作るのではなく買う
- メガ大企業でない限り、外部サービスを使った方がコストを抑えられる。
- 性能もSaasの方が上になる。
- デザインパターン4:継続的改善
- 作ったら終わりではなく、運用やサービスの成長、社内環境の変化に応じて進化させていくこと。
3章 アラート、オンコール、インシデント管理
どうしたらアラートをよくできるか
- アラートにメールを使うのをやめよう
- 量が多いとアラート疲れを起こすので、レベルに応じて分ける
- SMS, PageDuty
- チャット
- ログ
- 量が多いとアラート疲れを起こすので、レベルに応じて分ける
- 手順書を書こう
- やり方が自明でコピペするような内容であれば、アラートを飛ばさず自動化すべき
- 固定の閾値を決めることだけが方法ではない
- 統計的な値を使って、的確にアラートを出す
- アラートを削除し、チューニングしよう
- メンテナンス期間を使おう
- まずは自動復旧を試そう
オンコール
- オンコール担当者が不要なアラートを減らすorシステムを修復して、発生数を減らしていく。
- ローテンション制にする
- 必ず振り返りを行う
4章 統計入門
- 取りたい異常値の種類に応じて、平均値や中央値などを使い分けようという話だった。
- 安易に平均値を使ったりすると、検出すべき特異値が検出できないなど。
5章 ビジネスを監視する
- 事業的に重要な数字やKPI等を視覚化して、健全性を見ること。
- 売上
- ユーザ数
- (投稿サービスにおける)コメント数など
6章 フロントエンド監視
フロントエンドの監視はされないことが多いが、ビジネスに直結するため監視すべき。
- 成果例
- Amazon
- ロード時間を100ms改善すると売上が1%増加
- http://bit.ly/2y494hq
- Pinterest
- 体感時間を40%短縮した結果、SEOトラフィックと新規登録が15%増加した。
- medium.com
- Amazon
- DOM
- 基本的にはツールを導入することになる。
- Navigation Timing API
- Speed Index
- 詳細な情報は取れないが、ユーザから見た視覚的な観点でのロード時間を取れる。
- sites.google.com
- ロギング
- Saasを使ってjsのエラーログを取るべき
- シンセティック監視
- プルリクエストごとにフロントエンドへの計測できる環境が望ましく、WebpageTestのAPIをCIに組み込むことで実現できる。
7章 アプリケーション監視
- メトリクスでアプリケーションを計測する
- StatsDは気軽に導入できるのでオススメ
- github.com
- ビルドとリリースのパイプラインの監視
- デプロイの日時・担当者を記録しておくと、他のメトリクスと重ね合わせて調査しやすくなる。
- healthエンドポイントパターン
- /healthというエンドポイントを用意して、アプリケーション側で正常か否かチェックしてJSON等でレスポンスを返してチェックすること。
- 特にマクロサービス化を導入していると、サービス全体の状態が把握しやすい。
- マイクロサービスアーキテクチャを監視する
8章 サーバ監視
- OSの標準的なメトリクス
- ロードアベレージ
- 代理指標にはなり得るが、高くてもサービスは動くケースは多々あり、あまり当てにならない。
- ロードアベレージ
- SSL証明書の有効期限
- SNMP
- ネットワーク監視には使う必要があるが、サーバ監視にはオススメしない。
- プッシュベースのツールを選ぶべき
- データベースサーバ
- コネクション数で全体のトラフィックレベル
- 秒間クエリ数でDBの忙しさ
- オススメの書籍
- スケジュールジョブの監視
sh run-backup.sh 2>1& backup.log || echo "Job failed" > backup.log
- 解決策の一つは デッドマン装置
- 何らかの仕組みがアクションを止めるように指示するまではあるアクションを行うという仕組み。(多重実行されたりするので本番導入には、ある程度工夫が必要)
- Operation Ducksledge: Dead Man's Switch on Linux, Part 1: Basic bash
- ロギング
- 段階に応じて対応する。
- 収集
- 保存
- syslogで突っ込むだけでは使われないので、適切なサービスを使って保存する。
- 分析
- 段階に応じて対応する。
9章 ネットワーク監視
- SNMPのつらさ
- 唯一の手段だが、レガシーでかなり辛いらしい(私は使ったことないので想像つかない)。
- 知人が殺されたのかっていうぐらい批判的に記述されてた。
- 唯一の手段だが、レガシーでかなり辛いらしい(私は使ったことないので想像つかない)。
- 構成管理
- 設定変更の追跡はRANCIDのようなツールでバージョン管理できる。
- www.shrubbery.net
- 音声と映像
- レイテンシ、ジッタ、パケットロスを計測するのが基本中の基本。
10章 セキュリティ監視
詳しく深掘りたいなら、この本がオススメと記載されていた。
The Practice of Network Security Monitoring: Understanding Incident Detection and Response
- 作者: Richard Bejtlich
- 出版社/メーカー: No Starch Press
- 発売日: 2013/07/15
- メディア: ペーパーバック
- この商品を含むブログを見る
- 作者: Mike Julian,松浦隼人
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/01/17
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る