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

#akibaaws

"84ͱ؂ࢹ4BB4ͷಈ޲͔Β୳Δ  ؂ࢹʢϞχλϦϯάʣͷʮ͍·ʯ ",*#""84؂ࢹ ϞχλϦϯά ฤ

渡辺聖剛 ‣ʼ17/01⼊社 ‣AWS事業本部オペ部所属 ‣インターネット⽼⼈会 ‣前職までは所謂インフラエンジニア ‣汎⽤機(ʼ95~) -> ISP (Y2K~) ->
SIer (~ʼ10) -> ⾃他社Web構築運⽤ ‣(特に)好きなAWSサービス ‣Route 53、AWS Systems Manager ࣗݾ঺հ

19xx〜 ‣ 汎⽤機（ダム端末 - 中央集権型） ‣ オープンシステム（UNIX +
TCP/IP, CS型） ‣ インターネット（PC UNIX, x86） ‣ Web2.0（⾔語フレームワーク, モバイル） ‣ 4G(LTE) + スマートフォン ‣ クラウド（アプリ, インフラ）

‣ 六本⽊のバーで「最近『監視』ってどうなの︖」と聞かれた時に、適切なウンチクで返せるようになること Goal ※ը૾͸ΠϝʔδͰ͢

͸ͳ͢͜ͱ ‣ はなすこと（Agenda） ‣ はなさないこと

はなすこと（Agenda） ‣ そもそも「監視」って何さ︖ ‣ 監視される対象が変化している ‣ 監視する⽬的と価値も変化している ‣
監視する側の⽴場と価値観も（ｒｙ ‣ それに合わせてツールも（ｒｙ ‣ いまどんなものがある︖

はなさないこと ‣ 特定ツール・サービス(SaaS)の使い⽅ ‣ 各サービス(SaaS)の星取り表的⽐較 ‣ 「このサービス(SaaS)を使えばok︕」 ‣
セキュリティに特化した話

ͦ΋ͦ΋ʮ؂ࢹʯͬͯԿ͞ʁ ‣ 監視 vs monitoring

「⼊⾨」︖ ‣ ⼊⾨「監視」―モダンなモニタリングのためのデザインパターン ‣ @hamako9999 の記事 -> ‣
原題 : Practical Monitoring: Eﬀective Strategies for the Real World ‣ Practical = 実⽤的・実践的 ‣ “relating to real situations and events rather than ideas, emotions etc”（ロングマン現代英英辞典より） ‣ Eﬀective = 効果的な（「⼊⾨」...? https://dev.classmethod.jp/cloud/aws/practial-monitoring-bookreview/

監視︖ monitoring? (cont.) ‣ 監視のイメージ ‣ 監視カメラ ‣
モニタリングのイメージ ‣ ◦◦ウォッチング、モニタリング(観測・計測)ポスト英語と⽇本語で⾔葉のイメージがずいぶんと違う →翻訳物を読むときに気をつけたいポイント →（…⾔語の違いだけだろうか︖）

ʮ؂ࢹʯΛͱΓ·͘؀ڥͷมԽ ‣ 監視される対象 ‣ 監視する⽬的と価値 ‣ 監視する側の⽴場と価値観

「F1に例えたら︖」 ‣ 岡⽥良太郎（アスタリスク・リサーチ） ‣ hbstudy（主催・株式会社ハートビーツ） ‣ #87「Hardening に参加しよう︕」
‣ 1:43:00〜 https://youtu.be/liPWCeB0lw0?t=6180 ‣ ハードニングというセキュリティイベントの話をしているとき

もしもシステムがF1だったら︖ ‣ F1 = サーキット周回カーレース ‣ F1ドライバー、ピットクルー ‣
ピットではタイヤ交換、ガソリン補給、簡単なメンテなど ‣ ⾞(F1マシン)からピットへ常時データを送信（テレメトリ） ‣ ドライバーとクルーは無線でやりとり ‣ 規定の周回で速度を競う（完⾛しないとはじまらない） ‣ 年間20数戦、毎年あたらしい⾞で戦う https://commons.wikimedia.org/wiki/File:2011_Australian_GP_pit_lane.jpg

