AWSと監視SaaSの動向から探る監視（モニタリング）の「いま」

「入門『監視』」みなさん読まれましたか？　長くインフラ運用に携わっている方（僕です）は、読んで何かしらの違和感を感じたのではないでしょうか。 監視・運用を取り巻く環境の変化をふまえ、何を使って何をどう「監視」すれば良いのかを探ります。

Transcript

1. #akibaaws
2. "84ͱ؂ࢹ4BB4ͷಈ޲͔Β୳Δ
 ؂ࢹʢϞχλϦϯάʣͷʮ͍·ʯ 
   ",*#""84
   
   ؂ࢹ ϞχλϦϯά ฤ
3. 渡辺聖剛 ‣ʼ17/01⼊社 ‣AWS事業本部オペ部所属 ‣インターネット⽼⼈会 ‣前職までは所謂インフラエンジニア ‣汎⽤機(ʼ95~) -> ISP (Y2K~) -> SIer (~ʼ10) -> ⾃他社Web構築運⽤ ‣(特に)好きなAWSサービス ‣Route 53、AWS Systems Manager ࣗݾ঺հ
   
4. 19xx〜
    ‣ 汎⽤機（ダム端末 - 中央集権型） ‣ オープンシステム（UNIX + TCP/IP, CS型） ‣ インターネット（PC UNIX, x86） ‣ Web2.0（⾔語フレームワーク, モバイル） ‣ 4G(LTE) + スマートフォン ‣ クラウド（アプリ, インフラ）
