監視・ログ分析を最初から始めるイマドキの事情と理由・その2（解決編）

https://dev.classmethod.jp/articles/202007-devio2020-monitoring-1-2
https://www.youtube.com/watch?v=9gdIA9V8Sa0

Transcript

1. 後回しに
   しない
   ❗
   2
   監視･ログ分析を最初から始める
   イマドキの事情と理由・その
   〜 解 決 編 〜
   渡辺聖剛
   ソリューションアーキテクト
   AWS事業本部 パートナーアライアンス部
   2020.07.03
   

   View Slide

2. 2
   監視回　その2
   https://dev.classmethod.jp/news/developers-io-2020/
   
   イマココ
   

   View Slide

3. 3
   自己紹介
   渡辺聖剛 ( Seigo Watanabe )
   ● クラスメソッド株式会社
   AWS 事業本部
   パートナーアライアンス部
   ● 前職までは
   所謂インフラエンジニア
   ● 運用・監視(Monitoring)
   ● 好きな AWS サービス
   ○ ACM, Route 53
   ○ AWS Systems Manager
   https://dev.classmethod.jp/author/watanabe-seigo/
   

   View Slide

4. 4
   ※未承諾広告
   モニタリングまわりの記事を担当
   AWSにかなり限定した内容に
   なってます
   重複するところは多いですが、
   本ではかけなかった話
   ＋アップデートを話します
   https://gihyo.jp/book/2020/978-4-297-11329-2
   

   View Slide

5. 5
   前回のあらすじ
   

   View Slide

6. 6
   前回のあらすじ（おさらい）
   SREはMonitoringする生き物
   SLI/SLOを計測する
   計測（エージェントの組み込み）は最初から
   

   View Slide

7. 7
   前回のあらすじ（cont.）
   大量の情報を
   最初から取ってると
   どうなる？
   https://pixnio.com/ja/
   

   View Slide

8. 8
   前回のあらすじ（cont.）
   あふれます
   続きはその2で！
   https://booksbelow.wordpress.com/2010/05/31/on-writing-or-lack-of-it/
   
   

   View Slide

9. 9
   本日のゴール
   

   View Slide

10. 10
    本日のゴール
    ・・・という晴れやかな気持ちになること、
    https://booksbelow.wordpress.com/2010/05/31/on-writing-or-lack-of-it/
    https://flic.kr/p/8jmS1F
    https://www.irasutoya.com/2018/11/blog-post_109.html
    

    View Slide

11. 11
    本日のゴール
    そのためには道具が必要ですよね？
    ・・・という話をします
    

    View Slide

12. 12
    Agenda
    

    View Slide

13. 13
    Agenda
    「あふれる問題」について
    2つの解決策
    ・運用でカバー
    ・物理でカバー
    Tips・注意点
    まとめ
    

    View Slide

14. 14
    免責事項（再掲）
    時間が限られているので
    すごくざっくりした話しかしません
    流れをつかんでもらうのが目的です
    

    View Slide

15. 15
    免責事項　その2（再掲）
    時間が限られているので
    スライドに書いてあること全てを話しません
    興味がわいたらあとから読んで頂けますと！
    

    View Slide

16. 16
    免責事項　その3
    ここで話す「監視」とは
    M（Monitoring）のことです
    詳細はその1参照のこと
    https://www.oreilly.com/library/view/practical-monitoring/9781491957349/
    

    View Slide

17. 17
    あふれる問題
    

    View Slide

18. 18
    ログも監視データもアラートもあふれる
    監視データ(正規化・コンテキスト低)
    ログデータ(非正規化・コンテキスト高)
    アラート(24x7)
    なぜ？
    - 時代はマイクロサービス
    - リソースの爆発的増加
    - 監視頻度も上昇
    - 取得データは詳細化
    https://www.pexels.com/photo/cargo-container-lot-906494/
    

    View Slide

19. 19
    あふれたらどうなるか
    あふれる = それこそ可観測性に関わる問題
    昔からあるオオカミ少年化問題
    https://www.irasutoya.com/2016/10/blog-post_173.html
    

    View Slide

20. 20
    解決策1 :
    運用 工夫でカバー
    

    View Slide

21. 21
    ❌運用　⭕工夫
    「頑張る」だけは必ず回避しましょう
    - 継続できなければ続かない
    よくある「頑張る」の例
    - 見なくていいものにひとつずつフィルタ
    - 通知された複数の値を脳内で結合
    

    View Slide

