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

Slide 1

Slide 1 text

Masaya Aoyama CyberAgent adtech studio Datadogを使ってメトリクス監視とログ監視を一元管理 @Cloud Native Developers JP #7 MasayaAoyama @amsy810

Slide 2

Slide 2 text

連載「今こそ始めよう！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

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

Datadogとは？ Software as a Service（SaaS）の監視ツール　　Pros: 　　　　集約側サーバの運用が不要、マシンリソースが不要　　Cons: 　　　　金銭的コストが掛かる　　　　1 Host （10 Container included）あたり $15 - $23

Slide 6

Slide 6 text

Datadogとは？ • サーバ増強 • スケーリング • 機能追加 • アップデート • etc. 人数が少ないチームで見ていると大変

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

Datadog meets Kubernetes

Slide 11

Slide 11 text

What is

Slide 12

Slide 12 text

01 Pluggable Architecture 02 Sophisticated Tag 03 Beautiful Dashboard 04 Intelligent Monitoring & Alerting 05 Other Features

Slide 13

Slide 13 text

Point 1 Pluggable Architecture

Slide 14

Slide 14 text

Datadog Agent のアーキテクチャ外部のプログラムから UDP 経由でデータを受けとり、集計する 15 秒間隔でメトリクスを収集。 python のプログラムが実行される形式。 pluggable。メモリ上にバッファしてメトリクスを送信 NWの問題で送信できなかった場合は次回送信

Slide 15

Slide 15 text

Point 2 Sophisticated Tag

Slide 16

Slide 16 text

監視対象のサーバが沢山全体集合 prd-sys2-webfront-001 stg-sys1-ctldb-001

Slide 17

Slide 17 text

各サーバはグループ化 prd stg webfront webkvs 全体集合 ctldb prd-sys2-webfront-001 stg-sys1-ctldb-001 sys2 sys1

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

各サーバはグループ化 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

Slide 20

Slide 20 text

例えば… あるメトリクスの平均値や最大値を取得するとき * (Wildcard) で指定すると、　　の範囲で計算される Datadog のタグのおはなし prd stg 全体集合 webfront webkvs ctldb sys2 sys1

Slide 21

Slide 21 text

例えば… あるメトリクスの平均値や最大値を取得するとき env: prd で指定すると、　　の範囲で計算される Datadog のタグのおはなし prd stg 全体集合 webfront webkvs ctldb sys2 sys1

Slide 22

Slide 22 text

例えば… あるメトリクスの平均値や最大値を取得するとき env: prd, project: sys2 で指定すると、　　の範囲で計算される Datadog のタグのおはなし prd stg 全体集合 webfront webkvs ctldb sys2 sys1

Slide 23

Slide 23 text

例えば… あるメトリクスの平均値や最大値を取得するとき env: prd, project: sys2, role: webfront で指定すると、　　の範囲で計算される Datadog のタグのおはなし prd stg 全体集合 webfront webkvs ctldb sys2 sys1

Slide 24

Slide 24 text

例えば… あるメトリクスの平均値や最大値を取得するとき env: prd, project: sys2, role: webfront, host: prd-sys2-webfront-001 で指定すると、　　の範囲で計算される Datadog のタグのおはなし prd stg 全体集合 webfront webkvs ctldb sys2 sys1

Slide 25

Slide 25 text

Slide 26

Slide 26 text

今後、role 名が被ったりしてくると project も指定してあげる必要があります。 env: prd, project: sys1, role: web-front ≠ env: prd, role: web-front Datadog のタグのおはなし prd stg 全体集合 sys2 webfront webkvs sys1

Slide 27

Slide 27 text

その他のホストに自動的につけられるタグ ● 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 などでは自動でタグが付与される

Slide 28

Slide 28 text

ちなみにメトリクスにもタグがついてますたとえばディスク使用量には device tag がついています。 device タグを指定しない場合は、合算した平均値や最大値が表示されるので注意

Slide 29

Slide 29 text

Point 3 Beautiful Dashboard

Slide 30

Slide 30 text

ダッシュボードを作ろう・TimeBoard 　　期間指定可能、タイルレイアウト・ScreenBoard 　　最新のデータのみ、レイアウト自由

Slide 31

Slide 31 text

TimeBoard 期間、日時の指定が可能タイルサイズの変更も可能タイルサイズの変更も可能ひとつのタイルにひとつのグラフ

Slide 32

Slide 32 text