5. 
    (PBM
6. ‣ 六本⽊のバーで「最近『監視』ってどうなの︖」と 聞かれた時に、適切なウンチクで返せるようになる こと Goal
    ※ը૾͸ΠϝʔδͰ͢
7. 
    ͸ͳ͢͜ͱ ‣ はなすこと（Agenda） ‣ はなさないこと
8. はなすこと（Agenda）
    ‣ そもそも「監視」って何さ︖ ‣ 監視される対象が変化している ‣ 監視する⽬的と価値も変化している ‣ 監視する側の⽴場と価値観も（ｒｙ ‣ それに合わせてツールも（ｒｙ ‣ いまどんなものがある︖
9. はなさないこと
    ‣ 特定ツール・サービス(SaaS)の使い⽅ ‣ 各サービス(SaaS)の星取り表的⽐較 ‣ 「このサービス(SaaS)を使えばok︕」 ‣ セキュリティに特化した話
10. 
     ͦ΋ͦ΋ʮ؂ࢹʯͬͯԿ͞ʁ ‣ 監視 vs monitoring
11. 「⼊⾨」︖
     ‣ ⼊⾨「監視」―モダンなモニタリングのためのデザインパターン ‣ @hamako9999 の記事 -> ‣ 原題 : Practical Monitoring: Effective Strategies for the Real World ‣ Practical = 実⽤的・実践的 ‣ “relating to real situations and events rather than ideas, emotions etc”（ロングマン現代英英辞典より） ‣ Effective = 効果的な （「⼊⾨」...? https://dev.classmethod.jp/cloud/aws/practial-monitoring-bookreview/
12. 監視︖ monitoring? (cont.)
     ‣ 監視のイメージ ‣ 監視カメラ ‣ モニタリングのイメージ ‣ ◦◦ウォッチング、モニタリング(観測・計測)ポスト 英語と⽇本語で⾔葉のイメージがずいぶんと違う →翻訳物を読むときに気をつけたいポイント →（…⾔語の違いだけだろうか︖）
13. 
     ʮ؂ࢹʯΛͱΓ·͘؀ڥͷมԽ ‣ 監視される対象 ‣ 監視する⽬的と価値 ‣ 監視する側の⽴場と価値観
14. 「F1に例えたら︖」
     ‣ 岡⽥良太郎（アスタリスク・リサーチ） ‣ hbstudy（主催・株式会社ハートビーツ） ‣ #87「Hardening に参加しよう︕」 ‣ 1:43:00〜 https://youtu.be/liPWCeB0lw0?t=6180 ‣ ハードニングというセキュリティイベントの話をしているとき
15. もしもシステムがF1だったら︖
     ‣ F1 = サーキット周回カーレース ‣ F1ドライバー、ピットクルー ‣ ピットではタイヤ交換、ガソリン補給、簡単なメンテなど ‣ ⾞(F1マシン)からピットへ常時データを送信（テレメトリ） ‣ ドライバーとクルーは無線でやりとり ‣ 規定の周回で速度を競う（完⾛しないとはじまらない） ‣ 年間20数戦、毎年あたらしい⾞で戦う https://commons.wikimedia.org/wiki/File:2011_Australian_GP_pit_lane.jpg
16. もしもシステムがF1だったら︖(cont.)
     ‣ とっさに考えた例え ‣ ⾞ +ドライバー = アプリケーション ‣ ピットクルー = 運⽤担当者 ‣ ⾞の製造 = 開発担当者 ‣ レース（サービス運⽤）はアプリが動作させる ‣ ⾞の調⼦はピットクルー（運⽤担当）が⾒る
17. もしもシステムがF1だったら︖(cont.)
     ‣ 岡⽥⽒の答え︓ ‣ ⾞ +ドライバー =Ops（運⽤担当者） ‣ ピットクルー = Dev（開発担当者） ‣ 運⽤して初めて価値が⽣まれる ‣ Ops「(⾞の調⼦の)何かがおかしい」 ‣ Dev(ピット) : タイヤ交換(etc.) -> 次の周回へ
18. もしもシステムがF1だったら︖(深掘り)
     ‣ ドライバー = Ops、ピットクルー = Dev ‣ ⾞のテレメトリ(メトリック)を ‣ ドライバー(Ops) = いまその⾞を⾛らせ続ける(運⽤)ために使う ‣ ピットクルー(Dev) = 次のピットストップ(deploy)でどんなケアを するかを判断する材料 ‣ OpsよりDevのほうに多く⾶んでくる ‣ DevとOpsが⼀緒になってレースを戦うのがDevOps
19. もしもシステムがF1だったら︖(再掲)
     ‣ とっさに考えた例え ‣ ⾞ +ドライバー = アプリケーション ‣ ピットクルー = 運⽤担当者 ‣ ⾞の製造 = 開発担当者 ‣ レース（サービス運⽤）はアプリが動作させる ‣ ⾞の調⼦はピットクルー（運⽤担当）が⾒る →（よく考えたら）ウォーターフォール的な考え⽅
20. 「DevOpsが正義」というわけではない
     ‣ 道具は環境にあわせて作られる（既製品は特に） ‣ これまでは : 主にウォーターフォール向け、Opsのために ‣ 最近のは : DevOps念頭、イテレーションを回すために ‣ 技術的進化は Dev・Ops どちらにも恩恵がある
21. DevOps時代のモニタリング
     ‣ DevOps時代において ‣ 「システムが動いて初めて価値を⽣む」(岡⽥⽒) ‣ メトリックを「次のイテレーション（周回）を回す判断材料として」取 得することが重要 ‣ 蓄積 -> 分析 ‣ ならば「アラート」とは︖ ‣ アラート : 何かしらの「好ましくない事態」を検知したことによる通知 ‣ アラート(通知)を受け取るのは誰だろう
22. 再掲 : 198x〜
     ‣ 汎⽤機（ダム端末 - 中央集権型） ‣ オープンシステム（UNIX + TCP/IP, CS型） ‣ インターネット（PC UNIX, x86） ‣ Web2.0（⾔語フレームワーク, モバイル） ‣ 4G(LTE) + スマートフォン ‣ クラウド（アプリ, インフラ）
23. 汎⽤機環境
     ‣ ダム端末、中央集権型 ‣ CUI ‣ ジョブの正常性監視 -> 異常終了時にアラート ‣ ハードウェアの⾒回り（⽬視） ‣ ⽇次〜の⾃⼰診断（diagnostics） ‣ ⽉次〜でAct/Std切り替え・定期メンテナンス
24. オープンシステム環境
     ‣ UNIX + TCP/IP, クライアント・サーバ型 ‣ OpenView/NMM (Network Node Manager) ‣ UNIXワークステーションによるGUI表⽰ ‣ X-Window System、Sun/Solaris、HP-UX、AIX ‣ ノード間の疎通確認、トラフィック監視 ‣ LoadAverageのミニグラフ(xload) https://ja.wikipedia.org/wiki/X_Window_System
25. インターネット環境
     ‣ UNIXからPC UNIX(FreeBSD,Linux)へ ‣ x86アーキテクチャ（32bit,64bit） ‣ NW・トラフィック : SNMP、MRTG ‣ ノード : BigBrother, Hobbit ‣ ブラウザベースのUI ‣ ⼿製の監視システム ‣ 外から⾒た監視の重要性（メール着信等） https://oss.oetiker.ch/mrtg/ https://nnc3.com/mags/LM10/Magazine/Archive/2008/92/022-024_hobbit/article.html
26. Web2.0環境の運⽤・モニタリング
     ‣ ⾔語フレームワーク（Ruby on Rails） ‣ モバイル（フィーチャーフォン） ‣ ビッグデータ（⼤量データの⾼速分析） ‣ WebAPI ‣ OSSツールの進化 ‣ MRTG -> RRDTool、Cacti ‣ BigBrother, Hobbit -> Zabbix ‣ NetSaint -> Nagios ‣ APM（Application Performance Management） ‣ Webアプリケーションの複雑化とパフォーマンスチューニングの必要性 ‣ NewRelic (2008〜)
27. ここ5年10年の運⽤・モニタリング
     ‣ LTE + スマフォ、⼤陸間/⼤帯域/⾼速/低遅延 通信 ‣ UI/UX、リッチコンテンツ ‣ 売り切りパッケージ -> スマフォアプリ・Webサービス ‣ 動画配信、インタラクティブコンテンツ（30fps↑ゲームコンテンツ） ‣ クラウドインフラ ‣ サーバ側 : Infrastructure as Code、コンテナ ‣ クライアント側 : マルチデバイス、IoT ‣ ML（機械学習による⼤容量データの準リアルタイム分析・予測）
28. 四半世紀の変化
     ‣ 需要（市場の要求）と供給（技術的な進歩） ‣ コンピュート能⼒の向上 ‣ インフラのソフトウェア化（Software-Defined anything[*1](SDx)、クラウドインフラ） ‣ ネットワークの⾼速化（⼤帯域、低遅延、CDNの⼤衆化） ‣ ストレージの低廉化 ‣ ソフトウェアアプリケーションの複雑化、UI/UXのリッチ化 ‣ 機械学習の⼤衆化 ‣ 速度の重要性が爆上がり（応答速度、開発速度） ‣ 「システムの継続性・堅牢性」より「ビジネスの継続性・堅牢性」 *1 : https://www.sbbit.jp/article/cont1/29935
29. ʮ୲౰ൣғʯͷมԽ
    YY
    
    YY
     -"/ αʔό
    )8 04 ϛυϧ
    ΢ΣΞ ΞϓϦέʔγϣϯ ϋʔυ΢ΣΞϚΠΫϩίʔυυϥΠό ιϑτ΢ΣΞ ϋʔυ΢ΣΞ Ծ૝)8
    4%Y
    
    ιϑτ΢ΣΞ ΞϓϦέʔγϣϯ ίϯςφ 04 ϛυϧ
    ΢ΣΞ σʔληϯλ
    ϑΝγϦςΟ ‣ 純粋なハードウェアの領域 の⼤部分がSDxに置き換え られる ‣ インフラのソフトウェア化 ‣ マネージドインフラ ‣ 純粋な「インフラ」担当の 領域とするより、アプリと ⼀体化して考えたほうが良 い傾向が強くなる ※オンプレが無くなった＿＿ ＿わけではない 'BB4
    Ϛωʔδυ
