書籍名：『オライリー 入門 監視』（著者：Mike Julian）
日時：2019年3月7日～3月31日
Before
日時：2019年3月7日～3月31日
Before
監視はインフラエンジニアが片手間でするようなものだろうか？
NWエンジニア、DBエンジニアはいるのに監視エンジニアはなぜいない？
そもそも監視を学べる機会・本が少ない。など、色々な悩みを抱えていた時に、『オライリー 入門 監視』を手にした。
今まで自分がやってきた監視が正しいのか、間違いだったのか、この本で見極めようと思う。
NWエンジニア、DBエンジニアはいるのに監視エンジニアはなぜいない？
そもそも監視を学べる機会・本が少ない。など、色々な悩みを抱えていた時に、『オライリー 入門 監視』を手にした。
今まで自分がやってきた監視が正しいのか、間違いだったのか、この本で見極めようと思う。
気づき
すべてのエンジニア（アプリ・インフラ問わず）に読んでもらいたい一冊。
監視は「インフラエンジニアが片手間で行っていて、昔からのやり方を踏襲している」そんな人達が、この本を読むと目からウロコの一冊だろう。
読んだ瞬間から、書いてあることを実践したくなる。
1章 監視のアンチパターン
- アンチパターンとは、一見よいアイデアだが実装すると手痛いしっぺ返しをくらうものをいう。
- ツール依存になっていないか。
- 監視とは複雑な問題をひとくくりにしたもの、専門化されたツールが複数あって良い。
- 監視Agentは詳細な情報をもたらしてくれる。
- 小さく何かに特化したツールなら作る選択肢も。pythonコードのスクリプトなど。
- 役割をもつ全員が監視に責任を持つべき。
- アプリエンジニアはソースコードのどこに監視のポイントがあるか、ネットワークエンジニアならネットワーク監視の勘所が一番詳しいはず。
- 「動いている」かを監視する。リクエストが200 OKか？文字列は正しいか？レイテンシは増大していないか？
- アラートに関してはOSのメトリクスはあまり意味がない。CPU使用率が99％でも、正しく動いていれば良い。ただし分析・診断には必要。
- メトリクスは高頻度（最低でも60秒）で取らないと意味がない。保存期間に応じてデータの間引き設定を忘れないように。
- 監視設定にも手動ではなく、自動化を。
- 従来型環境は個別に何かを監視していたが、クラウドは集合体（複数システムのまとまり）として監視するよう変わってきた。
- まとめ
- ツールに依存しても、監視の仕組みは良くならない。
- 監視は全員がやるべき仕事。チームや部署内での役割ではない。
- 素晴らしい監視は、チェックボックスに「これは監視しています」とチェックを入れるだけで済むものではない。
2章 監視のデザインパターン
- 組み合わせ可能な監視⇒専門化されたツールを複数使い、監視プラットフォームを作ること。
- 代表的なものGraphite, Sensu, logstash, collectd
- 監視サービス５つの要素
- データ収集
- データストレージ
- 可視化
- 分析とレポート
- アラート
- 何か問題が起きた時にアラートを出すことが監視ではない、監視は質問を投げかける為にある。
- 監視はできるだけユーザに近いところから始める。
- レスポンス監視は何が問題なのか教えてくれないが、何かが問題で、それがユーザに影響を与えていることを知らせてくれる。
- メトリクス監視はユーザへ影響を与えているかどうかで必要有無を判断する。
3章 アラート、オンコール、インシデント管理
- 監視とは、あるシステムやそのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。
- アラート
- 誰かを叩き起こす為のアラート
- 参考情報（FYI)としてのアラート
- アラート通知にメールではない方法を選択する。
- すぐに応答かアクションが必要なアラート
- SMS、PagerDutyなどのページャーを使う
- 注意が必要だがすぐにアクションする必要がないアラート
- Chatなどに送りつけ、レビューなどで参照する。
- 履歴や診断の為に保存しておくアラート
- 良い手順（runbook）は以下の問に答えられる。
- 何のサービスで、何をするものか。
- 誰が責任か。
- どんな依存性をもっているか。
- インフラの構成はどのようなものか。
- どんなメトリクスやログを送っていて、それらはどういう意味か。
- どんなアラートが設定されていて、その理由は。
- コピペで済むような手順書は自動化する。手順書とは問題を解決する為に人の判断と診断が必要。
- アラートのノイズを減らす（アラート疲れをなくすし、重要なアラートに注力）。
- そのアラートはすぐに人が対応しなければいけないアラートか。
- 1ヶ月の推移を見たとき不要なアラート、閾値を変更できるアラートはないか。
- アラートを無くす為に自動化はできないか。
- 自動復旧で問題が修復できないならアラートを送る。
- 前日のアラート一覧を眺め、カイゼンできないか考える。
4章 統計入門
- average、中央値、周期性、分位数、標準偏差の利点と欠点を認識し利用する。
5章 ビジネスを監視する
- 事業（経営層）に影響があるか「サービスは動いているか、ユーザへの影響は？」を監視する。
- ビジネスKPI
- 顧客はサービスを使えているか。
- 儲かっているか。
- 事業が成長しているか。
- どれくらい利益がでているか（でていないか）。
- 顧客は喜んでいるか。
- 月次経常収益
- 顧客あたりの収益
- 課金顧客数
- ネットプロモータスコア
- 顧客生涯価値
- 顧客あたりのコスト
- 顧客獲得単価
- 顧客の解約数
- アクティブユーザ数（1日、1週間、1ヶ月などの単位で）
- サービスによってKPIは異なる。正解を見つけるには人と話し何が知りたい（KPI）かを得ること。
6章 フロントエンド監視
- ページロードが1秒遅くなると、顧客満足度が16％下がる。
- リアルユーザ監視（real user monitoring、RUM）
- 実際のユーザのブラウザよりメトリクスを監視。
- 例）Google Analytics（ページにJavascriptのスニペットを入れる）
- ブラウザはNavigation Timing APIでパフォーマンスメトリクスを公開。
- ツール Graphite, StatsD
- シンセティック監視
- ダミーのリクエストによる監視。
- 例）curlリクエストなど
- 代表的なサービス：WebpageTest
7章 アプリケーション監視
- ページロードが1秒遅くなると、顧客満足度が16％下がる。
- ビルドとリリースのパイプラインを監視
- healthエンドポイントパターン→正常性確認を行えるスクリプトを用意する。カナリアテスト、ステータスエンドポイントとも呼ぶ。
- 分散トレーシング⇒マイクロサービス間のやり取りを監視。（分散トレーシングシステム：Zipkin）ただし大規模向け。
8章 サーバ監視
- サーバ監視でSNMPやめよう。collectd, Telefraf, Diamondなどのプッシュ型へ。
- スケジュールジョブの監視：デッドマン装置
- ログ解析ツール：Splunk、ELK
9章 ネットワーク監視
- ネットワーク機器でも構成管理をRANSID
10章 セキュリティ監視
- auditd（Linu） Linuxカーネルへ直接フックする為、最後まで動作し続けることができる。
- SaaSの利用：CloudPassage, Threat Stack
- RootKit対策：rkhunter
11章 監視アセスメント
- 今までの総復習、ビジネスKPI、メトリクス、ログ、セキュリティ監視、アラート（ページロード時間の増加やレイテンシの増加）
付録
- 監視は開発者自身が自主的に行うべきもので、属人的な権威があってはならない。
- 監視とは「システムに対する高速健康診断」
- 監視とは継続的なテストである。
- ヘルスチェックの共通フォーマット"Health Check Response Format for HTTPS APIs"
- https://tools.ietf.org/id/draft-inadarei-api-health-check-02.html
- https://github.com/inadarei/rfc-healthcheck
すべてのエンジニア（アプリ・インフラ問わず）に読んでもらいたい一冊。
監視は「インフラエンジニアが片手間で行っていて、昔からのやり方を踏襲している」そんな人達が、この本を読むと目からウロコの一冊だろう。
読んだ瞬間から、書いてあることを実践したくなる。
コメント
コメントを投稿