#はじめに
日々感覚で行ってきた「監視」という業務を改めて見直すため、入門監視(O'Reilly Japan)を購入。
メモ
入門監視を読んで第1部監視の原則(1-4章)
入門監視を読んで第2部監視戦略 (5-11章)

#目次

第1部 監視の原則
 1章 監視のアンチパターン
 2章 監視のデザインパターン
 3章 アラート、オンコール、インシデント管理
 4章 統計入門
第2部 監視戦略
 5章 ビジネスを監視する
 6章 フロントエンド監視
 7章 アプリケーション監視
 8章 サーバ監視
 9章 ネットワーク監視
 10章 セキュリティ監視
 11章 監視アセスメントの実行
付録A 手順書の例：Demo App
付録B 可用性表
付録C 実践 監視 SaaS

##5章ビジネスを監視する
ビジネスKPIについてのエンジニアとしてのアプローチ方法
###1. ビジネスKPI (Key Perfomance Indicator)

経営者や創業者の観点からの関心(ビジネスKPI)は、以下のように簡単に分けることができます。
・顧客はアプリケーションあるいはサービスを使えているか。
・儲かっているか。
・成長しているか、縮小しているか、停滞しているか。
・どのくらい利益が出ているか。収益性は改善しているか、悪化しているか、停滞しているか。
・顧客は喜んでいるか

上記の質問に答えるためのメトリクス
月次経常収益：顧客からの月ごとの経常収益
顧客あたりの収益：顧客ごとの収益。通常は年ごと。
課金顧客の数
ネットプロモータスコア：顧客満足度 (サービス：アプリケーションを他の人にすすめるかを10段階で評価してもらう)
顧客生涯価値：ある顧客の生涯に渡る価値の合計
顧客獲得単価：顧客やユーザを獲得するのにどの裏位のコストがかかるのかの指標
顧客の解約数：アプリケーションやサービスを離れていく顧客の数の指標
アクティブユーザ数：アクティブユーザの定義はビジネるの性質に依存(日次アクティブ？週次？月次？)
バーンレート：会社全体でどのくらいのお金を使っているか？(オフィスの賃料や賃金も含む)
ランレート：現在の支出レベルを続けたときに資金がなくなるまでの期間
TAM(total addressable market)：ある特定のマーケットがどのくらいの大きさなのかの指標
粗利：販売したもののコストを除いた利益を表す指標

##6章フロントエンド監視
フロントエンドの定義：ブラウザあるいはネイティブなモバイルアプリケーションによってパースされて実行されるすべてをフロントエンドとして定義
フロントエンドのパフォーマンス監視のゴール：素早くロードされること (not 動き続けること)

###1. 遅いアプリケーションのコスト

ページロード時間は4秒以下を目指しましょう

ページロードが1秒遅くなると、平均でページビューが11%、顧客満足度が16%下がると言われている
最適なページロード時間は2秒以下で、5.1秒を超えるとビジネスに影響がで始めるといわれている

###2. フロントエンド監視の2つのアプローチ
リアルユーザ監視(Real User Monitoring,RUM)：監視データとして実ユーザトラフィックを使う。各ページにjavascriptの小さなスニペットを入れることで実現
シンセティック監視(Synthetic monitoring)：偽のリクエストを生成し、監視データを得る

###3. リアルユーザ監視
####3-1. DOM(Document Object Model)
DOMは、ツリー構造で表されるWebページの論理的な表現
プログラム(たとえばJavascript)から参照・解釈できるように構造化されている

####3-2. フロントエンドのパフォーマンスのメトリクス
#####Navigation Timing API
ブラウザはNavigation Timing APIを通してページパフォーマンスのメトリクスを公開している
特に有益なメトリクス
NavigationStart：ブラウザによってページリクエストが開始されたタイミング
domLoading：DOMがコンパイルされロードが始まったタイミング
domInteractive：ページが使用可能になったと考えられるタイミング
domContentLoaded：すべてのスクリプトが実行されたタイミング
domComplete：ページがすべて(HTML,CSS,JavaScript)のロードを終えたタイミング

#####Speed Index
視覚的な観点でページがロードされ終わったのがいつかを判断できる。
ユーザの体感を判断する点では、ブラウザが報告してくるメトリクスよりも正確

###4. シンセティック監視
curlの実行のような疑似requestを送り、パフォーマンスを測定する
WebPageTest等のツールを利用するのが1つの方法

##7章アプリケーション監視
###1. メトリクスでアプリケーションを監視する
StatsD：コードの中にメトリクスを追加するためのツール
StatsDはフラッシュ間隔(デフォルト10秒)でメトリクスを集計しバックエンドに送る

###2. healthエンドポイントパターン
/healthにヘルスチェック用のHTTPエンドポイントを作成する

###3. メトリクスにすべきか、ログにすべきか
チームにとってどちらが有益か？ユースケースを元に考える

###4. 何のログを取るべきか
システムを完全に理解し、トラブルシューティングに必要な便利な情報を取得すべき

###5. ディスクに置くべきか、ネットワーク越しに送るべきか
まずはディスクに書き込み、その後ネットワーク越しに送るべき
リアルタイムでのログ送付はトラフィック増加に繋がり面倒なボトルネックを生み出しかねない

###6. マイクロサービスアーキテクチャを監視する
マイクロサービスとは
分散トレーシングを利用する。
分散トレーシング：リクエストごとにIDを付与し、そのIDを元にサービスのアクセス時間の測定やトレーシングを可能にする

##8章サーバ監視
###1. OSの標準的なメトリクス
基本的なメトリクスは取得し、アラートは仕掛けない
OOMKillerをlog監視すると、メモリで重大な障害が起こった際に効果的
CPU/Disk/Memory/ネットワークのメトリクス監視についてコマンドベースで
ロードアベレージに依存することは時間の無駄

###2. SSL証明書
・購入元からEメールなどで有効期限を通知する仕組みを利用する
　ワイルドカード証明書の利用の際は通知が行き渡らない可能性があるため、考慮する
・外部のサイトツール(PingdomやStatusCake)を利用する
　社内などの内部NWに向けたチェックはできない
・社内のSSL監視システムを構築する

###3. SNMP
サーバ監視にSNMPを使うべきではない
・機能を追加するためにエージェントを拡張する作業は容易ではない
・十分にセキュアでない
・メトリクス収集を行うために、ポーリングを行う集中型の仕組みが必要
・他にもっと良いツールが有る (collectd / Telegraf / Diamond)

###4. Webサーバ
・秒間リクエスト数はパフォーマンス / トラフィックのレベルを測る効果的メトリクス
・HTTPステータスコード/リクエスト時間の監視も効果的
・コネクション数はサーバのキープアライブ設定にも依存するためおすすめではない

###5. データベースサーバ
・コネクション数 (MySQLではスレッドと表現するため注意)
・秒間クエリ数 (データベースの稼働状況を確認できる)
・スロークエリ (ユーザの体感が遅くなっているか？がわかる)
・レプリカサーバへのレプリケーション遅延

###6. メッセージキュー
pub/subシステムの監視メトリクスはまずは2つの監視を始めればしばらくの間は大丈夫
・キューの長さ
・消費率

###7. キャッシュ
・キャッシュから追い出されたアイテム数
・ヒット・ミス比率またはキャッシュ・ヒット率

###8. DNS
・ゾーン転送
・秒間クエリ数

##9章ネットワーク監視
残念ながらSNMP一択

####1. NMPの仕組み
・ポート161(ポーリング)/162(トラップ)を使うUDPベースのプロトコル
・エージェントはマネージャに対しOID（オブジェクトID）を提供する
・MIB(Management Infromation Base)はオブジェクトIDとテキスト名を紐付ける
・コミュニティ名とは実質的にパスワードとなる平文

###2. インタフェイスのメトリクス
帯域幅：ある接続から一度に遅れる理論上の最大量
スループット：秒間あたりの送受信ビット数
レイテンシ：パケットがネットワークリンクを通じてやり取りされるのにかかる時間
エラー：送受信エラー / ドロップ / CRCエラー / オーバーラン / キャリアエラー / リセット / コリジョン
ジッタ：あるメトリックの、通常の測定値からの狂い

###3. 構成管理
RANCIDのようなツールは、読み出し専用アカウントでデバイスにログインし、設定をダウンロードし、それをバージョン管理システムに入れるという仕組みで動いています。

###4. ルーティング
ダイナミックルーティングプロトコルは状況を見て監視すべきです。
スパニングツリーの変更は、ネットワークで急に大障害を引き起こす可能性があります。

####BGP
・シャーシのメモリ容量に対するTCAMテーブルのサイズ
・BGPピアノ変更
・BGPのASパス変更
・BGPコミュニティの変更

####OSPF
・アジャセンシの変更

####スパニングツリープロトコル (STP)
・ルートブリッジが変わったのはいつか
・プロトコルのコンバージェンスがいつか

###5. シャーシ
インタフェース同様シャーシも監視を行うべき

####CPUとメモリ
CPUは0から100%にいったりきたりするものもある。
グラフは鵜呑みにせず、アラートは出さない

####ハードウェア
スイッチのスタック、ラインカード、管理カード、電源等

####フロー監視
帯域幅を大きく使っている活動やノードを突き止めたり、IPごとプロトコルごと、アプリケーションごと、サービスごとといった単位で帯域幅の使用率を分析できる。

フローの実装
・NetFlow
・sFlow
・J-Flow
・IPFIX