30. どこを何で監視（モニタリング）する︖
     ‣ ここ数10年程で⾒るべき場所と⽬的が変化している ‣ そのために使える技術も⾶躍的に進化している ‣ その時々で最適な道具と⼿法が使われてきた ‣ 10年前の常識で監視・モニタリングしてませんか︖ ‣ 監視される側の可観測性(Observability)はあがっている ‣ どこをどう監視すべきか、⼀番詳しいひとは誰だろう
31. 
     ʮϖοτͱՈசʯϞσϧʹ͓͚ΔϞχλϦϯά
32. CERN Data Centre Evolution
     ‣ Published on Nov 19, 2012 https://www.slideshare.net/gmccance/cern-data-centre-evolution#17
33. ‣ 家畜(cattle)モデル ‣ 1台1台は最低限 ‣ 全体のパフォーマンスを重視 「ペットと家畜」モデルにおけるモニタリング
     ‣ ペット(pet)モデル ‣ 1台1台のサーバから丁寧な メトリックを取得 http://www.tokyowest-ah.jp/medicals/sort_anesthetic.html https://www.titech.ac.jp/news/2019/043843.html
34. 「ペットと家畜」モデルにおけるモニタリング(cont.)
     ‣ クラウドインフラ=「H/Wを⻑持ちさせる」という 視点がない ‣ 100%までぶん回していい ‣ ⾃在にスケールアウト・スケールアップ -> 動いているこ とが⼤切 ‣ Design for failure ‣ その代わりの「従量課⾦」
