Datadog基本のキ

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

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

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

環境

• AWS EC2(Amazon Linux)

AWS Integrationsをインストールする

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

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

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

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

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

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

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

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

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

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

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

Ansible

tasks/main.yml

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

tags:
- env:{{ env_value }}

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

handlers/main.yml

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から下記設定を行います。

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

監視/通知設定

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

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

CPU監視

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

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

ここで重要なのは、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を選択して、下記を設定します。

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

ディスク監視

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

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

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

ホストステータス監視

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

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

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

プロセス監視

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

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

cp conf.yaml.example conf.yaml

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

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でプロセス監視が行われているか確認してください。

----------------
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を選択して、下記を設定します。

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

次に対象のインスタンスを指定します。

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

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

外形監視

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

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

まず、New API Testを選択します。

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

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

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

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

ダッシュボード

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

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

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

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

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

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

最後にタイトルを書いてあげればOKです。

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

まとめ

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

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

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