2026年10月16日

2026年10月16日

Datadog AgentのLinux設定方法|datadog.yamlの基本・Nginx/MySQL連携・ログ収集・動作確認

Datadog Agent は、Linux にインストールしたあと /etc/datadog-agent/datadog.yaml で全体の設定を、conf.d 配下のファイルで Nginx や MySQL などの連携(インテグレーション)を設定します。この記事では、インストール時の注意点、datadog.yaml で最初に決めておく項目、WordPress サーバーでよく使う Nginx・MySQL の連携、ログ収集、そして設定が効いているかを確かめるコマンドまでを、Linux 側の作業に絞って説明します。

Agent のファイル配置を把握する

Linux 版の Agent(Agent 7 系)をパッケージで入れると、主に次の場所を使います(2026年10月現在)。

  • /etc/datadog-agent/datadog.yaml:API キー、送信先サイト、ホスト名、タグなど全体の設定
  • /etc/datadog-agent/conf.d/<連携名>.d/conf.yaml:各インテグレーションの設定
  • /var/log/datadog/:Agent 自身のログ
  • dd-agent:Agent が動作する専用ユーザー

設定で迷ったときは「全体のことは datadog.yaml、個別のソフトウェアのことは conf.d」と覚えておくと整理しやすくなります。

インストールする

Datadog の管理画面で Linux 向けのインストール手順を開くと、API キーと送信先サイトが入ったワンライナーが表示されます。形は次のようなものです。

DD_API_KEY="your-api-key" DD_SITE="ap1.datadoghq.com" \
  bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"

このスクリプトは、Datadog のパッケージリポジトリを登録して Agent をインストールし、API キーを datadog.yaml に書き込みます。インターネットから取得したスクリプトを root 権限で実行することになるため、気になる場合は先にスクリプトをダウンロードして中身を確認するか、公式ドキュメントにある手動の手順(リポジトリと署名鍵を自分で登録してから apt や dnf で入れる方法)を使います。

DD_SITE は、Datadog のアカウントを作成したリージョンに合わせます。日本のリージョン(AP1)なら ap1.datadoghq.com、米国の既定リージョンなら datadoghq.com です。ここが違うと、Agent は動いているのにデータが画面に出ない、という状態になります。自分のサイトは、ブラウザで開いている Datadog の URL から判断できます。

API キーはシェルの履歴に残るため、実行後に history -d で消すか、先頭にスペースを付けて履歴に残さない設定(HISTCONTROL=ignorespace)を使うと安全です。

datadog.yaml で最初に決める項目

インストール直後の datadog.yaml は、ほとんどの項目がコメントアウトされた長いファイルです。最初に確認・設定しておきたいのは次の項目です。

# /etc/datadog-agent/datadog.yaml(抜粋)
api_key: your-api-key
site: ap1.datadoghq.com

hostname: web01.example.com
tags:
  - env:production
  - role:web
  - service:wordpress

logs_enabled: true

process_config:
  process_collection:
    enabled: true

hostname は、指定しなければ Agent が自動で決めます。クラウドのインスタンスでは自動で決まった名前が分かりにくいことがあるので、運用で使う名前を明示しておくと画面で探しやすくなります。後から変えると、別のホストとして扱われる点に注意してください。

tags は、ダッシュボードやモニター(アラート)で絞り込むための目印です。env・service・role のように、キーと値の組で付ける規則をチーム内で揃えておくと、台数が増えても整理が崩れません。

logs_enabled はログ収集の全体スイッチで、既定では無効です。これを true にしただけではログは送られず、どのファイルを集めるかを conf.d 側で指定する必要があります。

process_collection を有効にすると、プロセスの一覧と資源の使用量を画面で確認できます。PHP-FPM のワーカーがメモリを使いすぎていないかを調べるときなどに役立ちます。

datadog.yaml には API キーが含まれるため、所有者は dd-agent、権限は 640 程度にして、他のユーザーから読めないようにします。プロキシ経由でしか外に出られないサーバーでは、proxy の項目で HTTPS プロキシを指定します。

設定を変えたら Agent を再起動します。

sudo systemctl restart datadog-agent

Nginx と連携する

Nginx の接続数やリクエスト数を取るには、Nginx の stub_status を有効にし、Agent からだけ読めるようにします。

# /etc/nginx/conf.d/status.conf
server {
    listen 127.0.0.1:81;
    location /nginx_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
        access_log off;
    }
}
sudo nginx -t && sudo systemctl reload nginx
curl http://127.0.0.1:81/nginx_status

127.0.0.1 で待ち受けているのは、状態ページを外部に公開しないためです。続いて Agent 側の設定ファイルを作ります。各連携のディレクトリには conf.yaml.example が用意されているので、それをコピーして編集すると書式を間違えにくくなります。