22. 22
    工夫でカバーその1
    代表値でとらえる
    

    View Slide

23. 23
    代表値でとらえる
    個々を見るのではなく、全体の動作で把握する
    ● サイト全体のSLI/SLO
    ● AutoScaling Group
    ● フロントエンド監視
    ○ Synthetic Monitoring（シンセティック監視・合成監視）
    ○ Real-User Monitoring（RUM・リアルユーザー監視）
    ● Apdex（Application Performance Index）
    ● ビジネスKPI
    https://www.flickr.com/photos/epeirogenic/with/3070203272/
    

    View Slide

24. 24
    Load Averageも代表値
    単位時間あたりの実行待ちとI/O待ちのプロセスの数で
    システムの負荷を表現したもの
    待ちが多い = 負荷が高い
    分散システムだと扱いづらい値ではあるが、
    使いどころによってはまだ有効
    https://www.techscore.com/blog/2017/12/08/how_is_load_average_calculated/
    

    View Slide

25. 25
    フロントエンド監視
    

    View Slide

26. 26
    フロントエンド監視
    ユーザ・クライアントが体験する機能や動作を計測
    APMと付き合わせて挙動を明らかにする
    https://www.irasutoya.com
    合成監視
    アクセスを機械的に
    シミュレート
    RUM
    ユーザがアクセスし
    た際にデータを収集 APM
    Application Performance
    Management / Monitoring
    

    View Slide

27. 27
    フロントエンド監視(cont.)
    シンセティクス = 見たいところを定期的に監視
    RUM = 実際にユーザが見た時・見たところを監視
    “最良のモニタリング戦略は、フロントエンドとバック
    エンドのソリューションを組み合わせたもの”
    - リアルユーザモニタリング（RUM） vs 合成モニタリン
    グ: 顧客体験を改善するにはどうしたらいいか - New
    Relic公式ブログ
    https://blog.newrelic.co.jp/uncategorized/synthetic-versus-real-user-monitoring/
    

    View Slide

28. 28
    フロントエンド監視(cont.)
    Google Analytics (GA) や外形監視とは目的が異なる
    - GA : サイト訪問者の動向分析・広告効果測定・SEO
    - 外形 : ポート監視・API監視・ヘルスチェック
    重複する領域が多いため同一視されやすい印象
    外形監視
    ・「外部から」の監視
    ・Web、DB、SMTP
    ・応答をチェック
    ・ブラックボックス監視
    https://www.atmarkit.co.jp/ait/articles/0403/20/news010.html
    https://takehora.hatenadiary.jp/entry/2019/07/05/012036
    https://devops.com/black-box-vs-white-box-monitoring-what-you-need-to-know/
    シンセティック監視
    ・「外部から」の監視
    ・Web、REST API
    ・応答のみならず
    　一連のシーケンスなども
    　APMとしてデータ収集
    ・ホワイトボックス監視
    

    View Slide

29. 29
    Apdex
    

    View Slide

30. 30
    Apdex（Application Performance Index）
    ユーザー体験の快適さ・満足度を、レスポンスタイムを
    指標に数値で表現したもの
    仮に「0.5秒以内にレスポンスがあること」
    を満足と定義する（T=0.5）
    ※SLOとは別に定義（ex) 0 < SLO ≦ 4T）
    https://www.apdex.org/index.php/about/
    https://blog.newrelic.com/product-news/how-to-choose-apdex-t/
    Satisfied（満足） 0〜0.5秒 n ≦ T
    Tolerated（許容範囲） 0.5〜2.0秒 T < n ≦ 4T
    Frustrated（不満） 2.0秒〜 4T < n
    

    View Slide

31. 31
    工夫でカバーその2
    統計値でとらえる
    

    View Slide

32. 32
    統計値でとららえる
    数値の上下に一喜一憂せず、数値の「意味」を取り出す
    統計値・統計分析
    ○ 複数のメトリクスを数値計算して可視化
    ○ 移動平均や線形予測など
    パーセンタイル（分位数）p80,p99など
    ○ 単位時間当たりの全ての数字を昇順ソートして、
    全体のパーセンテージにあたる値
    ○ 平均とは違い、突発的なスパイクを除外できる
    https://stopcovid19.metro.tokyo.lg.jp/
    

    View Slide

