Save 37% off PRO during our Black Friday Sale! »

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

E39a62a5c1f1829cc6ce0ec642424947?s=47 Seigo Watanabe
May 30, 2019
1.7k

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

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

E39a62a5c1f1829cc6ce0ec642424947?s=128

Seigo Watanabe

May 30, 2019
Tweet

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)   ‣ そもそも「監視」って何さ︖ ‣ 監視される対象が変化している ‣ 監視する⽬的と価値も変化している ‣

    監視する側の⽴場と価値観も(ry ‣ それに合わせてツールも(ry ‣ いまどんなものがある︖
  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. ʮ୲౰ൣғʯͷมԽYYYY   -"/ αʔό )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の積極的な利⽤がコストダウンに繋がる ‣ なんとなしに始めるのは危険、⾼く付く可能性 ‣ まず計測から・無料枠からはじめよう︕
  66. None