もしもシステムがF1だったら︖(cont.) ‣ とっさに考えた例え ‣ ⾞ +ドライバー = アプリケーション
‣ ピットクルー = 運⽤担当者 ‣ ⾞の製造 = 開発担当者 ‣ レース（サービス運⽤）はアプリが動作させる ‣ ⾞の調⼦はピットクルー（運⽤担当）が⾒る

もしもシステムがF1だったら︖(cont.) ‣ 岡⽥⽒の答え︓ ‣ ⾞ +ドライバー =Ops（運⽤担当者） ‣
ピットクルー = Dev（開発担当者） ‣ 運⽤して初めて価値が⽣まれる ‣ Ops「(⾞の調⼦の)何かがおかしい」 ‣ Dev(ピット) : タイヤ交換(etc.) -> 次の周回へ

もしもシステムがF1だったら︖(深掘り) ‣ ドライバー = Ops、ピットクルー = Dev ‣
⾞のテレメトリ(メトリック)を ‣ ドライバー(Ops) = いまその⾞を⾛らせ続ける(運⽤)ために使う ‣ ピットクルー(Dev) = 次のピットストップ(deploy)でどんなケアをするかを判断する材料 ‣ OpsよりDevのほうに多く⾶んでくる ‣ DevとOpsが⼀緒になってレースを戦うのがDevOps

もしもシステムがF1だったら︖(再掲) ‣ とっさに考えた例え ‣ ⾞ +ドライバー = アプリケーション
‣ ピットクルー = 運⽤担当者 ‣ ⾞の製造 = 開発担当者 ‣ レース（サービス運⽤）はアプリが動作させる ‣ ⾞の調⼦はピットクルー（運⽤担当）が⾒る →（よく考えたら）ウォーターフォール的な考え⽅

「DevOpsが正義」というわけではない ‣ 道具は環境にあわせて作られる（既製品は特に） ‣ これまでは : 主にウォーターフォール向け、Opsのために ‣
最近のは : DevOps念頭、イテレーションを回すために ‣ 技術的進化は Dev・Ops どちらにも恩恵がある

DevOps時代のモニタリング ‣ DevOps時代において ‣ 「システムが動いて初めて価値を⽣む」(岡⽥⽒) ‣ メトリックを「次のイテレーション（周回）を回す判断材料として」取得することが重要
‣ 蓄積 -> 分析 ‣ ならば「アラート」とは︖ ‣ アラート : 何かしらの「好ましくない事態」を検知したことによる通知 ‣ アラート(通知)を受け取るのは誰だろう

再掲 : 198x〜 ‣ 汎⽤機（ダム端末 - 中央集権型） ‣
オープンシステム（UNIX + TCP/IP, CS型） ‣ インターネット（PC UNIX, x86） ‣ Web2.0（⾔語フレームワーク, モバイル） ‣ 4G(LTE) + スマートフォン ‣ クラウド（アプリ, インフラ）

汎⽤機環境 ‣ ダム端末、中央集権型 ‣ CUI ‣ ジョブの正常性監視 ->
異常終了時にアラート ‣ ハードウェアの⾒回り（⽬視） ‣ ⽇次〜の⾃⼰診断（diagnostics） ‣ ⽉次〜でAct/Std切り替え・定期メンテナンス

オープンシステム環境 ‣ 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

インターネット環境 ‣ 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

Web2.0環境の運⽤・モニタリング ‣ ⾔語フレームワーク（Ruby on Rails） ‣ モバイル（フィーチャーフォン） ‣
ビッグデータ（⼤量データの⾼速分析） ‣ WebAPI ‣ OSSツールの進化 ‣ MRTG -> RRDTool、Cacti ‣ BigBrother, Hobbit -> Zabbix ‣ NetSaint -> Nagios ‣ APM（Application Performance Management） ‣ Webアプリケーションの複雑化とパフォーマンスチューニングの必要性 ‣ NewRelic (2008〜)