33. 33
    動的な閾値設定
    外れ値（Outlier）検知
    ふるまい（Anomaly）検知
    - 通常の傾向から外れた動きの検知
    - 急激な増加・減少、ルーティンとは違う動き
    - 統計的手法や機械学習による分類手法
    閾値の設定を固定とせず、
    状況に応じた検出・通知を行う
    https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/
    CloudWatch_Anomaly_Detection.html
    

    View Slide

34. 34
    ビジネスKPIも大事なメトリクス
    政治層のひとが見てくれるダッシュボードを整備するこ
    とで、「上司に報告」という重大な業務が効率化できる
    ○ サービスを見るのはエンジニアも必要な視点
    ○ SLOの判断基準になる
    ※事例を後述
    

    View Slide

35. 35
    工夫でカバーその3
    可視化
    Visualization
    

    View Slide

36. 36
    可視化 = データの意味づけ
    コンテキストに基づいて情報を整理
    Information（情報）から
    Intelligence（分析された知識）へ
    https://www.history.com/topics/us-government/history-of-the-cia
    

    View Slide

37. 37
    可視化 = 情報を素早く把握するための方法
    アンスコムの例（Anscombe’s quartet）
    可視化することで特徴が見えてくる
    https://ja.wikipedia.org/wiki/アンスコムの例
    

    View Slide

38. 38
    可視化 = 情報を素早く把握するための方法
    “データ可視化の主なメリットは三つがあります：
    1. 現状を把握し、課題やその原因を発見することで、
    迅速な対応が可能になる
    2. 社内にデータをオープンに利用可能に、
    情報を早く共有し、業務の効率を上げる
    3. 社内の様々なデータを統合することで、
    予測分析を行い、トレンドの洞察を得られる”
    データ可視化とは？その必要性と基本手法を解説
    https://kirikuroda.github.io/datareporting/introduction.html
    

    View Slide

39. 39
    工夫でカバーその4
    その他の工夫
    

    View Slide

40. 40
    工夫 = 効率を上げる
    「見なくて良いものは見ない」は正しいか？
    ○ 例) CPU利用率ってアラート投げる必要ある？
    ○ 明らかに不要なものは言うまでもない
    （クラウドなのにH/W RAIDエラーとか…）
    →見なくても取っておこう
    ○ 分析するときには必要
    ○ 収集したデータをふるい分けする
    「いま見るべきもの」と「あとで見る/見そうなもの」
    ○ いま見なくて良いもの→通知もしなくて良い
    

    View Slide

41. 41
    分類例
    ● 即応が必要なもの (on-call alert)
    ● 対応は必要だが即応不要なもの (chat notice)
    ● 対応は要らないが知っておきたいもの (log info)
    ● 監査や障害調査のために (log-archive debug)
    参考（再掲）：
    Lambdaのログレベル方針について、チームで話して
    明文化してみた | Developers.IO
    https://dev.classmethod.jp/articles/lambda-log-level/
    

    View Slide

42. 42
    だれに通知する？
    人間に通知する→ITSやChatに直接通知
    ○ 初動を早くする
    機械に通知する→自動化
    ● 誰も気付かなければ障害ではない
    ● 無事復旧できたのならオンコールは不要
    ● TCP/IPの再送も自動的な復旧のひとつ
    ○ 許容範囲内に収まるならいちいち監視しない
    （逆説的に）障害であるのなら、気付けるようにすべき
    

    View Slide

43. 43
    どこまで細かく求めるか？
    “1秒間のダウンタイムを計測するには、1秒未満の間隔
    でデータを収集する必要があります”
    - 入門　監視
    「波形を捉えるには、その波形の最大周波数の2倍を超
    えた周波数で標本化する必要がある」
    - シャノンの定理（標本化定理）
    https://pixnio.com/ja/
    

    View Slide

44. 44
    「海岸線の正確な長さを測定しなさい」
    1kmの物差しを使うと、小さな入り江や岬が測れない
    100mの物差しを使うと、ゴツゴツの岩肌が測れない
    10m、1m ... スケールを変えると、いままで測れていな
    かったものが見えてくる
    1mm、0.1mm ... 砂粒の起伏をどうやって測る？
    そもそも波や、潮の満ち引きがあるなかで、
    どこまで測る意味がある？
    https://pixnio.com/ja/
    https://www.irasutoya.com/2017/03/blog-post_421.html
    

    View Slide

45. 45
    基準を与えるのがSLI/SLO
    →SLOに必要なだけのSLIを、
    　必要十分な粒度で測定しましょう
    https://pixnio.com/ja/
    https://www.irasutoya.com/2013/03/blog-post_1704.html
    

    View Slide

