Datadog基本のキ

0

最近会社でもDatadogを使い始めています。
非常に沢山の情報をまとめてチェックできるため、積極的に導入検証を進めています。

Datadogはドキュメントが充実しているので、基本的なことは下記ドキュメントを見ることで大抵のことは設定可能です。
https://docs.datadoghq.com/ja/

とは言え、Datadogは出来ることが膨大なので最初は戸惑うことが多いですし、ドキュメントも所々英語のままなので私自身も最初は分からないことだらけでした。
そこで、私がここ最近設定を検証した内容を、記録がてら残しておきます。
※まだ触り初めのため誤っている内容がありましたら、是非ご指摘いただけましたら幸いです。

環境

  • AWS EC2(Amazon Linux)

AWS Integrationsをインストールする

AWSを使っていてまずはじめにやることは、下記のIntegrationsでAWSをインストールすることから始まります。

image.png

Integrationsを表示すると沢山のIntegrationsが存在します。
https://docs.datadoghq.com/ja/integrations/

IntegrationsをインストールすることでインストールしたIntegrationのメトリクスを収集できる状態になります。

その中にAWSがあるので、インストールを行うと下記のような画面になります。
image.png

ここでは自分で使っているAWSアカウントを追加する必要があります。
また、そのAWSアカウントに対してDatadogがサービスで利用しているAWSアカウントに対して、読み取り権限を付与してあげることになります。
そうすることで、Datadogは様々なAWSのAPIで取得した情報をDatadogのメトリクスとして表示させることができるようになります。

screenshot_2019-12-06_18_16_46.png

IAM Roleの設定の詳細は下記のドキュメントに書いてありますが、IAM Roleまで作成して設定してあげた値を上記Integrationsで設定します。
https://docs.datadoghq.com/ja/integrations/amazon_web_services/?tab=allpermissions

ここまで設定して暫くすると、CloudWatchで取得しているメトリクスがDatadogで同期されるようになります。
下記MetricsのSummaryより、メトリクスのキーが表示されるようになっていることを確認出来たらOKです。
もし確認できないようでしたら、うまく同期できていないのでこれまでの設定を見直す必要があります。
image.png

下記はec2に関するメトリクスが取得できているかを確認しています。

image.png

EC2にdatadogのエージェントをインストールする

IntagrationsのAgentを見ると各OSにあわせたエージェントのインストール手順が確認できます。
screenshot_2019-12-06_18_28_54.png

MacOS用のエージェントもあるのが面白いですね。
上記ワンライナーを実行しても良いと思いますし、弊社ではAnsibleを使用しているので下記のようなdatadog-agentロールを用意して適用しました。

Ansible

tasks/main.yml

- name: Add repository
tags: datadog-agent
become: yes
copy: src=datadog.repo dest=/etc/yum.repos.d/datadog.repo owner=root group=root mode=0644

- name: install datadog-agent
tags: datadog-agent
yum: name=datadog-agent state=installed enablerepo=datadog disablerepo='*'
become: yes
ignore_errors: "{{ ansible_check_mode }}"

- name: copy datadog-agent conf
tags: datadog-agent
become: yes
template:
src: "{{ item.src }}"
dest: "{{ item.dest }}"
owner: dd-agent
group: dd-agent
loop:
- { src: datadog.yaml.j2, dest: /etc/datadog-agent/datadog.yaml }
notify: restart datadog-agent
ignore_errors: "{{ ansible_check_mode }}"

files/datadog.repo

[datadog]
name=datadog
enabled=1
baseurl=https://yum.datadoghq.com/suse/stable/6/x86_64
type=rpm-md
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://yum.datadoghq.com/DATADOG_RPM_KEY.public
https://yum.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public

templates/datadog.yaml.j2

api_key: {{ datadog_api_key }}

tags:
- env:{{ env_value }}

:pencil: key:value 形式にする際に key: value のようなフォーマットにしたいと思う方は多いかと思いますが、なぜかスペースを空けないとタグが認識されないことがあったので、key:value のフォーマットで登録しています。

handlers/main.yml

- name: restart datadog-agent
become: yes
service: name=datadog-agent state=restarted enabled=yes

Ansible Galaxyを使っている場合は公式のものが既に用意されているようです。
https://galaxy.ansible.com/Datadog/datadog

上記まで設定できて、問題がなければメトリクスは取得できるようになっていますので、監視設定を行っていきます。

通知先の設定（Slack）

弊社ではSlackを使っているので基本的にはアラートの通知先はSlackにしています。
Datadogも通知先はSlackにするために下記設定を実施しました。
SlackもAWSと同様、Integrationsから下記設定を行います。
screenshot_2019-12-06_18_48_55.png

注意点として、通知先チャンネルはここで設定できますが、通知先ユーザーはここでは設定できません。
そのため、後ほど説明しますが、メンション先はSlack特有のメンションのフォーマットに則って記述が必要です。

