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

1. 池山 邦彦 | Kunihiko Ikeyama
Sales Engineer, Datadog
kunihiko.ikeyama@datadog.com
無意味なアラートからの脱却
〜 Datadogを使ってモダンなモニタリングを始めよう 〜
#datadogJP

2. なぜアラートの嵐に埋もれるのか？

3. なぜアラートの嵐に埋もれるのか？
✔ 監視する必要のないものも通知設定している
✔ 通知する必要のない通知を飛ばしている
✔ 一つのインシデントで引きずられて発砲される通知がたくさんある
✔ 複数の条件が成立して初めて通知されるべき通知も個別に通知している

4. なぜアラートの嵐に埋もれるのか？
✔ 監視する必要のないものも通知設定している
それ、監視する必要ある？
✔ 通知する必要のない通知を飛ばしている
別にその通知受け取る必要なくない？
✔ 一つのインシデントで引きずられて発砲される通知がたくさんある
過剰に通知設定してません？
✔ 複数の条件が成立して初めて通知されるべき通知も個別に通知している
通知の条件正しく設定してる？

5. $whoami
池山 邦彦（いけやま くにひこ）
Sales Engineer, Datadog
2018年11月 Datadog入社
職務：
プリセールスとして、モニタリングの素晴らしさを世に伝える仕事に
従事
なぜDatadogに入社したのか？
- Datadog使いやすくて面白い！
- 思ったより色んなことできて奥が深い
- 犬のロゴかわいい

6. Datadogってナニ？

7. リアルタイムの
パフォーマンス
可視化
What is Datadog
クラウド時代の開発者 &運用担当者のためのモニタリング &分析SaaS
強力な
アラート
ダッシュボード公開や
チーム間のコラボレーション
根本原因の
相関と分析
履歴の分析

8. レガシーなモニタリングツールではクラウド時代のスピードとペースに追いつけない
プラットフォーム／サービス ユニット (VM, コンテナ, ファンクション)
リリース頻度 人への投資
ごく少数の
ベンダー
多数のOSSや
SaaSの併用
年に1度
日に一度
Ops
Dev + Ops
Biz + Dev
+ Ops
Standardized/On-Premise Diverse/SaaS
Time
ツールの数
インスタンス、コンテナ、
マイクロサービス等々
頻度
人へのニーズ
分散集中
Waterfall Agile IntegratedSilo’d
Time Time

9. インフラ
アーキテクチャ
開発サイクル
スタック
関係者
モニタリング
集約
モノリス
ウォーターフォール
標準化されたオンプレの
ベンダーソフトウェ
インフラ（管理者）
開発（参加者）
次世代
分散
マイクロサービス
アジャイル
多種多様で導入しやすい OSSや
SaaSコンポーネント
複数のインフラ・開発チーム
レガシー

10. なぜモニタリング？

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. システムの可視性における三本柱
MetricsTraces
トレンドやパターンを把握
システムやミドルウェアの
パフォーマンス
組み合わせや集計による分析
インシデントの調査
デバッグやトラブルシューティング
イベントベース
Items in Shopping Cart Logins Total Trips Ad Revenue
Logs
サービス間の原因特定
アプリケーションのスループット
レイテンシ、エラー
リクエストベース
ビジネス
分析

13. Why Datadog
250以上のインテグレーション
チームを跨いだコラボレーション
セルフサービス、OOTB、Fast Time to Value
メトリクス、イベント、 APM、ログの相関
機械学習を含むスケーラブルなプラットフォーム

14. クラウド時代のモニタリング
そのポイントは？

15. ではなく
Cattle, not pets
ペット 家畜

16. Tag（タグ）
メトリクスに付帯
key:value 形式で1個のメトリックに複数の
タグを付与することが可能
フィルタリング／グルーピング
サーバーやVM、コンテナをロール、データ
センター、ゾーンごとに分析可能に
カスタマイズ可能
エージェント設定ファイル、 UI、インテグレーション
等々、自身でタグの付与が可能
タグごとのモニタリング・分析

17. モニタリングのポイント
モニタリング対象について考えてみよう
ワークメトリクス
リソースメトリクス
イベント
APM
ログ

18. モニタリングのポイント
モニタリング対象について考えてみよう
ワークメトリクス
リソースメトリクス
イベント
APM
ログ
スループット（throughput）
単位時間あたりの処理量（通常は絶対値で表現される）
例）秒間HTTPリクエスト数／秒間DBクエリー数
成功（success）
成功した処理のパーセンテージ
例）HTTPステータス2xxの割合／成功したDBクエリーの割合
失敗（error）
失敗した処理のパーセンテージ
例）HTTPステータス5xxの割合／例外処理が発生したクエリーの割合
パフォーマンス（performance）
処理が完了するまでに要する時間といった効率
例）99%のリクエストが0.1秒以内にレスポンスされる／
クエリー時間の90パーセンタイル値