46. 46
    ところで
    ここまでやっても、
    やっぱり運用でカバーつらくないですか？
    

    View Slide

47. 47
    解決策2 :
    物理 ツールで解決
    

    View Slide

48. 48
    「ツール」とは
    ソフトウェアだけに限らず、
    世にあふれるメソッドも「ツール」の
    ひとつ
    「巨人の肩の上に立つ」
    巨人 = 偉大な先人の知恵を
    積極的に借りよう
    https://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants
    https://www.irasutoya.com/2019/01/blog-post_43.html
    

    View Slide

49. 49
    ここで紹介する「ツール」
    ダッシュボード
    AIOps/MLOps
    カオスエンジニアリング
    SaaS
    ほかにもいっぱいある！
    その1で引用したものも「ツール」「巨人」です
    

    View Slide

50. 50
    ダッシュボード
    

    View Slide

51. 51
    ダッシュボード = 「ひと目で分かる」
    “企業内の各種ビジネスデータから重要な要点を抽出し
    て、ひと目で分かるように視覚化したもの”
    “自動車の計器盤のメタファー”
    - デジタルダッシュボード, Wikipedia
    多くの監視・モニタリングツールは
    ダッシュボードのカスタマイズに対応
    - CloudWatch Dashboardsなどなど
    https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/GettingStarted.html
    

    View Slide

52. 52
    ダッシュボードも進化する
    対象と役割が変化すれば、
    最適なダッシュボードの形態も変化する
    2000 2020
    https://spaceflight.nasa.gov/gallery/images/shuttle/sts-101/html/jsc2000e10522.html
    https://www.youtube.com/watch?v=won6Ap9JnVw
    

    View Slide

53. 53
    New Relic One プログラマブルダッシュボード
    Reactコンポーネントを使って
    独自のダッシュボードを
    作成可能
    ※既存のカスタマイズ機能に
    　飽き足らないひと向け
    https://docs.newrelic.com/docs/new-relic-one/use-new-relic-one/build-new-relic-one/
    new-relic-one-build-your-own-custom-new-relic-one-application
    

    View Slide

54. 54
    ダッシュボードはみんなのために
    分かりやすく可視化 = データの民主化
    “開発委託先が月に一度の運用レポートを、専門家では
    ない担当社員に届けるといういままでの体制から、毎分
    更新される最新の運用情報が、普段慣れ親しんだビジネ
    ス指標と一緒に届くことで、自分たちがサービスを届け
    ているというライブ感とユーザーの反応をダイレクトに
    共有できる”
    大規模キャンペーンでの Mackerel活用で
    ビジネス上のKPIもダッシュボードで可視化
    ～クレディセゾン～
    https://mackerel.io/ja/blog/entry/customers/credit-saison
    

    View Slide

55. 55
    AIOps / MLOps
    

    View Slide

56. 56
    AIOps・MLOps
    AI（機械学習によるパターン認識・分類）で
    情報をふるい分け・利用者にリコメンド
    - 予測検知
    - トリアージ、ノイズの軽減
    - RootCauseのサジェスト
    AIOpsは絶賛進化中
    プレーヤーは続々
    - New Relic, IBM Watson, moogsoft etc...
    

    View Slide

57. 57
    GameDay
    Chaos Engineering
    

    View Slide

58. 58
    GameDay
    あるシチュエーションを設定し、
    本番さながらの環境を用意して、
    日頃の備えやスキルがうまく回るかを測るもの
    （あるいはそれ競技化したもの）
    ● 自動車の衝突実験（制御された事故）
    + 消防訓練（経験を通じて本番に備える）
    + 予防接種（耐性を付ける）
    https://awsgamedaymicroservicestokyo.splashthat.com/
    https://www.mlit.go.jp/jidosha/anzen/02assessment/car_h21/test_crash.html
    

    View Slide

59. 59
    Chaos Engineering
    「GameDayを定期的・定常的に行う」もの
    - 日常的に「制御された」障害が発生する
    - システム・運用チームはそれに対処する
    - 対処 = SLO内で完結させる
    ● 予告なし（抜き打ち）訓練
    ○ 運用担当（人間）チームが対応できるか
    ○ 自動対処・リカバリ（機械）は意図通りに機能するか
    https://www.gremlin.com/
    

    View Slide