35. 「ペットと家畜」モデルにおけるモニタリング(cont.)
     ‣ クラウドインフラ=「H/Wを⻑持ちさせる」という 視点がない ‣ 100%までぶん回していい -> 「とりあえず閾値90%」︖ ‣ ⾃在にスケールアウト・スケールアップ -> 動いているこ とが⼤切 ‣ Design for failure -> 1つ2つ落ちることは織り込み済み ‣ その代わりの「従量課⾦」-> 警告するべき視点の変化
36. ex) プロセスが落ちることとサーバが落ちることにどんな差が︖
     ‣ どちらも「サービスが継続出来なくなる」ことに変わりない ‣ 昔 -> OS再起動にコスト⼤ -> プロセスだけ再起動しよう ‣ ペット化されたインフラは個体差も⼤きく複雑 ‣ モノリシック、密結合 ‣ いま -> コンテナ作り直せば︖ ‣ IaC, Immutable Infrastructure ‣ マイクロサービス、疎結合
37. 
     ԿΛͲ͏ʮ؂ࢹʯ͢Δʁ ‣ 監視する項⽬ ‣ 監視する⽬的 ‣ 監視ツール
38. 何をモニタリングするか
     ‣ アプリケーションレイヤ ‣ APM,トレース ‣ インフラストラクチャレイヤ ‣ メトリック（Gauge, Counter） ‣ ログ ‣ 正規化されていない⽂字列データ ‣ パフォーマンス ‣ 外形監視(Synthetic), Apdex http://www.xtbg.ac.cn/ydhz/hzdt/201102/t20110225_3075706.html
39. 何をモニタリングするか(cont.)
     ‣ ⾼解像度(1s)・短期間(オンデマンド) ‣ 現在進⾏中の事象調査 ‣ ping、top系コマンド（htop, Glances）、netdata ‣ 中〜低解像度(1min〜1d)・中〜⻑期間(〜1y〜) ‣ 中⻑期的な傾向把握・将来予測、ふるまいの把握 ‣ ソリューション（オンプレ、SaaS）+ 式・機械学習 ‣ イベントドリブン ‣ 発⽣した事象の詳細・関連性調査 ‣ トレース・ログ解析