ここ5年10年の運⽤・モニタリング ‣ LTE + スマフォ、⼤陸間/⼤帯域/⾼速/低遅延通信 ‣ UI/UX、リッチコンテンツ
‣ 売り切りパッケージ -> スマフォアプリ・Webサービス ‣ 動画配信、インタラクティブコンテンツ（30fps↑ゲームコンテンツ） ‣ クラウドインフラ ‣ サーバ側 : Infrastructure as Code、コンテナ ‣ クライアント側 : マルチデバイス、IoT ‣ ML（機械学習による⼤容量データの準リアルタイム分析・予測）

四半世紀の変化 ‣ 需要（市場の要求）と供給（技術的な進歩） ‣ コンピュート能⼒の向上 ‣ インフラのソフトウェア化（Software-Deﬁned anything[*1](SDx)、クラウドインフラ）
‣ ネットワークの⾼速化（⼤帯域、低遅延、CDNの⼤衆化） ‣ ストレージの低廉化 ‣ ソフトウェアアプリケーションの複雑化、UI/UXのリッチ化 ‣ 機械学習の⼤衆化 ‣ 速度の重要性が爆上がり（応答速度、開発速度） ‣ 「システムの継続性・堅牢性」より「ビジネスの継続性・堅牢性」 *1 : https://www.sbbit.jp/article/cont1/29935

ʮ୲౰ൣғʯͷมԽYYYY -"/ αʔό )8 04 ϛυϧ ΢ΣΞ ΞϓϦέʔγϣϯ
ϋʔυ΢ΣΞϚΠΫϩίʔυυϥΠό ιϑτ΢ΣΞ ϋʔυ΢ΣΞ Ծ૝)8 4%Y ιϑτ΢ΣΞ ΞϓϦέʔγϣϯ ίϯςφ 04 ϛυϧ ΢ΣΞ σʔληϯλ ϑΝγϦςΟ ‣ 純粋なハードウェアの領域の⼤部分がSDxに置き換えられる ‣ インフラのソフトウェア化 ‣ マネージドインフラ ‣ 純粋な「インフラ」担当の領域とするより、アプリと⼀体化して考えたほうが良い傾向が強くなる ※オンプレが無くなった＿＿＿わけではない 'BB4 Ϛωʔδυ

どこを何で監視（モニタリング）する︖ ‣ ここ数10年程で⾒るべき場所と⽬的が変化している ‣ そのために使える技術も⾶躍的に進化している ‣ その時々で最適な道具と⼿法が使われてきた ‣
10年前の常識で監視・モニタリングしてませんか︖ ‣ 監視される側の可観測性(Observability)はあがっている ‣ どこをどう監視すべきか、⼀番詳しいひとは誰だろう

ʮϖοτͱՈசʯϞσϧʹ͓͚ΔϞχλϦϯά

CERN Data Centre Evolution ‣ Published on Nov
19, 2012 https://www.slideshare.net/gmccance/cern-data-centre-evolution#17

‣ 家畜(cattle)モデル ‣ 1台1台は最低限 ‣ 全体のパフォーマンスを重視「ペットと家畜」モデルにおけるモニタリング ‣
ペット(pet)モデル ‣ 1台1台のサーバから丁寧なメトリックを取得 http://www.tokyowest-ah.jp/medicals/sort_anesthetic.html https://www.titech.ac.jp/news/2019/043843.html

「ペットと家畜」モデルにおけるモニタリング(cont.) ‣ クラウドインフラ=「H/Wを⻑持ちさせる」という視点がない ‣ 100%までぶん回していい ‣ ⾃在にスケールアウト・スケールアップ
-> 動いていることが⼤切 ‣ Design for failure ‣ その代わりの「従量課⾦」

「ペットと家畜」モデルにおけるモニタリング(cont.) ‣ クラウドインフラ=「H/Wを⻑持ちさせる」という視点がない ‣ 100%までぶん回していい -> 「とりあえず閾値90%」︖
‣ ⾃在にスケールアウト・スケールアップ -> 動いていることが⼤切 ‣ Design for failure -> 1つ2つ落ちることは織り込み済み ‣ その代わりの「従量課⾦」-> 警告するべき視点の変化

ex) プロセスが落ちることとサーバが落ちることにどんな差が︖ ‣ どちらも「サービスが継続出来なくなる」ことに変わりない ‣ 昔 -> OS再起動にコスト⼤
-> プロセスだけ再起動しよう ‣ ペット化されたインフラは個体差も⼤きく複雑 ‣ モノリシック、密結合 ‣ いま -> コンテナ作り直せば︖ ‣ IaC, Immutable Infrastructure ‣ マイクロサービス、疎結合