60. 60
    GameDay・Chaos Engineeringは
    Design for failureの原則に従っているかの実地検査
    “Everything fails all the time”
    全ては障害を起こすもの、
    という前提から逆算した設計
    ・SPOFの排除
    ・H/Wが故障してもAppには影響を
    　及ぼさないように
    そうすれば、
    真に壊れるものはなくなる
    AWS re:Invent 2019 - Keynote with Dr. Werner Vogels
    https://www.youtube.com/watch?v=OdzaTbaQwTg
    

    View Slide

61. 61
    ※未承諾広告
    New Relic +
    Classmethod
    カオスエンジニアリング
    やってます
    https://classmethod.jp/news/200414-newrelic/
    https://cloud.watch.impress.co.jp/docs/news/1247030.html
    

    View Slide

62. 62
    SaaS
    

    View Slide

63. 63
    運用のためのツールの運用を頑張る？
    その「頑張ってる」ものは業務の本筋ですか？
    頑張ることで失っているものはありませんか？
    ○ 時間
    ○ 稼働
    頑張らない → SaaSをいれて楽になろう
    

    View Slide

64. 64
    「SaaSいれて楽になろう」？
    正確に言えば、
    ● SaaSだからといって、頑張らなくてよくなる
    わけではない
    ● 頑張るところが変わるだけ
    本来集中したいところに集中
    ● →責任共有モデル（by AWS）
    https://aws.amazon.com/jp/compliance/shared-responsibility-model/
    

    View Slide

65. 65
    ご紹介
    ❖ CloudWatchファミリー
    ❖ Mackerel
    ❖ New Relic
    ❖ Sumo Logic
    ❖ その他
    （基本的に弊社で扱っているもの）
    

    View Slide

66. 66
    免責事項　その4
    完全に適材適所・ケースバイケースの世界なので、
    正解は「まず使ってみる」
    SaaSは日々開発が続き進歩しているので、いまの情報
    が明日正しいとは限らない
    なんとなく「この辺かな？」と当たりを付けるときにご
    参照頂ければ
    

    View Slide

67. 67
    CloudWatchファミリー
    ※X-RayなどCloudWatchを冠さないものも含む
    ● 全ての基本
    ● サードパーティ製品はCloudWatchに依存
    ● 最初から用意されている
    ● 使いこなすために頑張る必要がある
    ○ 個々の機能が完全に統合されていない、
    ダッシュボード機能の不足など
    ● 完全にAWS特化
    出来ることと、他のもので補えるもの・
    補うと楽なもの・補うべきものを認識して使う
    https://aws.amazon.com/jp/cloudwatch/
    

    View Slide

68. 68
    Mackerel
    ● 純国産。はじめの一歩
    ● 楽に始められる、それでいて見た目や操作性も
    良い、拡張性も分かりやすい
    ● 監視をしっかりやりたい、でもどこから？
    となっているひと向け
    ○ Sな監視をしていた方々が入りやすいと思われる
    ● 使っていくと物足りなくなってくるところはある
    次の一手：拡張・作り込む、単分野SaaSと組み合わせ
    る、統合型SaaSに乗り換える
    https://mackerel.io/ja/
    

    View Slide

69. 69
    New Relic
    ● 自他共に認める「可観測性プラットフォーム」
    ● 可視化、パフォーマンスチューニングの強い味方
    ● なんでもそろってる。
    全ての機能はAPMのためにある
    ○ なので、例えばインフラ監視だけのために入れるメリッ
    トは薄い（ないわけではもちろん無い）
    ● 逆にいうと、全体像の把握や使いこなしに力が要る
    ● Lambdaやk8sにももちろん対応
    目的のために邁進できる強い組織の強い味方
    https://newrelic.co.jp/
    

    View Slide

70. 70
    Sumo Logic
    ● 純SaaS型SIEM
    ● 一方でLambdaやk8sのダッシュボードもある
    ○ SIEMとして入れて応用するのはよさそう
    ● ありとあらゆるプラットフォームのログを収集して
    一元管理・可視化
    ● メトリック収集機能もある
    ○ ただしログ分析の補助的なものにとどまる
    ログ収集・集積・可視化 + 脅威評価・分析
    https://www.sumologic.jp/
    

    View Slide

71. Sumo
    Logic
    New Relic
    71
    各SaaSの得意分野図
    App
    OS
    インフラ
    (AWS)
    Event Log Metric Trace
    (APM)
    Frontend
    Synthetics
    RUM
    S3, CWLogs CloudWatch X-Ray CWSynthetics
    k8s, FaaS
    Mackerel
    ※面積の広さと製品の優劣は無関係です
    ※製品動向の全てを表現しているわけではありません。2次元の図では表現しきれません…
    ML
    AIOps
    

    View Slide

