Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

【15-B-7】無意味なアラートからの脱却 ~ Datadogを使ってモダンなモニタリングを始めよう ~

1,303 views

Published on

Developers Summit 2019【15-B-7】池山様の講演資料です。

Published in: Technology
  • Be the first to comment

【15-B-7】無意味なアラートからの脱却 ~ Datadogを使ってモダンなモニタリングを始めよう ~

  1. 1. 池山 邦彦 | Kunihiko Ikeyama Sales Engineer, Datadog kunihiko.ikeyama@datadog.com 無意味なアラートからの脱却 〜 Datadogを使ってモダンなモニタリングを始めよう 〜 #datadogJP
  2. 2. なぜアラートの嵐に埋もれるのか?
  3. 3. なぜアラートの嵐に埋もれるのか? ✔ 監視する必要のないものも通知設定している ✔ 通知する必要のない通知を飛ばしている ✔ 一つのインシデントで引きずられて発砲される通知がたくさんある ✔ 複数の条件が成立して初めて通知されるべき通知も個別に通知している
  4. 4. なぜアラートの嵐に埋もれるのか? ✔ 監視する必要のないものも通知設定している それ、監視する必要ある? ✔ 通知する必要のない通知を飛ばしている 別にその通知受け取る必要なくない? ✔ 一つのインシデントで引きずられて発砲される通知がたくさんある 過剰に通知設定してません? ✔ 複数の条件が成立して初めて通知されるべき通知も個別に通知している 通知の条件正しく設定してる?
  5. 5. $whoami 池山 邦彦(いけやま くにひこ) Sales Engineer, Datadog 2018年11月 Datadog入社 職務: プリセールスとして、モニタリングの素晴らしさを世に伝える仕事に 従事 なぜDatadogに入社したのか? - Datadog使いやすくて面白い! - 思ったより色んなことできて奥が深い - 犬のロゴかわいい
  6. 6. Datadogってナニ?
  7. 7. リアルタイムの パフォーマンス 可視化 What is Datadog クラウド時代の開発者 &運用担当者のためのモニタリング &分析SaaS 強力な アラート ダッシュボード公開や チーム間のコラボレーション 根本原因の 相関と分析 履歴の分析
  8. 8. レガシーなモニタリングツールではクラウド時代のスピードとペースに追いつけない プラットフォーム/サービス ユニット (VM, コンテナ, ファンクション) リリース頻度 人への投資 ごく少数の ベンダー 多数のOSSや SaaSの併用 年に1度 日に一度 Ops Dev + Ops Biz + Dev + Ops Standardized/On-Premise Diverse/SaaS Time ツールの数 インスタンス、コンテナ、 マイクロサービス等々 頻度 人へのニーズ 分散集中 Waterfall Agile IntegratedSilo’d Time Time
  9. 9. インフラ アーキテクチャ 開発サイクル スタック 関係者 モニタリング 集約 モノリス ウォーターフォール 標準化されたオンプレの ベンダーソフトウェ インフラ(管理者) 開発(参加者) 次世代 分散 マイクロサービス アジャイル 多種多様で導入しやすい OSSや SaaSコンポーネント 複数のインフラ・開発チーム レガシー
  10. 10. なぜモニタリング?
  11. 11. サービスダウンに伴う機会損失 サービスのSLOは? 99.9% → 年間8.76時間のダウンまで許容 99.99% → 年間0.876時間のダウンまで許容 1時間のサービスダウンで発生する機会損失額は? 100万ドル(約1億円) / 時間 の場合… 3時間のダウンでサラリーマンの生涯所得を上回る 3分間のダウンで5万ドルの損失 = 社員1人の年収 復旧にかかる平均回復時間(MTTR)は? 失われるのはお金だけ? - 社会的信用 - 顧客満足度 - リピート率 The Cost of Downtime for the Top US Ecommerce Sites https://www.gremlin.com/ecommerce-cost-of-downtime/ サービス稼働を可視化してコントロールすること 復旧を早めてリスクを最小化すること
  12. 12. システムの可視性における三本柱 MetricsTraces トレンドやパターンを把握 システムやミドルウェアの パフォーマンス 組み合わせや集計による分析 インシデントの調査 デバッグやトラブルシューティング イベントベース Items in Shopping Cart Logins Total Trips Ad Revenue Logs サービス間の原因特定 アプリケーションのスループット レイテンシ、エラー リクエストベース ビジネス 分析
  13. 13. Why Datadog 250以上のインテグレーション チームを跨いだコラボレーション セルフサービス、OOTB、Fast Time to Value メトリクス、イベント、 APM、ログの相関 機械学習を含むスケーラブルなプラットフォーム
  14. 14. クラウド時代のモニタリング そのポイントは?
  15. 15. ではなく Cattle, not pets ペット 家畜
  16. 16. Tag(タグ) メトリクスに付帯 key:value 形式で1個のメトリックに複数の タグを付与することが可能 フィルタリング/グルーピング サーバーやVM、コンテナをロール、データ センター、ゾーンごとに分析可能に カスタマイズ可能 エージェント設定ファイル、 UI、インテグレーション 等々、自身でタグの付与が可能 タグごとのモニタリング・分析
  17. 17. モニタリングのポイント モニタリング対象について考えてみよう ワークメトリクス リソースメトリクス イベント APM ログ
  18. 18. モニタリングのポイント モニタリング対象について考えてみよう ワークメトリクス リソースメトリクス イベント APM ログ スループット(throughput) 単位時間あたりの処理量(通常は絶対値で表現される) 例)秒間HTTPリクエスト数/秒間DBクエリー数 成功(success) 成功した処理のパーセンテージ 例)HTTPステータス2xxの割合/成功したDBクエリーの割合 失敗(error) 失敗した処理のパーセンテージ 例)HTTPステータス5xxの割合/例外処理が発生したクエリーの割合 パフォーマンス(performance) 処理が完了するまでに要する時間といった効率 例)99%のリクエストが0.1秒以内にレスポンスされる/   クエリー時間の90パーセンタイル値
  19. 19. モニタリングのポイント モニタリング対象について考えてみよう ワークメトリクス リソースメトリクス イベント APM ログ 使用率(utilization) リソースがビジー状態になる時間の割合、もしくは、 リソースが使用されているキャパシティの割合 例)ビジー状態のディスクI/Oの時間%/合計メモリに対する使用% 飽和度(saturation) 処理しきれないリクエスト量 例)メモリのスワップ量/キューに溜まっているDBクエリー数 失敗(error) 処理そのものからは見えない内部エラー 例)ディスクデバイスエラー数/DBレプリケーションエラー数 可用性(availability) リソースがリクエストに応答可能な状態となっている時間の割合 定期的にチェックされている場合のみ観測可能 例)ディスク読み書き可能な時間%/DBにアクセス可能な時間%
  20. 20. モニタリングのポイント モニタリング対象について考えてみよう ワークメトリクス リソースメトリクス イベント APM ログ メトリクスとは別にシステムの変更といった重要な通知を イベントとして記録する 頻度としてはメトリクスほどではないが原因究明につながる 情報を含むことがある 変更(changes) コード変更のリリースやビルド、パッチ適用 等々 アラート(alerts) 生成されたアラートや3rd Party製品の通知 スケーリング(scaling events) サーバーやコンテナの追加/停止
  21. 21. モニタリングのポイント モニタリング対象について考えてみよう ワークメトリクス リソースメトリクス イベント APM ログ アプリケーション開発とインフラ運用の統合 DevOpsのチーム体制やインフラの変化(オートスケール、マイクロ サービス、コンテナ化)に伴いフルスタックでのモニタリングが必要と なった - アプリケーションのスループット、エラー、レイテンシ - トランザクションのトレーサビリティ - サービスマップ
  22. 22. Datadog APMの特長 - 関数やメソッドごとのパフォーマンスやエラーのトレースを 簡単な設定で取得可能 - メトリクスやログとのシームレスな相関をGUIで実現 - マイクロサービスの分散トレーシングも可能 - OpenTracingにも対応 - 対応言語: Python / Ruby / Go / Java / Node.js / .NET / PHP https://docs.datadoghq.com/tracing/languages/
  23. 23. 詳細な原因や傾向を分析 アプリケーションのデバッグ情報やシステムの挙動を記録したログを、 メトリクスやトレース情報と相関付けることで原因の検索/分析ワーク フローを簡素化 アプリケーショントレース との相関 ログパターン分析 モニタリングのポイント モニタリング対象について考えてみよう ワークメトリクス リソースメトリクス イベント APM ログ
  24. 24. Datadogでモニタリングしてみよう
  25. 25. アラートの種類 緊急性に応じて3段階のレベルでアラートを使い分ける データベースのクエリーレスポンスが遅くなってきているが サービス全体のレスポンスに影響するほどではない 記録する(Record) - 緊急度:低 誰かに知らせる必要がなく、モニタリングシステムに記録するだけ ディスクスペースが逼迫してきているので数日以内での対応 が必要 通知する(Notification) - 緊急度:中 すぐに対応が必要ではないが、誰かが対応できるようにメールや チャットで知らせる レスポンス時間がSLAに抵触するほど遅延している 呼び出す(Page) - 緊急度:高 他の仕事や私用を中断してでも対応が必要なものを、担当者に直接 連絡して呼び出す
  26. 26. Datadogでのモニタリングとアラート
  27. 27. モニタリングの種類 閾値 異常検知(Anomaly) 外れ値(Outlier) 予測(Forecast) ログ APM 複合条件 And others...
  28. 28. UIから簡単にセルフインストール可能 さまざまな3rd Partyツールとの連携 - Slack - PagerDuty - JIRA - Webhook - ServiceNOW - etc モニターごとに個別に連携先を指定可能 アラートワークフローで役に立つ豊富なインテグレーション
  29. 29. Synthetics - 外形監視 サービスを外側から監視 複数の拠点から任意のサイトや APIエンドポイントに HTTP(S)リクエストを送信して監視 クライテリアとしてステータスコード、レスポンス時間、 ヘッダ等の指定が可能 モニター対象として通知したり、稼働状況をダッシュ ボードで可視化することが可能 プライベートベータ( 2019年2月現在)
  30. 30. Uptime Widget
  31. 31. Demo
  32. 32. お試しください 14日間のフリートライアルにサインアップ!
  33. 33. 2月23日(土) JAWS Days 2019 [Lunch Session] クラウド時代のモニタリングといえば Datadogだよね https://jawsdays2019.jaws-ug.jp/session/1112/ 2月28日(木) Datadog Meetup #2 in 大阪 Datadogはじめました! in 大阪 https://datadog.connpass.com/event/119412/ 3月20日(水) Datadog CTO来日講演 w/AWS(仮) 4月9日(火)、10日(水) DevOps Days Tokyo 2019 告知
  34. 34. Let’s explore monitoring in the cloud age
  35. 35. Thank you

×