監視/通知設定

監視/通知設定の殆どはMonitorsから行います。
ここから下記基本的な設定を説明していきます。

  • CPU監視
  • メモリー監視
  • ディスク監視
  • ホストステータス監視
  • プロセス監視
  • 外形監視

CPU監視

CPU使用率が一定以上超えた際に通知するようにします。

Monitors→New Monitor→Metricを選択して、下記を設定します。

ステップ 設定内容
Choose the detection method Threshold Alert
Define the metric Metric: system.cpu.user, from: 設定したタグ, avg by: host, Multi Alert
Set alert conditions above, on average, 5 minutes Alert, threshold: 90%
Say what’s happening 下記内容を設定

ここで重要なのは、Define the metricでMulti Alertにして、host単位にすることです。
デフォルトでは、取得したホスト全てのメトリクスの平均値1つが対象になってしまい、ホストごとのアラートになりません。
そこでMulti Alertにすることでホスト単位でのアラート通知にすることが出来ます。
この考え方については、他のメトリクスでも同様です。

通知先は下記を設定します。
{{host.name}}や{{host.ip}}などは変数になっており、ここに値が自動的に入ってきます。

<!subteam^XXXXX|@メンショングループ名>

HostName: {{host.name}}
IPAddress: {{host.ip}}

@slack-チャンネル名

Slackの通知先については、Slackのwebhookなどで指定するようなフォーマットにする必要があるので注意が必要です。
また、チャンネル名については @slack-XXXXというフォーマットのまま通知内容にも表示される仕様のようです。

メモリ監視

使用可能なメモリが10%を切ったら通知をするようにします。

Monitors→New Monitor→Metricを選択して、下記を設定します。

ステップ 設定内容
Choose the detection method Threshold Alert
Define the metric Metric: system.mem.free/system.mem.buffered/system.mem.cached/system.mem.total, from: 設定したタグ, avg by: host, Multi Alert, ( a + b + c ) / d
Set alert conditions below, on average, 5 minutes Alert, threshold: 0.1
Say what’s happening 下記内容を設定

Define the metric はCPUと異なり、取得したメトリクスから計算をします。
Add Query ボタンより、複数メトリクスを選択して、最後に計算を行います。
※メモリの計算式については、メモリの使用率を説明しているサイト等を参考にされることをオススメします。
screenshot_2019-12-06_19_36_18.png

ディスク監視

使用可能なディスクが10%を切ったら通知をするようにします。

Monitors→New Monitor→Metricを選択して、下記を設定します。

ステップ 設定内容
Choose the detection method Threshold Alert
Define the metric Metric: system.disk.used/system.disk.total, from: 設定したタグ, avg by: host, Multi Alert, a / b
Set alert conditions below, on average, 5 minutes Alert, threshold: 0.1
Say what’s happening 上記と同様

メモリ使用率計算よりはシンプルになりますが、こちらも複数クエリから計算するようにしています。
screenshot 2019-12-06 19.47.25.png

ホストステータス監視

いわゆる死活監視です。AWSのEC2でホストステータスチェックでエラーになった際に通知をするようにします。

Monitors→New Monitor→Metricを選択して、下記を設定します。

ステップ 設定内容
Choose the detection method Threshold Alert
Define the metric Metric: aws.ec2.status_check_failed, from: 設定したタグ, avg by: host, Multi Alert
Set alert conditions above or equal to, on average, 5 minutes Alert, threshold: 1
Say what’s happening 上記と同様

上記のシンプルな設定のみでOKです。

screenshot 2019-12-06 19.52.32.png

プロセス監視

プロセスの死活監視を行います。
こちらは他のメトリクスとは異なるので、少しだけ注意が必要です。
CPUやメモリー、ディスクなどの監視は特に意識しなくともメトリクスが取得できていますが、プロセス監視については設定ファイルをいじる必要があります。

まず、対象のインスタンスで下記設定ファイルを変更します。

cd /etc/datadog-agent/conf.d/process.d/
cp conf.yaml.example conf.yaml

次に下記のように監視対象のプロセスを記載します。

init_config:
pid_cache_duration: 120

instances:
- name: nginx
search_string:
- nginx

- name: unicorn
exact_match: false
search_string:
- unicorn

ここで重要なのはexact_match:をFalseにする場合があるという点です。
これはプロセスがRubyやJavaなど、別のプロセスから呼び出されている場合に、exact_matchをFalseにすることで、あいまい検索になり、ヒットするようになります。
うまくプロセス監視で検知できない場合は、ここの値を調整してみてください。

設定後、restart datadog-agentで再起動して、datadog-agent statusでプロセス監視が行われているか確認してください。