72. 72
    その他にもSaaSはたくさん
    Datadog
    インフラエンジニアが持ち得る最強のツール
    全方位に隙なし
    Cloud Monitor（旧Stackdriver） Googleの考える最強の監視システム
    Pingdom フロントエンド監視特化
    SignalFx, Instana APM特化。リアルタイム指向
    Sysdig monitor セキュリティ用途強め。クローズドボックス監視
    AirBreak トレースログに特化。OSS実装のerrbitも
    Epsagon 分散トレーシング特化。エージェントレス
    他にも Humio, AppDynamics, Dynatrace ...（書き切れません）
    各ツールは独自の特徴と特色、UI/UX、出自と得意分野をもっています。
    いろいろ試して自分たちにあったものを！
    

    View Slide

73. 73
    ※未承諾広告
    気になったSaaSは
    Developers.IOで検索❗
    https://dev.classmethod.jp/
    

    View Slide

74. 74
    押さえておきたい
    ● Prometheus + Grafana
    ● OpenTelemetry, OpenMetrics
    

    View Slide

75. 75
    Prometheus + Grafana
    OSSモニタリングツールの現在の代表格
    CNCF・Docker・k8sでは業界標準
    各社「Prometheus形式のメトリクス」に
    対応を開始
    - Datadog Prometheus Check
    - New Relic Prometheus integrations
    - Amazon CloudWatch ...
    https://docs.datadoghq.com/ja/integrations/prometheus/
    https://docs.newrelic.com/docs/integrations/prometheus-integrations
    https://aws.amazon.com/jp/about-aws/whats-new/2020/05/amazon-cloudwatch-now-
    monitors-prometheus-metrics-now-in-beta/
    

    View Slide

76. 76
    OpenTelemetry, OpenMetrics
    トレース情報・メトリック情報のCNCFによる標準化
    ※現在ベータ・Coming soon
    https://opentelemetry.io/
    https://openmetrics.io/
    

    View Slide

77. 77
    Tips・注意点
    

    View Slide

78. 78
    Zabbixは？
    まだまだ現役。進化も開発も続いている
    ‘20/07現在でZabbix5.0
    必要なのは、どのツールが一番合うかを考えること
    - 監視対象、運用体制
    - 盲目的に「あれがいい」「これはダメ」というのは
    やめよう
    - （その点で、SaaSは始めやすく止めやすい）
    https://www.zabbix.com/jp
    

    View Slide

79. 79
    CI/CDも監視対象にしよう
    いつDeployしたか？その前後で傾向に変化は？
    Deployにどのくらい時間がかかっているか？
    コンテナイメージのサイズは？
    見るべきポイントはたくさんあります
    - Top 5 container and Kubernetes best practices
    re:Invent 2019
    https://dev.classmethod.jp/articles/reinvent2019-container-best-practices/
    https://dev.classmethod.jp/articles/201912-report-con307-reinvent2019/
    

    View Slide

80. 80
    監視エージェントの影響を最小限に
    コスト的にも性能的にも、
    エージェントが足を引っ張っては意味がない
    いち案：サンプリングという考え方
    ○ 同一集団のなかで1つだけエージェントを動かす
    ○ あるいは、トラフィック全体の一部を計測用に流す
    ● 特定条件にあう場合においてのみエージェントを
    導入 or 起動する仕組み
    

    View Slide

81. 81
    テクニックとしては考えられるが、それによって取得で
    きるデータに制限がでたり、データそのものの有効性に
    疑問符が付くようでは本末転倒
    - Q : Real-User Monitoring用のJavaScriptを
    　　lazy load（遅延読込）できないか？
    - A : できはするけど、本当に？
    まず各ベンダが推奨するBest practiceにそって
    組み込もう
    影響の少ない組み込み方は？
    

    View Slide

82. 82
    まとめ
    

    View Slide

83. 83
    まとめ
    監視(Monitoring)は守りのためでなく、
    いまのシステム・サイトをより良くするためのもの
    本来の目的に注力するために、
    巨人の肩に積極的に乗りましょう
    ※弊社もお手伝いします！
    https://www.irasutoya.com/2019/01/blog-post_43.html
    

    View Slide

84. View Slide