40. なんのために︖
     ‣ KPI ‣ パフォーマンス(応答速度)向上、チューニング ‣ UI/UX - A/Bテスト、ヒートマップ、滞在時間・離脱率 ‣ 可⽤性、「障害を起こさない」、セキュリティ ‣ リソース管理 - コスト効率の向上 ‣ 継続的なテスト ‣ チェック監視（正常な状態から外れていないか、という意味で） ※機能要件・⾮機能要件の境は曖昧
41. それからどうする︖
     ‣ ⾃動対応 ‣ 再起動、オートスケール、詳細情報の収集(gathering) ... ‣ 通知・エスカレーション ‣ 即時 -> ⼈間による即対応を促す ‣ 定期的レポーティング(〜⽇次、⽉次、年次) ‣ 記録のみ ‣ 将来的な利⽤
42. どうモニタリングする︖
     ‣ 式による監視、異常検知(ふるまい検知、外れ値検知) ‣ 代表値での監視 ‣ 時系列・関連付け ‣ ダッシュボード ‣ 監視SaaS / 運⽤SaaS ‣ ⾃動化(Automation)
43. 式による監視、異常検知(ふるまい検知、外れ値検知)
     ‣ 統計的⼿法、ML ‣ 個々の値に⼀喜⼀憂しない、全体傾向をみる ‣ S/N⽐の向上、認識補助 ‣ ノイズの除去、有意メトリックのふるい分け ‣ セキュリティインシデントの検知的な側⾯ ‣ ex) GuardDuty（これぞ「監視」って感じでは︖）
44. 代表値での監視
     ‣ 外形監視 - ネットワーク含めシステム全体の応答遅延 ‣ シングル、シナリオ ‣ 多拠点からの観測 -> クライアントアクセスをシミュレート ‣ Apdex - 応答速度の点から「顧客満⾜度」を図る ‣ https://newrelic.degica.com/docs/apm/new-relic-apm/apdex/ apdex-measuring-user-satisfaction ‣ LoadAverage - OS内I/O遅延 ‣ UNIX初期からある「システムのパフォーマンス」指標
45. ダッシュボード
     ‣ 複数要素の同時監視 ‣ システム横断、リソース横断、ログ＋メトリック ‣ エンジニアリングだけでなくビジネスレイヤでも ‣ KPI ‣ パフォーマンス
46. 監視SaaS / 運⽤SaaS
     ‣ 「監視システムのお守り」は業務ですか︖ ‣ 数の暴⼒を享受しよう ‣ ポイント ‣ メトリクスの保存期間 - シーズナル要因を⾒極めるための年単位、Max/Ave/中央値 ‣ 監視対象のグルーピング⽅式 - タグ付け、カテゴライズ、サービス/ロール ‣ 通知の柔軟性 - フラッピング抑制 ‣ ⾒た⽬、操作性 - ある意味もっとも重要︕ 毎⽇眺めたくなるものを ‣ 多⾓的な表⽰、分析機能、拡張性 etc.
47. 監視ソリューションにこだわらない監視
     ‣ 例 : IoT Bot の監視（re:Invent 2018 DEV311） ‣ 各IoTは定期的にステータスをDynamoDBにアップロード ‣ ステータスのアップデートが途絶えた = 死と判断する https://dev.classmethod.jp/cloud/aws/practial-monitoring-bookreview/
48. ⾃動化(Automation)
     ‣ ヘルスチェックは⽴派な監視 ‣ failoverは⽴派な⾃動運⽤ ‣ 「⾃動化は信⽤ならない」 ‣ 「信⽤出来るところに⾃動化を使う」「⾃動化出来ない部分は減ら していく」 ‣ 「なんでも⾃動化すればええんや」
49. 参考︓「運⽤⾃動化」とは
     ‣ 波⽥野裕⼀⽒ ‣ 運⽤設計ラボ合同会社所属 ‣ 「不都合な真実」で有名 ‣ もっと広い「運⽤⾃動化」につい ての提⾔ ‣ ぜひ⼀度ご⼀読を https://speakerdeck.com/opelab/20190306-operation-what-automation