ScreenBoard 柔軟なサイズ指定ある期間の最新データ ScreenBoard は public URL が生成可能

Slide 33

Slide 33 text

グラフの作り方グラフの種類グラフの表示形式棒グラフ、線グラフ、積立グラフ対象とするホスト、メトリクスのタグを指定平均値、最大値、最小値、合計などを指定 role 毎にグラフ化算術処理

Slide 34

Slide 34 text

Query Value Heatmap Change Hostmap Toplist Distribution

Slide 35

Slide 35 text

Kubernetes Dashboard

Slide 36

Slide 36 text

グラフを作ろうメトリクスさえ送っておけばいいので、広告システム的な外れ値検知にも利用可能外れ値検知の算術演算　アルゴリズム、パラメータを指定

Slide 37

Slide 37 text

グラフを作ろう複合メトリクスのグラフ化 warn/crit のマーカー

Slide 38

Slide 38 text

グラフを作ろう複数メトリクスの計算結果をグラフ化複数グラフ化 Template Variable の利用

Slide 39

Slide 39 text

Template Variable の利用 Template Variable を利用することで、絞込用の変数を外出しすることが可能です後から変更可能。デフォルト値も設定できるので、積極的に使ったほうが良さそう。後から変更可能。デフォルト値も設定できるので、積極的に使ったほうが良さそう。

Slide 40

Slide 40 text

実際にはここに role や env の指定が入るようになります。 Template Valiable の選択　default 値の指定も可能　* マッチも可能

Slide 41

Slide 41 text

Point 4 Intelligent Monitor & Alerting

Slide 42

Slide 42 text

モニタの種類 ―――　ホスト死活監視 ―――　メトリクス監視 ―――　Integration 系監視 ―――　プロセス監視 ―――　ネットワーク監視（TCP/HTTP） ―――　カスタムチェック（自作プラグイン等） ―――　イベント監視（ログ監視で利用） ―――　外れ値監視（グループ内の異常なホストの検知） ―――　アプリケーションパフォーマンス監視 ―――　複合条件監視（ex. DBのiops が高い && 5xx count が高い）様々な方式で監視設定を行うことが可能

Slide 43

Slide 43 text

メトリクスモニタを作ろうグラフと同じで host, device タグ毎に分割マルチアラートにすることで 1つのモニタで host * device 毎に監視たまにデータが抜け落ちたりすることもあるので、Do not requre に閾値、変化量、異常値などの監視タイプが存在モニタの種類によっては Warning がありません

Slide 44

Slide 44 text

グラフを作ろう未来を予知してアラートいつもとの違いを検知してアラートグループ中の違いを検知してアラート

Slide 45

Slide 45 text

メトリクスモニタを作ろう過去の推移などから異常値の割合でアラートを発報する偏差やアルゴリズムなど設定

Slide 46

Slide 46 text