ԿΛͲ͏ʮ؂ࢹʯ͢Δʁ ‣ 監視する項⽬ ‣ 監視する⽬的 ‣ 監視ツール

何をモニタリングするか ‣ アプリケーションレイヤ ‣ APM,トレース ‣ インフラストラクチャレイヤ ‣
メトリック（Gauge, Counter） ‣ ログ ‣ 正規化されていない⽂字列データ ‣ パフォーマンス ‣ 外形監視(Synthetic), Apdex http://www.xtbg.ac.cn/ydhz/hzdt/201102/t20110225_3075706.html

何をモニタリングするか(cont.) ‣ ⾼解像度(1s)・短期間(オンデマンド) ‣ 現在進⾏中の事象調査 ‣ ping、top系コマンド（htop, Glances）、netdata
‣ 中〜低解像度(1min〜1d)・中〜⻑期間(〜1y〜) ‣ 中⻑期的な傾向把握・将来予測、ふるまいの把握 ‣ ソリューション（オンプレ、SaaS）+ 式・機械学習 ‣ イベントドリブン ‣ 発⽣した事象の詳細・関連性調査 ‣ トレース・ログ解析

なんのために︖ ‣ KPI ‣ パフォーマンス(応答速度)向上、チューニング ‣ UI/UX -
A/Bテスト、ヒートマップ、滞在時間・離脱率 ‣ 可⽤性、「障害を起こさない」、セキュリティ ‣ リソース管理 - コスト効率の向上 ‣ 継続的なテスト ‣ チェック監視（正常な状態から外れていないか、という意味で） ※機能要件・⾮機能要件の境は曖昧

それからどうする︖ ‣ ⾃動対応 ‣ 再起動、オートスケール、詳細情報の収集(gathering) ... ‣ 通知・エスカレーション
‣ 即時 -> ⼈間による即対応を促す ‣ 定期的レポーティング(〜⽇次、⽉次、年次) ‣ 記録のみ ‣ 将来的な利⽤

どうモニタリングする︖ ‣ 式による監視、異常検知(ふるまい検知、外れ値検知) ‣ 代表値での監視 ‣ 時系列・関連付け ‣
ダッシュボード ‣ 監視SaaS / 運⽤SaaS ‣ ⾃動化(Automation)

式による監視、異常検知(ふるまい検知、外れ値検知) ‣ 統計的⼿法、ML ‣ 個々の値に⼀喜⼀憂しない、全体傾向をみる ‣ S/N⽐の向上、認識補助 ‣
ノイズの除去、有意メトリックのふるい分け ‣ セキュリティインシデントの検知的な側⾯ ‣ ex) GuardDuty（これぞ「監視」って感じでは︖）

代表値での監視 ‣ 外形監視 - ネットワーク含めシステム全体の応答遅延 ‣ シングル、シナリオ ‣
多拠点からの観測 -> クライアントアクセスをシミュレート ‣ Apdex - 応答速度の点から「顧客満⾜度」を図る ‣ https://newrelic.degica.com/docs/apm/new-relic-apm/apdex/ apdex-measuring-user-satisfaction ‣ LoadAverage - OS内I/O遅延 ‣ UNIX初期からある「システムのパフォーマンス」指標

ダッシュボード ‣ 複数要素の同時監視 ‣ システム横断、リソース横断、ログ＋メトリック ‣ エンジニアリングだけでなくビジネスレイヤでも ‣
KPI ‣ パフォーマンス

監視SaaS / 運⽤SaaS ‣ 「監視システムのお守り」は業務ですか︖ ‣ 数の暴⼒を享受しよう ‣
ポイント ‣ メトリクスの保存期間 - シーズナル要因を⾒極めるための年単位、Max/Ave/中央値 ‣ 監視対象のグルーピング⽅式 - タグ付け、カテゴライズ、サービス/ロール ‣ 通知の柔軟性 - フラッピング抑制 ‣ ⾒た⽬、操作性 - ある意味もっとも重要︕ 毎⽇眺めたくなるものを ‣ 多⾓的な表⽰、分析機能、拡張性 etc.