50. 再掲 : 監視︖ monitoring?
     ‣ 監視のイメージ ‣ 監視カメラ ‣ モニタリングのイメージ ‣ ◦◦ウォッチング、モニタリング(観測・計測)ポスト
51. つまり
     ‣ むかし ‣ 1台1台が貴重、重い、できるだけ個々を⽌めないようにする、 リソースも⾼く有限だったのでピンポイント、監視コストが⾼い ‣ 監視するほうも、されるほうも ‣ 通信帯域が制限 = 監視対象にちかいところで監視 ‣ 通知⼿段も限定的(ポケベル、⾳声電話)、DCまで物理移動 ‣ 連絡を受けてひとが対応
52. つまり
     ‣ いま ‣ 無尽蔵のクラウドリソース、監視コストが低い、多量のデータ を素早く処理できる ‣ 監視するほうも、されるほうも ‣ 通信帯域が潤沢 = ネットワーク越しでいい -> SaaS ‣ インフラもクラウド、スマホで再起動やらスケールアップやら ‣ アラートを受けるのは⾃動化装置、報告のみ受け取る
53. AWS Well-Architected Framework 運⽤の優秀性
     ‣ 期待される成果を定義し（中略）正し く運⽤できているかどうかを判断する ために使われるシステムと運⽤に関す るメトリクスを特定 ‣ メトリクスを収集して分析（中略）顧 客やビジネスニーズを満たせているか を確認し、改善 ‣ メトリクスをビジネスニーズと整合さ せる（中略）⼀元化されていない⼿動 で取得されたメトリクスは、計画外の イベントが発⽣した際にシステムの運 ⽤を⼤きく妨げる結果につながります https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well-Architected_Framework_2018_JA_final.pdf https://d1.awsstatic.com/events/jp/2017/summit/slide/D2T1-1.pdf
54. 
     ؂ࢹ4BB4
    
    ӡ༻4BB4 ‣ 監視(monitoring)と運⽤(operation) ‣ pushとpull ‣  , 鯖, ⽝, 遺跡, 相撲 etc.
55. 監視(monitoring) ‣ AWS ‣ CloudWatch, X-Ray ... ‣ 汎⽤(網羅的)・インフラ寄り ‣ Datadog, Mackerel, Stackdriver ... ‣ 特定⽤途寄り ‣ NewRelic, sumoLogic, Pingdom ... ‣ 他にもセキュリティ向けなど 運⽤(operation) ‣ AWS ‣ Systems Manager (SSM), SNS ... ‣ 通知・通知⽀援 ‣ PagerDuty, Slack ... ‣ ⾃動化⽀援 ‣ Opsgenie, Turbot ... ざっくり
    
56. オレオレ監視システム
     ⼊⾨「監視」より抜粋︓ ‣ 2.3 デザインパターン3︓作るのではなく買う ‣ “ひと握りの企業はさらに⼤きくなり、ユニークな問題やニーズを満たすための独⾃の監視プラット フォームを構築します。Netflix、Dropbox、Twitterと⾔った企業は、このグループに属します。” ‣ “多くの点に関して、私は監視の SaaS ソリューションの⽀持者です。5 年間は悩む必要はなく SaaS を監視に使うべきだというのが私の考えです。” ‣ 2.3.1 安いから ‣ 2.3.2 あなたは（おそらく）監視ツールを設計する専⾨家ではないから ‣ 2.3.3 SaaS を使うとプロダクトにフォーカスできるから ‣ 2.3.4 実際のところ SaaS の⽅がよいから