メトリクスモニタを作ろうデータの欠損が 15 分続いた場合にアラートを投げるアラートメッセージを Markdown で設定 {{HOGE}} で幾つかの変数が利用可能 {{#is_alert}}... などでアラート時のメッセージを設定 @slack-datadog_rs で slack 宛 @pager-duty で pagerduty 発報 @pager-duty-resolve で pagerduty resolve

Slide 47

Slide 47 text

Process モニタなどでの工夫複数台構成で一部に障害が即時対応しなくても問題ない場合 env, project, role 毎にグルーピンググループ内で障害の割合で発報するように

Slide 48

Slide 48 text

2 種類の異常検知系モニタの違い Outliner モニタ特定のグループの中で異常な対象を検知する　例: 14 台の中で 1 台だけ異常なホストがいる Metrics モニタの anomaly alert 普段とくらべて異常な対象を検知する　例: request がいつもと比べて多い

Slide 49

Slide 49 text

Point 5 Other features

Slide 50

Slide 50 text

Downtime 機能いわゆる zabbix のメンテナンスモードです。対象のモニタ対象のホスト　を指定します。繰り返しなど。 DB のバックアップ時の iops などは除外しています。

Slide 51

Slide 51 text

HostMap 視覚的にメトリクスの状態を確認 prd 環境のサーバを project, role で分類し memory の利用率を可視化

Slide 52

Slide 52 text

Infrastructure List aws のインスタンスを role ごとにまとめて表示とかサーバの一覧を簡単に検索それぞれのサーバにどの Middleware が入っているか等

Slide 53

Slide 53 text

Metrics Explorer/Summary 一時的にグラフ/メトリクスを確認したいときなど

Slide 54

Slide 54 text

notebook 障害時の報告用に。ある期間・ある日時のグラフをペラいちにまとめる。例えば、パケットドロップ率が上昇して、レスポンスが落ちていました。とか。

Slide 55

Slide 55 text

What is

Slide 56

Slide 56 text

Kubernetes コンテナを利用する際のプラットフォーム　・コンテナを複数ノードにまたがって分散管理　・ロードバランシングエンドポイントの提供 Pod Pod Pod Deployment Service Node Node Node Node とにかくコンテナ使うなら Kubernetes

Slide 57

Slide 57 text

And now,

Slide 58

Slide 58 text

Datadog meets Kubernetes

Slide 59

Slide 59 text

Datadog の Tag ≒ Kubernetes の Label

Slide 60

Slide 60 text

各サーバはグループ化 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

Slide 61

Slide 61 text

各サーバはグループ化 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

Slide 62

Slide 62 text

01 Live Container Monitoring 02 Simplest Installation 03 Kubernetes Monitoring & Alerting 04 Container Native Metrics 05 Log Management

Slide 63

Slide 63 text

Point 1 Live Container Monitoring

Slide 64

Slide 64 text

ライブコンテナモニタリング Containers モニタリングのページでアクティブに調査している間はコンテナ毎に 2 sec 周期でメトリクスが更新されバックグラウンドではメトリクスは 10 sec の周期で収集され保存されます。 ● 柔軟な絞り込みを行なうことが可能 ○ Deployment に紐づくコンテナ ○ Service に紐づくコンテナ ○ Pod に紐づくコンテナ ○ Namespace 毎 ○ その他実際に見てみましょう

Slide 65

Slide 65 text

ライブコンテナモニタリング

Slide 66

Slide 66 text

Point 2 Simplest Installation

Slide 67

Slide 67 text

コンテナ監視 on Docker コンテナの監視を行なう方法は２種類 1. コンテナホスト上で datadog-agent プロセスを起動する ○ /etc/dd-agent/conf.d/docker*.yaml を設定する必要がある 2. コンテナホスト上に datadog/docker-dd-agent コンテナを起動する ○ docker コンテナに特定のディレクトリ以下を ReadOnly で渡す必要がある

Slide 68

Slide 68 text

Slide 69

Slide 69 text

コンテナ監視 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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

auto_conf を使った Service Discovery Datadog Pod から Nginx Pod の監視をしたいときサービスディスカバリによる自動判別！ nginx.yaml: |- docker_images: - nginx init_config: instances: - nginx_status_url:　http://%%host%%:%%port%%/nginx_status

Slide 73

Slide 73 text

Point 3 Monitoring & Alerting at Kubernetes

Slide 74

Slide 74 text

Kubernetesでのモニタリングコンテナが正常に起動しているかのチェック ● Readiness Probe ● Liveness Probe Datadog側ではコンテナのステータスだけを確認する（DD側は設定変更不要）　＝個々のコンテナに対してDatadog側では細かいチェックを行わない　　プロセスの生存性、ポートが空いているか、etc ただし、Latencyのモニタリングなどは必要

Slide 75

Slide 75 text

Point 4 Container Native Metrics

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

kube-state-metrics による Cluster Level メトリクス kubernetes_state.* のメトリクスは Cluster Level のメトリクス例えば ● Deployment の現在の Pod 数 ● 要求 Pod 数 ● 停止 Pod 数 ● Job の成功数、失敗数 Cluster Level のメトリクスは kubernetes add-on の kube-state-metrics を利用 Helm だと datadog と合わせて自動でインストール

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

Deployment の Pod 数を監視する例

Slide 80

Slide 80 text

A/B テストでの Pod 数を監視する例 Pod Pod Pod Deployment: dp1 Service ab-endpoint

Slide 81

Slide 81 text

A/B テストでの Pod 数を監視する例 Pod Pod Pod Pod Pod Deployment: dp1 Deployment: dp2 Service ab-endpoint

Slide 82

Slide 82 text

A/B テストでの Pod 数を監視する例

Slide 83

Slide 83 text

Point 5 Log Management

Slide 84

Slide 84 text

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円データ量で考えるのではなく、行数でカウント　＝ログデータを有意義に使ってもらいたいとのこと

Slide 85

Slide 85 text

No content

Slide 86

Slide 86 text

No content

Slide 87

Slide 87 text

まとめ 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

Slide 88

Slide 88 text

ご静聴ありがとうございました。