監視ソリューションにこだわらない監視 ‣ 例 : IoT Bot の監視（re:Invent 2018
DEV311） ‣ 各IoTは定期的にステータスをDynamoDBにアップロード ‣ ステータスのアップデートが途絶えた = 死と判断する https://dev.classmethod.jp/cloud/aws/practial-monitoring-bookreview/

⾃動化(Automation) ‣ ヘルスチェックは⽴派な監視 ‣ failoverは⽴派な⾃動運⽤ ‣ 「⾃動化は信⽤ならない」 ‣
「信⽤出来るところに⾃動化を使う」「⾃動化出来ない部分は減らしていく」 ‣ 「なんでも⾃動化すればええんや」

参考︓「運⽤⾃動化」とは ‣ 波⽥野裕⼀⽒ ‣ 運⽤設計ラボ合同会社所属 ‣ 「不都合な真実」で有名 ‣
もっと広い「運⽤⾃動化」についての提⾔ ‣ ぜひ⼀度ご⼀読を https://speakerdeck.com/opelab/20190306-operation-what-automation

再掲 : 監視︖ monitoring? ‣ 監視のイメージ ‣ 監視カメラ
‣ モニタリングのイメージ ‣ ◦◦ウォッチング、モニタリング(観測・計測)ポスト

つまり ‣ むかし ‣ 1台1台が貴重、重い、できるだけ個々を⽌めないようにする、リソースも⾼く有限だったのでピンポイント、監視コストが⾼い ‣ 監視するほうも、されるほうも
‣ 通信帯域が制限 = 監視対象にちかいところで監視 ‣ 通知⼿段も限定的(ポケベル、⾳声電話)、DCまで物理移動 ‣ 連絡を受けてひとが対応

つまり ‣ いま ‣ 無尽蔵のクラウドリソース、監視コストが低い、多量のデータを素早く処理できる ‣ 監視するほうも、されるほうも
‣ 通信帯域が潤沢 = ネットワーク越しでいい -> SaaS ‣ インフラもクラウド、スマホで再起動やらスケールアップやら ‣ アラートを受けるのは⾃動化装置、報告のみ受け取る

AWS Well-Architected Framework 運⽤の優秀性 ‣ 期待される成果を定義し（中略）正しく運⽤できているかどうかを判断するために使われるシステムと運⽤に関す
るメトリクスを特定 ‣ メトリクスを収集して分析（中略）顧客やビジネスニーズを満たせているかを確認し、改善 ‣ メトリクスをビジネスニーズと整合させる（中略）⼀元化されていない⼿動で取得されたメトリクスは、計画外のイベントが発⽣した際にシステムの運⽤を⼤きく妨げる結果につながります https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well-Architected_Framework_2018_JA_ﬁnal.pdf https://d1.awsstatic.com/events/jp/2017/summit/slide/D2T1-1.pdf

؂ࢹ4BB4ӡ༻4BB4 ‣ 監視(monitoring)と運⽤(operation) ‣ pushとpull ‣ , 鯖,
⽝, 遺跡, 相撲 etc.

監視(monitoring) ‣ AWS ‣ CloudWatch, X-Ray ... ‣ 汎⽤(網羅的)・インフラ寄り ‣
Datadog, Mackerel, Stackdriver ... ‣ 特定⽤途寄り ‣ NewRelic, sumoLogic, Pingdom ... ‣ 他にもセキュリティ向けなど運⽤(operation) ‣ AWS ‣ Systems Manager (SSM), SNS ... ‣ 通知・通知⽀援 ‣ PagerDuty, Slack ... ‣ ⾃動化⽀援 ‣ Opsgenie, Turbot ... ざっくり

オレオレ監視システム⼊⾨「監視」より抜粋︓ ‣ 2.3 デザインパターン3︓作るのではなく買う ‣ “ひと握りの企業はさらに⼤きくなり、ユニークな問題やニーズを満たすための独⾃の監視プラットフォームを構築します。Netﬂix、Dropbox、Twitterと⾔った企業は、このグループに属します。” ‣
“多くの点に関して、私は監視の SaaS ソリューションの⽀持者です。5 年間は悩む必要はなく SaaS を監視に使うべきだというのが私の考えです。” ‣ 2.3.1 安いから ‣ 2.3.2 あなたは（おそらく）監視ツールを設計する専⾨家ではないから ‣ 2.3.3 SaaS を使うとプロダクトにフォーカスできるから ‣ 2.3.4 実際のところ SaaS の⽅がよいから

