# 統合監視 ## 定義 統合監視(synthetic monitoring)は、複数の場所からサイトのパフォーマンスを疑似的にテストする監視手法(アクティブモニタリング)である。ping・TCP コネクション・HTTP リクエストを使った内部監視と似た性質を持ち、正常に機能しているかどうか(稼動しているかどうか)を確認するのに最適とされる。ユーザが問題に遭遇する前に検知したいとき、定期監視による基準作りをしたいときに使う。具体的には、カタログページやコメント機能などビジネス上重要な手順の監視、Facebook のページや支払いサービスなど自分では管理できないが依存しているコンポーネントの健康状態監視、複数の都市・通信キャリアでのテスト結果比較による地域・プロバイダ障害の切り分けに向く。原則は負荷テストと同じだが、目的はサイトを落とすことではなく訪問者にとって最適なパフォーマンスを見積もることにある。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 11 訪問者の気持ち：ユーザ対面メトリクス]] §11.3.1) サービスを選ぶ際の考慮点として、スクリプトの記録・管理の容易さ(アプリケーションとの同期を保つ保守コスト)、レポートの粒度、バックエンド監視ツールとのアラート互換性、テスト対象範囲(テキストメッセージング・E メールサインアップ・Twitter 連携・HTML5 WebSocket・Server-Sent Events・動画埋め込み・Ajax・RIA 等をカバーできるか)、テスト手法がスクリプトかブラウザエミュレートか本物のブラウザ(「ブラウザあやつり人形」、コストは高いが実際に DOM を操作するため動作が安定)か、エラー発生時の挙動(アラート送信のみか、詳細記録・経路探索まで行うか)がある。設定自体は、テストする URL・間隔・エラー時対応を決めるだけで比較的簡単だが、応用的な監視には「何も壊さない」ユーザアカウントを別途用意する必要がある。統合監視自体がサーバ資源を消費する点にも注意が要り、トラフィックの50%以上が監視スクリプトだったサイトの例が挙げられている。(Source: ch.11 §11.3.1.2-11.3.1.3) ## 横断的知見 - (1 ソース目のため、横断的知見は次の関連ソース追加時に育てる。) ## 未解決の問い - 統合監視と[[リアルユーザモニタリング]](RUM)を併用する際、両者のデータをどのように1つのダッシュボードへ統合すべきか。本章は「補完的」と述べるにとどまり、統合の具体的な設計(共通のユニークキー・ダッシュボードの粒度)には触れていない。 - 統合監視のトラフィックがサーバ資源の50%を超えた実例が挙げられているが、監視トラフィック自体の負荷を上限管理する定量的な設計指針(サンプリング率・間隔の決め方)は本章に明示されていない。 - 「ブラウザあやつり人形」(実ブラウザでの疑似操作)とスクリプトベースのエミュレーションのコスト・安定性トレードオフは、2011年当時と比べてヘッドレスブラウザ(Puppeteer 等)の普及でどう変わったか。 ## 関連 - 概念: [[リアルユーザモニタリング]](補完的な監視技法) / [[エンドユーザメトリクス]](統合監視が支えるウェブパフォーマンス測定) / [[可用性]] / [[アラートアンチパターン]](フォルスアラート防止の論点) - ソース: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 11 訪問者の気持ち：ユーザ対面メトリクス]] - エンティティ: [[Alistair Croll]] / [[Sean Power]] ## 出典 - アリステア・クロール、シーン・パワー, 「11章 訪問者の気持ち：ユーザ対面メトリクス」, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, §11.3.1.