Datadogを使って メトリクス監視とログ監視を一元管理 @Cloud Native Developers JP #7

Datadogを使って メトリクス監視とログ監視を一元管理 @Cloud Native Developers JP #7

Transcript

1. Masaya Aoyama CyberAgent adtech studio Datadogを使って メトリクス監視とログ監視を一元管理 @Cloud Native Developers JP #7 MasayaAoyama @amsy810
2. 連載「今こそ始めよう！Kubernetes 入門」 @ThinkIT Japan Container Days v18.04　Keynote 登壇 Cloud Native Meetup Tokyo Organizer (+ KubeCon日本人会 + JKD) CKA (CKA-1700-0138-0100)、CKAD (CKAD-1800-0002-0100) OpenStack / Kubernetes Contributor Masaya Aoyama (@amsy810) Infrastructure Engineer
5. Datadogとは？ Software as a Service（SaaS）の監視ツール 　　Pros: 　　　　集約側サーバの運用が不要、マシンリソースが不要 　　Cons: 　　　　金銭的コストが掛かる 　　　　1 Host （10 Container included） あたり $15 - $23
6. Datadogとは？ • サーバ増強 • スケーリング • 機能追加 • アップデート • etc. 人数が少ないチームで見ていると大変
10. Datadog meets Kubernetes
11. What is
12. 01 Pluggable Architecture 02 Sophisticated Tag 03 Beautiful Dashboard 04 Intelligent Monitoring & Alerting 05 Other Features
13. Point 1 Pluggable Architecture
14. Datadog Agent のアーキテクチャ 外部のプログラムから UDP 経由で データを受けとり、集計する 15 秒間隔でメトリクスを収集。 python のプログラムが実行される形式。 pluggable。 メモリ上にバッファしてメトリクスを送信 NWの問題で送信できなかった場合は次回送信
15. Point 2 Sophisticated Tag
16. 監視対象のサーバが沢山 全 体 集 合 prd-sys2-webfront-001 stg-sys1-ctldb-001
17. 各サーバはグループ化 prd stg webfront webkvs 全 体 集 合 ctldb prd-sys2-webfront-001 stg-sys1-ctldb-001 sys2 sys1
18. Datadog では各ホストにタグを設定 • env: prd • project: sys2 • role: webfront • host: prd-sys2-webfront-001 各ホストには複数のタグがついています • prd-app2-webfront-{001, 002, …} ◦ prd, sys2, webfront • stg-app1-ctldb-{001, 002, …} ◦ stg, sys1, ctldb Datadog のタグのおはなし prd stg webfront webkvs 全 体 集 合 ctldb sys2 sys1
19. 各サーバはグループ化 prd stg webfront webkvs 全 体 集 合 ctldb prd-sys2-webfront-001 stg-sys1-ctldb-001 env: stg project: sys1 role: ctldb host: stg-sys1-ctldb-001 env: prd project: sys2 role: webfront host: prd-sys2-webfront-001 sys2 sys1
20. 例えば… あるメトリクスの 平均値や最大値を取得するとき * (Wildcard) で指定すると、　　の範囲で計算される Datadog のタグのおはなし prd stg 全 体 集 合 webfront webkvs ctldb sys2 sys1
21. 例えば… あるメトリクスの 平均値や最大値を取得するとき env: prd で指定すると、　　の範囲で計算される Datadog のタグのおはなし prd stg 全 体 集 合 webfront webkvs ctldb sys2 sys1
22. 例えば… あるメトリクスの 平均値や最大値を取得するとき env: prd, project: sys2 で指定すると、　　の範囲で計算される Datadog のタグのおはなし prd stg 全 体 集 合 webfront webkvs ctldb sys2 sys1
23. 例えば… あるメトリクスの 平均値や最大値を取得するとき env: prd, project: sys2, role: webfront で指定すると、　　の範囲で計算される Datadog のタグのおはなし prd stg 全 体 集 合 webfront webkvs ctldb sys2 sys1
24. 例えば… あるメトリクスの 平均値や最大値を取得するとき env: prd, project: sys2, role: webfront, host: prd-sys2-webfront-001 で指定すると、　　の範囲で計算される Datadog のタグのおはなし prd stg 全 体 集 合 webfront webkvs ctldb sys2 sys1
25. 例えば… あるメトリクスの 平均値や最大値を取得するとき env: prd, project: sys2, role: webfront, host: prd-sys2-webfront-001 で指定すると、　　の範囲で計算される Datadog のタグのおはなし prd stg 全 体 集 合 webfront webkvs ctldb sys2 sys1
26. 今後、role 名が被ったりしてくると project も指定してあげる必要があります。 env: prd, project: sys1, role: web-front ≠ env: prd, role: web-front Datadog のタグのおはなし prd stg 全 体 集 合 sys2 webfront webkvs sys1
27. その他のホストに自動的につけられるタグ • region ◦ ariake, aws • instance-type ◦ s2.medium, t2.small, etc • availability-zone ◦ ar-diana-1c, ap-northeast-1c, etc • image ◦ ami-000002e, etc • os ◦ CentOS_release_6.6_(final), etc GCP, AWS などでは 自動でタグが付与される
28. ちなみにメトリクスにもタグがついてます たとえば ディスク使用量 には device tag がついています。 device タグを指定しない場合は、 合算した平均値や最大値が 表示されるので注意
29. Point 3 Beautiful Dashboard
30. ダッシュボードを作ろう ・TimeBoard 　　期間指定可能、タイルレイアウト ・ScreenBoard 　　最新のデータのみ、レイアウト自由
31. TimeBoard 期間、日時の指定が可能 タイルサイズの変更も可能 タイルサイズの変更も可能 ひとつのタイルに ひとつのグラフ
32. ScreenBoard 柔軟なサイズ指定 ある期間の最新データ ScreenBoard は public URL が生成可能
33. グラフの作り方 グラフの種類 グラフの表示形式 棒グラフ、線グラフ、積立グラフ 対象とする ホスト、メトリクスのタグを指定 平均値、最大値、最小値、合計 などを指定 role 毎にグラフ化 算術処理
34. Query Value Heatmap Change Hostmap Toplist Distribution
35. Kubernetes Dashboard
36. グラフを作ろう メトリクスさえ送っておけばいいので、 広告システム的な外れ値検知にも利用可能 外れ値検知の算術演算 　アルゴリズム、パラメータを指定
37. グラフを作ろう 複合メトリクスの グラフ化 warn/crit のマーカー
38. グラフを作ろう 複数メトリクスの 計算結果をグラフ化 複数グラフ化 Template Variable の利用
39. Template Variable の利用 Template Variable を利用することで、絞込用の変数を外出しすることが可能です 後から変更可能。 デフォルト値も設定できるので、 積極的に使ったほうが良さそう。 後から変更可能。 デフォルト値も設定できるので、 積極的に使ったほうが良さそう。
40. 実際にはここに role や env の指定が 入るようになります。 Template Valiable の選択 　default 値の指定も可能 　* マッチも可能
41. Point 4 Intelligent Monitor & Alerting
42. モニタの種類 ―――　ホスト死活監視 ―――　メトリクス監視 ―――　Integration 系監視 ―――　プロセス監視 ―――　ネットワーク監視（TCP/HTTP） ―――　カスタムチェック（自作プラグイン等） ―――　イベント監視（ログ監視で利用） ―――　外れ値監視（グループ内の異常なホストの検知） ―――　アプリケーションパフォーマンス監視 ―――　複合条件監視（ex. DBのiops が高い && 5xx count が高い） 様々な方式で監視設定を行 うことが可能
43. メトリクスモニタを作ろう グラフと同じで host, device タグ毎に分割 マルチアラートにすることで 1つのモニタで host * device 毎に監視 たまにデータが抜け落ちたりすることもあ るので、Do not requre に 閾値、変化量、異常値などの 監視タイプが存在 モニタの種類によっては Warning がありません
44. グラフを作ろう 未来を予知してアラート いつもとの違いを検知してアラート グループ中の違いを検知してアラート
45. メトリクスモニタを作ろう 過去の推移などから 異常値の割合でアラートを発報する 偏差やアルゴリズムなど設定
46. メトリクスモニタを作ろう データの欠損が 15 分続いた場合に アラートを投げる アラートメッセージを Markdown で設定 {{HOGE}} で幾つかの変数が利用可能 {{#is_alert}}... などでアラート時のメッセージを設定 @slack-datadog_rs で slack 宛 @pager-duty で pagerduty 発報 @pager-duty-resolve で pagerduty resolve
47. Process モニタなどでの工夫 複数台構成で一部に障害が即時対応しなくても問題ない場合 env, project, role 毎に グルーピング グループ内で障害の割合で 発報するように
48. 2 種類の異常検知系モニタの違い Outliner モニタ 特定のグループの中で異常な対象を検知する 　例: 14 台の中で 1 台だけ異常なホストがいる Metrics モニタの anomaly alert 普段とくらべて異常な対象を検知する 　例: request がいつもと比べて多い
49. Point 5 Other features
50. Downtime 機能 いわゆる zabbix のメンテナンスモードです。 対象のモニタ 対象のホスト 　を指定します。 繰り返しなど。 DB のバックアップ時の iops などは除外していま す。
51. HostMap 視覚的に メトリクスの状態を 確認 prd 環境のサーバを project, role で分類し memory の利用率を 可視化
52. Infrastructure List aws のインスタンスを role ごとにまとめて表示とか サーバの一覧を簡単に検索 それぞれのサーバにどの Middleware が入っているか等
53. Metrics Explorer/Summary 一時的にグラフ/メトリクスを 確認したいときなど
54. notebook 障害時の報告用に。 ある期間・ある日時のグラフを ペラいちにまとめる。 例えば、 パケットドロップ率が上昇して、 レスポンスが落ちていました。 とか。
55. What is
56. Kubernetes コンテナを利用する際のプラットフォーム 　・コンテナを複数ノードにまたがって分散管理 　・ロードバランシングエンドポイントの提供 Pod Pod Pod Deployment Service Node Node Node Node とにかくコンテナ使うなら Kubernetes
57. And now,
58. Datadog meets Kubernetes
59. Datadog の Tag ≒ Kubernetes の Label
60. 各サーバはグループ化 prd stg webfront webkvs 全 体 集 合 ctldb prd-ake-webfront-001 stg-izanami-ctldb-001 env: stg project: sys1 role: ctldb host: stg-sys1-ctldb-001 env: prd project: sys2 role: webfront host: prd-sys2-webfront-001 sys2 sys1
61. 各サーバはグループ化 Cluster A Cluster B Service B Deployment B Deployment C 全 体 集 合 Service A Deployment A Pod B Pod A cluster: B Service: A deployment: A pod_id: XXX cluster: A service: B deployment: B pod_id: YYY
62. 01 Live Container Monitoring 02 Simplest Installation 03 Kubernetes Monitoring & Alerting 04 Container Native Metrics 05 Log Management
63. Point 1 Live Container Monitoring
64. ライブコンテナモニタリング Containers モニタリングのページでアクティブに調査している間は コンテナ毎に 2 sec 周期でメトリクスが更新され バックグラウンドではメトリクスは 10 sec の周期で収集され保存されます。 • 柔軟な絞り込みを行なうことが可能 ◦ Deployment に紐づくコンテナ ◦ Service に紐づくコンテナ ◦ Pod に紐づくコンテナ ◦ Namespace 毎 ◦ その他 実際に見てみましょう
65. ライブコンテナモニタリング
66. Point 2 Simplest Installation
67. コンテナ監視 on Docker コンテナの監視を行なう方法は２種類 1. コンテナホスト上で datadog-agent プロセスを起動する ◦ /etc/dd-agent/conf.d/docker*.yaml を設定する必要がある 2. コンテナホスト上に datadog/docker-dd-agent コンテナを起動する ◦ docker コンテナに特定のディレクトリ以下を ReadOnly で渡す必要がある
68. コンテナ監視 on Docker コンテナの監視を行なう方法は２種類 1. コンテナホスト上で datadog-agent プロセスを起動する ◦ /etc/dd-agent/conf.d/docker*.yaml を設定する必要がある 2. コンテナホスト上に datadog/docker-dd-agent コンテナを起動する ◦ docker コンテナに特定のディレクトリ以下を ReadOnly で渡す必要がある
69. コンテナ監視 on Kubernetes 実はたったの 1 コマンドで展開 Helm を使わない場合は様々な設定が必要… • Docker socket、cgroups、proc 周りをマウント • Kubernetes 用 Service Discovery の有効化 • 必要に応じて RBAC の設定 • Kubernetes add-on の kube-state-metrics の有効化 • auto_conf の設定 $ helm init （クラスタ構築以降 1 度だけ実行すれば OK） $ helm install --name dd-aoyama stable/datadog
70. Datadog Agent 設定 helm initする際に設定のyamlファイルを指定する事が可能 設定例（公式より） image: repository: datadog/docker-dd-agent tag: latest daemonset: enabled: true deployment: enabled: false replicas: 1 kubeStateMetrics.enabled: true datadog: apiKey: xxxxxxxxxxxxxxx name: dd-agent logLevel: WARNING tags: env:xxxxx $ helm install -f values.yml --name dd-aoyama stable/datadog # confd: # redisdb.yaml: |- # init_config: # instances: # - host: "name" # port: "6379" resources: requests: cpu: 100m memory: 128Mi limits: cpu: 256m memory: 512Mi autoconf: kubernetes_state.yaml: |- docker_images: - kube-state-metrics init_config: instances: - kube_state_url: http://%%host%%:%%port%%/metrics
71. auto_conf を使った Service Discovery Datadog Pod から Nginx Pod の監視をしたいとき いちいち Pod の IP を設定するの…？ 　　　　　　　　　　　　　　　 コンテナのライフサイクルは短いけど… /etc/dd-agent/conf.d/nginx.conf init_config: instances: - nginx_status_url: http://10.0.0.1:80/nginx_status - nginx_status_url: http://10.0.0.2:80/nginx_status - nginx_status_url: http://10.0.0.3:80/nginx_status
72. auto_conf を使った Service Discovery Datadog Pod から Nginx Pod の監視をしたいとき サービスディスカバリによる自動判別！ nginx.yaml: |- docker_images: - nginx init_config: instances: - nginx_status_url:　http://%%host%%:%%port%%/nginx_status
73. Point 3 Monitoring & Alerting at Kubernetes
74. Kubernetesでのモニタリング コンテナが正常に起動しているかのチェック • Readiness Probe • Liveness Probe Datadog側ではコンテナのステータスだけを確認する（DD側は設定変更不要） 　＝ 個々のコンテナに対してDatadog側では細かいチェックを行わない 　　 プロセスの生存性、ポートが空いているか、etc ただし、Latencyのモニタリングなどは必要
75. Point 4 Container Native Metrics
76. Kubernetes のメトリクス kubernetes.* または kubernetes_state.* で登録される 　　　　　　　　　　　　　　　　 #kube_service:service-sample #kube_deployment:dep-sample #kube_replica_set:dep-sample-2627731247 #kube_namespace:default #kube_pod:dep-sample-2627731247-79414 #kube_pod_ip:10.100.76.12 #kube_master_version:1.7.8 #kubelet_version:1.7.8 豊富なタグも付与される 　Deployment名、Service名、etc
77. kube-state-metrics による Cluster Level メトリクス kubernetes_state.* のメトリクスは Cluster Level のメトリクス 例えば • Deployment の現在の Pod 数 • 要求 Pod 数 • 停止 Pod 数 • Job の成功数、失敗数 Cluster Level のメトリクスは kubernetes add-on の kube-state-metrics を利用 Helm だと datadog と合わせて自動でインストール
78. Deployment の Pod 数を監視する例 Pod Pod Pod Deployment: dep-sample Pod Pod Pod Pod Pod Pod Pod Deployment: dep-sample Pod Pod Pod Pod Unavailable: 0 Desired: 7 Available: 7 Unavailable: 2 Desired: 7 Available: 5
79. Deployment の Pod 数を監視する例
80. A/B テストでの Pod 数を監視する例 Pod Pod Pod Deployment: dp1 Service ab-endpoint
81. A/B テストでの Pod 数を監視する例 Pod Pod Pod Pod Pod Deployment: dp1 Deployment: dp2 Service ab-endpoint
82. A/B テストでの Pod 数を監視する例
83. Point 5 Log Management
84. Log Monitoring Datadog v6以降、Agentにログモニタリングの機能が内包 Datadog Agentの機能を有効化することで利用可能 100万行あたり 7 days retention: $1.27 = 140円 15 days retention: $1.70 = 190円 30 days retention: $2.50 = 280円 データ量で考えるのではなく、行数でカウント 　＝ログデータを有意義に使ってもらいたいとのこと
87. まとめ Datadog • Pluggable Architecture • Sophisticated Tag • Beautiful Dashboard • Intelligent Monitor & Alerting • Other features Container with Datadog • Live Container Monitoring • Simplest Installation • Container Native Metrics • Monitring & Alerting at Kubernetes • Log Management
88. ご静聴ありがとうございました。