19. モニタリングのポイント
モニタリング対象について考えてみよう
ワークメトリクス
リソースメトリクス
イベント
APM
ログ
使用率（utilization）
リソースがビジー状態になる時間の割合、もしくは、
リソースが使用されているキャパシティの割合
例）ビジー状態のディスクI/Oの時間%／合計メモリに対する使用%
飽和度（saturation）
処理しきれないリクエスト量
例）メモリのスワップ量／キューに溜まっているDBクエリー数
失敗（error）
処理そのものからは見えない内部エラー
例）ディスクデバイスエラー数／DBレプリケーションエラー数
可用性（availability）
リソースがリクエストに応答可能な状態となっている時間の割合
定期的にチェックされている場合のみ観測可能
例）ディスク読み書き可能な時間%／DBにアクセス可能な時間%

20. モニタリングのポイント
モニタリング対象について考えてみよう
ワークメトリクス
リソースメトリクス
イベント
APM
ログ
メトリクスとは別にシステムの変更といった重要な通知を
イベントとして記録する
頻度としてはメトリクスほどではないが原因究明につながる
情報を含むことがある
変更（changes）
コード変更のリリースやビルド、パッチ適用 等々
アラート（alerts）
生成されたアラートや3rd Party製品の通知
スケーリング（scaling events）
サーバーやコンテナの追加／停止

21. モニタリングのポイント
モニタリング対象について考えてみよう
ワークメトリクス
リソースメトリクス
イベント
APM
ログ
アプリケーション開発とインフラ運用の統合
DevOpsのチーム体制やインフラの変化（オートスケール、マイクロ
サービス、コンテナ化）に伴いフルスタックでのモニタリングが必要と
なった
- アプリケーションのスループット、エラー、レイテンシ
- トランザクションのトレーサビリティ
- サービスマップ

22. Datadog APMの特長
- 関数やメソッドごとのパフォーマンスやエラーのトレースを
簡単な設定で取得可能
- メトリクスやログとのシームレスな相関をGUIで実現
- マイクロサービスの分散トレーシングも可能
- OpenTracingにも対応
- 対応言語: Python / Ruby / Go / Java / Node.js / .NET / PHP
https://docs.datadoghq.com/tracing/languages/

24. 詳細な原因や傾向を分析
アプリケーションのデバッグ情報やシステムの挙動を記録したログを、
メトリクスやトレース情報と相関付けることで原因の検索／分析ワーク
フローを簡素化
アプリケーショントレース
との相関
ログパターン分析
モニタリングのポイント
モニタリング対象について考えてみよう
ワークメトリクス
リソースメトリクス
イベント
APM
ログ

25. Datadogでモニタリングしてみよう

26. アラートの種類
緊急性に応じて3段階のレベルでアラートを使い分ける
データベースのクエリーレスポンスが遅くなってきているが
サービス全体のレスポンスに影響するほどではない
記録する（Record） - 緊急度：低
誰かに知らせる必要がなく、モニタリングシステムに記録するだけ
ディスクスペースが逼迫してきているので数日以内での対応
が必要
通知する（Notification） - 緊急度：中
すぐに対応が必要ではないが、誰かが対応できるようにメールや
チャットで知らせる
レスポンス時間がSLAに抵触するほど遅延している
呼び出す（Page） - 緊急度：高
他の仕事や私用を中断してでも対応が必要なものを、担当者に直接
連絡して呼び出す

27. Datadogでのモニタリングとアラート

28. モニタリングの種類
閾値 異常検知（Anomaly） 外れ値（Outlier） 予測（Forecast）
ログ APM 複合条件
And others...

29. UIから簡単にセルフインストール可能
さまざまな3rd Partyツールとの連携
- Slack
- PagerDuty
- JIRA
- Webhook
- ServiceNOW
- etc
モニターごとに個別に連携先を指定可能
アラートワークフローで役に立つ豊富なインテグレーション

30. Synthetics - 外形監視
サービスを外側から監視
複数の拠点から任意のサイトや APIエンドポイントに
HTTP(S)リクエストを送信して監視
クライテリアとしてステータスコード、レスポンス時間、
ヘッダ等の指定が可能
モニター対象として通知したり、稼働状況をダッシュ
ボードで可視化することが可能
プライベートベータ（ 2019年2月現在）

31. Uptime Widget

32. Demo

41. お試しください
14日間のフリートライアルにサインアップ！

42. 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
告知

43. Let’s explore monitoring
in the cloud age

44. Thank you