57. push or pull
     ‣ 監視サーバ(マネージャ)と監視クライアント(エージェント)間の通信⽅法 ‣ push ... エージェント -> マネージャ ‣ pull ... マネージャ -> エージェント ‣ いわゆるポーリング ‣ 実際問題として、どちらかだけ、というものはない ‣ 例 1 ‣ 登録・メトリック送信は push / 死活や必要に応じてマネージャから pull ‣ 例 2 ‣ メトリックや死活判定は push / 登録はクラウドインフラのAPIから pull ‣ 例 3 ‣ ログは push / 外形監視は pull (polling) ‣ ※製品によっては「◦◦型」と謳っているものも
58. Amazon Web Services
     ‣ 純正の安⼼感と流⽯のAWS連携 ‣ CloudWatch ‣ metrics / Agent / Event / Alarm / Logs / Dashboards ‣ CW Logs Insights / Container Insights (New!) ‣ AWS X-Ray ‣ Amazon Route 53 Healthcheck ‣ HTTP/HTTPS接続監視からの CW Events発⽕ ‣ AWS Systems Manager, Lambda, SNS etc. https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/welcome-health-checks.html
59. Mackerel
     ‣ みんな⼤好き ‣ mackerel-agent / -container-agent, Agentプラグイン, check -> action ‣ AWSインテグレーションでCWメトリクス収集 ‣ 外形監視（L7） ‣ ダッシュボード ‣ 各種Webhook連携 ‣ 国産 ‣ シフト＆リフトのフェーズで使いやすい（偏⾒） ‣ インフラメトリクス監視に寄りがち
60. Datadog
     ‣ みんな⼤好き ‣ Infra, Metrics, 外形, APM, Trace, Logs, Dashboard ‣ AWSインテグレーション ‣ AWSと密接、莫⼤な開発リソース ‣ Infraから始まって網羅的に機能拡充中 ‣ 外形監視がこの3⽉にGA（API Test / Browser Test） ‣ APMもできる（こなれているかは︖ ‣ これから⽇本市場に⼒をいれていく（らしい
61. New Relic, Stackdriver
     ‣ New Relic ‣ APM, Analyze, Infrastructure, 外形, フロントエンド, リアルユーザ ‣ Apdexの発明元（パフォーマンス = 顧客満⾜度の指標） ‣ イベントドリブンからのドリルダウン（Stack trace, Server status） ‣ アプリ寄りの出⾃。ログはこれから ‣ Stackdriver ‣ いまはGoogle = GCPとの密接な連携 ‣ AWSインテグレーション(コネクタ) ‣ Monitoring, Logging, Error Reporting, Trace, Debugger
62. sumoLogic
     ‣ ログ解析重点 ‣ 「ログを収集・分析・可視化するSaaS」（弊社加藤・談） ‣ インポートしてしまえば強⼒な正規化・分析⽀援を施せる ‣ 別途収集のメトリックと時系列で並べられる ‣ コマンドラインで⾔えば top ではなく grep/sed/awk/sort や Perl・Ruby の代替 ‣ リアルタイムよりは分析で威⼒を発揮 ‣ 障害、セキュリティイシューの調査 ‣ 定期的なレポーティングやアラート設定も可能 ‣ OSSでいえば Elasticsearch + logstash + Kibana ‣ 対抗は Splunk https://dev.classmethod.jp/cloud/aws/jaws_days_2019_sumologic/
63. Pingdom
     ‣ 外形監視特化 ‣ Uptime Monitoring - 複数拠点からの死活監視 ‣ Performance / Real User Monitoring ‣ Transaction Monitoring ‣ Page speed Monitoring ‣ アラート通知、インフラ監視も ‣ Server monitor - StatsD, インテグレーション, ダッシュボード
64. 
     ·ͱΊ
65. まとめ
     ‣ 監視 or モニタリング ‣ 監視 -> 異常を⾒つけて通知することが主眼 ‣ モニタリング -> 定期的な計測、異常があったら対処 ‣ ⾃動対応 or 通知 ‣ 対象がかわったのでやり⽅もかわる ‣ SaaSの積極的な利⽤がコストダウンに繋がる ‣ なんとなしに始めるのは危険、⾼く付く可能性 ‣ まず計測から・無料枠からはじめよう︕