# /etc/datadog-agent/conf.d/nginx.d/conf.yaml
init_config:

instances:
  - nginx_status_url: http://127.0.0.1:81/nginx_status

logs:
  - type: file
    path: /var/log/nginx/access.log
    service: wordpress
    source: nginx
  - type: file
    path: /var/log/nginx/error.log
    service: wordpress
    source: nginx

source: nginx を指定すると、Datadog 側で Nginx 用のログの解析ルールが適用されます。アクセスログの形式を独自に変えている場合は、解析がうまく効かないことがあるので、画面でログが項目ごとに分かれているかを確認してください。

MySQL と連携する

MySQL(MariaDB)のメトリクスを取るには、Agent 専用の DB ユーザーを作ります。WordPress の DB ユーザーを流用せず、必要な権限だけを持つユーザーを分けるのが安全です。作業前に DB のバックアップを取っておいてください。

CREATE USER 'datadog'@'localhost' IDENTIFIED BY 'your-strong-password';
GRANT REPLICATION CLIENT ON *.* TO 'datadog'@'localhost';
GRANT PROCESS ON *.* TO 'datadog'@'localhost';
GRANT SELECT ON performance_schema.* TO 'datadog'@'localhost';
# /etc/datadog-agent/conf.d/mysql.d/conf.yaml
init_config:

instances:
  - host: 127.0.0.1
    port: 3306
    username: datadog
    password: "your-strong-password"

必要な権限は、MySQL のバージョンや使う機能(クエリの詳細な監視など)によって追加が必要になることがあるため、Datadog の MySQL インテグレーションのドキュメントで確認してください。このファイルにはパスワードが入るので、datadog.yaml と同じく dd-agent だけが読める権限にします。設定ファイルに平文で置きたくない場合は、Agent のシークレット管理機能で外部から値を読み込む方法もあります。

ログファイルの読み取り権限

ログ収集でつまずきやすいのが権限です。Agent は dd-agent ユーザーで動くため、そのユーザーが読めないログは集められません。Ubuntu の Nginx のログは adm グループで読める設定になっていることが多く、その場合は次のように dd-agent をグループに加えます。

ls -l /var/log/nginx/
sudo usermod -aG adm dd-agent
sudo systemctl restart datadog-agent

ログファイルの所有者やグループはディストリビューションや logrotate の設定で異なるので、ls -l で確かめてから対応してください。ログの権限そのものを緩めるのは避けます。

設定が効いているか確認する

Agent には、状態を調べるためのコマンドが用意されています。

sudo datadog-agent status                         # 全体の状態、各連携の成否、ログ収集の状況
sudo -u dd-agent datadog-agent configcheck        # 読み込まれた連携設定の一覧
sudo -u dd-agent datadog-agent check nginx        # 指定した連携を1回だけ実行して結果を表示
sudo tail -n 50 /var/log/datadog/agent.log        # Agent 自身のエラー

status の出力では、API キーが有効か、各チェックが OK かエラーか、ログの各ファイルが読めているかが分かります。よくある原因と確認の順番は次のとおりです。

  1. API キーやサイトの誤り:status の API キーの項目でエラーが出ます。datadog.yaml の api_key と site を見直します。
  2. YAML のインデント誤り:configcheck に連携が出てこない、または agent.log に読み込みエラーが出ます。タブ文字が混ざっていないかも確認します。
  3. 接続先や権限の誤り:check nginx や check mysql でエラー内容が表示されます。curl や mysql -u datadog -p で、Agent と同じ条件で手動接続できるかを試します。
  4. ログの権限:status のログの項目に、ファイルを開けないというエラーが出ます。前の節の権限を確認します。

Datadog のサポートに問い合わせるときは datadog-agent flare で設定やログをまとめて送れます。秘密情報は自動で伏せられる仕組みになっていますが、送信前に何が含まれるかを確認しておくと安心です。

まとめ

  • 全体の設定は /etc/datadog-agent/datadog.yaml、各ソフトウェアとの連携は conf.d/<連携名>.d/conf.yaml で行います。
  • インストール時の DD_SITE はアカウントのリージョンに合わせます。違うとデータが表示されません。
  • hostname と tags を最初に決めておくと、台数が増えても画面で整理しやすくなります。
  • Nginx は stub_status をローカル限定で公開し、MySQL は専用の DB ユーザーを最小限の権限で作ります。
  • ログ収集は logs_enabled と conf.d の logs の両方が必要で、dd-agent が読める権限かを確認します。
  • 動作確認は datadog-agent status・configcheck・check <連携名> の順に進めると原因を絞り込めます。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