push or pull ‣ 監視サーバ(マネージャ)と監視クライアント(エージェント)間の通信⽅法 ‣ push ...
エージェント -> マネージャ ‣ pull ... マネージャ -> エージェント ‣ いわゆるポーリング ‣ 実際問題として、どちらかだけ、というものはない ‣ 例 1 ‣ 登録・メトリック送信は push / 死活や必要に応じてマネージャから pull ‣ 例 2 ‣ メトリックや死活判定は push / 登録はクラウドインフラのAPIから pull ‣ 例 3 ‣ ログは push / 外形監視は pull (polling) ‣ ※製品によっては「◦◦型」と謳っているものも

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

Mackerel ‣ みんな⼤好き ‣ mackerel-agent / -container-agent, Agentプラグイン,
check -> action ‣ AWSインテグレーションでCWメトリクス収集 ‣ 外形監視（L7） ‣ ダッシュボード ‣ 各種Webhook連携 ‣ 国産 ‣ シフト＆リフトのフェーズで使いやすい（偏⾒） ‣ インフラメトリクス監視に寄りがち

Datadog ‣ みんな⼤好き ‣ Infra, Metrics, 外形, APM,
Trace, Logs, Dashboard ‣ AWSインテグレーション ‣ AWSと密接、莫⼤な開発リソース ‣ Infraから始まって網羅的に機能拡充中 ‣ 外形監視がこの3⽉にGA（API Test / Browser Test） ‣ APMもできる（こなれているかは︖ ‣ これから⽇本市場に⼒をいれていく（らしい

New Relic, Stackdriver ‣ New Relic ‣ APM,
Analyze, Infrastructure, 外形, フロントエンド, リアルユーザ ‣ Apdexの発明元（パフォーマンス = 顧客満⾜度の指標） ‣ イベントドリブンからのドリルダウン（Stack trace, Server status） ‣ アプリ寄りの出⾃。ログはこれから ‣ Stackdriver ‣ いまはGoogle = GCPとの密接な連携 ‣ AWSインテグレーション(コネクタ) ‣ Monitoring, Logging, Error Reporting, Trace, Debugger

sumoLogic ‣ ログ解析重点 ‣ 「ログを収集・分析・可視化するSaaS」（弊社加藤・談） ‣ インポートしてしまえば強⼒な正規化・分析⽀援を施せる ‣
別途収集のメトリックと時系列で並べられる ‣ コマンドラインで⾔えば top ではなく grep/sed/awk/sort や Perl・Ruby の代替 ‣ リアルタイムよりは分析で威⼒を発揮 ‣ 障害、セキュリティイシューの調査 ‣ 定期的なレポーティングやアラート設定も可能 ‣ OSSでいえば Elasticsearch + logstash + Kibana ‣ 対抗は Splunk https://dev.classmethod.jp/cloud/aws/jaws_days_2019_sumologic/

Pingdom ‣ 外形監視特化 ‣ Uptime Monitoring - 複数拠点からの死活監視
‣ Performance / Real User Monitoring ‣ Transaction Monitoring ‣ Page speed Monitoring ‣ アラート通知、インフラ監視も ‣ Server monitor - StatsD, インテグレーション, ダッシュボード

·ͱΊ

まとめ ‣ 監視 or モニタリング ‣ 監視 ->
異常を⾒つけて通知することが主眼 ‣ モニタリング -> 定期的な計測、異常があったら対処 ‣ ⾃動対応 or 通知 ‣ 対象がかわったのでやり⽅もかわる ‣ SaaSの積極的な利⽤がコストダウンに繋がる ‣ なんとなしに始めるのは危険、⾼く付く可能性 ‣ まず計測から・無料枠からはじめよう︕

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

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

More Decks by Seigo Watanabe

Featured

Transcript