process (1.10.1)
----------------
Instance ID: process:nginx:XXX [OK]
Configuration Source: file:/etc/datadog-agent/conf.d/process.d/conf.yaml
Total Runs: 25,202
Metric Samples: Last Run: 17, Total: 428,432
Events: Last Run: 0, Total: 0
Service Checks: Last Run: 1, Total: 25,202
Average Execution Time : 3ms

Instance ID: process:unicorn:XXX [OK]
Configuration Source: file:/etc/datadog-agent/conf.d/process.d/conf.yaml
Total Runs: 25,201
Metric Samples: Last Run: 17, Total: 428,415
Events: Last Run: 0, Total: 0
Service Checks: Last Run: 1, Total: 25,201
Average Execution Time : 3ms

上記のようにOKが返ってきていれば、暫くしたのちに、Datadogで監視設定ができるようになります。
プロセス監視の通知設定については、今までとは少しだけ手順が異なります。

Monitors→New Monitor→Process Checkを選択して、下記を設定します。

まず、監視ができるようになると下記のように通知対象のプロセスが表示されるようになります。
image.png

次に対象のインスタンスを指定します。
screenshot_2019-12-06_20_21_46.png

次にしきい値を調整します。今回はざっくりと、3回失敗したらアラートを飛ばすようにします。
image.png

その後は今までの監視通知と同じようにメッセージを設定すればOKです。
ちなみに、{{comparator}} という変数を使うと、ホスト名とプロセス名が取得できるので、件名に設定しておくと良さそうです。

外形監視

外形監視について説明します。
外形監視はSyntheticsという機能を使用してメトリクスを取得します。
Syntheticsの凄い所として、e2eテストみたいなのも行えるという点です。
ステップを設定することで、定期的に特定のサイトへログインして、特定の文字列が返ってくるかなどの実行が行えます。
今回は別の機能である、いわゆる外形監視について説明します。

Synthetics→Synthetcis Test→New Testを選択して、下記を設定します。

まず、New API Testを選択します。
screenshot 2019-12-06 20.30.48.png

次にHTTPかSSLかを選択します。
HTTPヘッダーをいじったり、レスポンスBODYの文字列を見たい場合はHTTPを選択し、SSL証明書の期限をチェックしたい場合はSSLを選択します。
※Datadogでは外形監視で、レスポンスチェックとは別に証明書期限を設定した場合は2つ設定を作ることになります。
今回はHTTPを選択します。
image.png

次にLocationを選択します。
海外展開などをしている場合に、世界のとある地点からのレスポンスタイムなどを見たい場合などに有用かと思います。
今回は国内のみを想定して、Tokyoにします。
image.png

次にしきい値とレスポンスBODYに含まれる監視対象の文字列を設定します。
ステータスは200でも文字列が含まれないようなアラートに対応可能です。
ここは期待する値なので、通常ステータス200、およびlancersという文字列が返ってくることを期待した設定です。
3分間で1回失敗したら、アラートが通知されます。
image.png

最後は今までと同様のメッセージを設定すればOKです。

ダッシュボード

ダッシュボードは、デフォルトでもpresetとして基本的なものは既に存在しています。
image.png

特定のロールや特定のサービスごとの全体の負荷状況を見たい場合、自分でダッシュボードを作成すると俯瞰して見ることが可能です。
そこでざっくりとした作成手順を記載します。

まず、DashboardからNew dashboardを選択し、New Timeboardを選択します。
image.png

たくさんのウィジェットが存在しますが、Timeseriesをドラッグアンドドロップします。
image.png

Monitorを設定したのと同様に、avg byをhostにすることでホスト単位のメトリクスになります。
また、fromでroleを指定してあげることで特定のrole単位のメトリクスになります。
screenshot_2019-12-06_20_51_04.png

DisplayやColorを変更することで、各メトリクスにあわせて分かりやすい表示（積み上げグラフ、棒グラフ、線グラフなど）へ変更することも出来ます。
screenshot 2019-12-06 20.53.29.png

最後にタイトルを書いてあげればOKです。
screenshot_2019-12-06_20_55_16.png

それらを組み合わせると下記のようなダッシュボードが作成できます。
screenshot_2019-12-06_20_57_00.png

まとめ

Datadogのごくごく基本的な監視設定とダッシュボードについてまとめてみました。
既に沢山の先人たちが設定については公開してくれていますが、まとまった記事を見かけなかったので今回振り返りも兼ねてまとめてみました。
幾つかのメトリクスをまとめたダッシュボードを作成しただけで、沢山の情報が俯瞰して見られて大変便利です。
また、Datadogが他のサービスには無い良さとしては、APMもまとめて監視出来る点が大きいです。
APMやインフラに必要な監視は別々のサービスであること多いので、今までは正直APMの日々のメトリクスモニタリングが疎かになっていた部分がありましたが、1つのツールで見られるようになったことで、積極的にモニタリングを行っていこうという意識になります。

これから、どんどんDatadogを活用していき、サービス改善につなげていければと思います。

それでは、より良いモニタリングライフを！