Datadog Fundamentals 認定 / 02 / 06
インフラの準備と Agent の導入
このドメインで学ぶこと
このドメインでは、Datadog にデータを送る土台を作る手順を学びます。具体的には、ホストやコンテナに Datadog Agent をインストールする経路 (Fleet Automation のアプリ内手順、Docker、Kubernetes、構成管理ツール)、Agent が送信に使う API キーとプログラム API 用の Application キーの役割の違い、Agent の起動・停止・状態確認のコマンド、そして Agent が自分のホスト名をどう決めるかの規則です。試験では「この場面でどのキーを使うか」「設定ファイルはどこにあるか」「コンテナで API キーをどう渡すか」「複数の候補からどのホスト名が採用されるか」のように、実務の一場面を切り取った形で問われます。数値や既定値は 2026 年 9 月時点の公式ドキュメントに基づきます。
公式ガイドの内容範囲
- Agent のインストール
- API キー
- Application キー
- Agent の実行
- Agent のホスト名
重要ポイント
- Datadog Agent はホスト上で動くオープンソースのソフトウェアで、メトリクスとイベントを収集して Datadog に送信する。
- API キーは組織に固有で Agent の送信に必須。Application キーはユーザーに紐づき、API キーと組み合わせてプログラム API にアクセスする。
- 組織の API キーは既定で最大 50 個まで作成でき、失効させたキーは 7 日以内なら復元できる。
- ブラウザやモバイルアプリからの送信には API キーではなくクライアントトークンを使う。API キーはクライアント側に露出させてはならない。
- Linux の主設定ファイルは /etc/datadog-agent/datadog.yaml、インテグレーション設定は同じ場所の conf.d/ に置く。
- Docker で Agent を動かすときは DD_API_KEY 環境変数が必須で、DD_SITE で送信先サイトを指定する (既定は datadoghq.com)。
- Linux では systemctl で datadog-agent サービスを起動・停止・再起動し、datadog-agent status で状態を確認する。
- Agent の正規ホスト名は、設定ファイルで明示した名前、DNS ホスト名、EC2 のインスタンス ID の順で最初に条件を満たしたものが採用される。
- Datadog のサイト (US1 / EU1 / AP1 など) は互いに独立しており、Agent の site パラメータを自分の組織のサイトに合わせる必要がある。
用語と概念
Datadog Agent
監視対象のホストやコンテナ上で動作し、CPU やメモリなどのシステムメトリクス、イベント、ログ、トレースを収集して Datadog に送るソフトウェアです。ソースコードは GitHub の datadog-agent リポジトリで公開されています。クラウド事業者の外部監視は数分間隔のサンプリングですが、Agent はホストの内側から 15 秒ごとに統計を集めるため、より細かい粒度で状況を把握できます。Agent レベルで付けたタグは、その Agent が送る全てのメトリクス、ログ、トレースに付きます。Datadog は少なくとも月に 1 回の更新を推奨しています。
- Datadog Agent製品
- ホスト用語
インストール経路と Fleet Automation
Agent の導入には、Datadog アプリ内の手順 (Fleet Automation) で生成したスクリプトをホストで実行する方法が推奨されています。Kubernetes では Helm チャートや Datadog Operator、構成管理では Ansible、Chef、Puppet、SaltStack などが使えます。Fleet Automation は導入だけでなく、稼働中の Agent の一覧、バージョン、設定の履歴、リモートでの更新、API キーの使用状況の監査までを一つの画面から扱えます。通常は完全な Agent のインストールが推奨されます。
API キー
組織 (org) に固有の認証情報で、Agent がメトリクスやイベントを Datadog に送信するときに必要です。組織には最低 1 個の API キーが必要で、既定では最大 50 個まで作成できます。キー名は組織内で一意でなければなりません。デプロイ手段ごとに別の API キーを用意しておくと、漏えい時にそのキーだけを失効させて影響範囲を絞れます。失効させた API キーは 7 日間「Revoked」状態で残り、その間なら元の値のまま復元できます。作成したユーザーが無効化されても API キー自体は有効なまま残る点が Application キーとの違いです。
Application キーとスコープ
組織の API キーと組み合わせて、ダッシュボードやモニターの作成などプログラム API を呼び出すための鍵です。作成したユーザーアカウントに紐づき、既定ではそのユーザーと同じ権限を持ちます。必要最小限の権限だけに絞る「スコープ」を指定するのが推奨で、スコープ名は大文字小文字を区別します。ユーザーが無効化されると、そのユーザーが作った Application キーは失効します。ユーザー間で移譲することはできないため、チームで共有する鍵が必要なときはサービスアカウントで発行します。One-Time Read モードが有効な組織では、秘密の値は作成時に一度しか表示されません。
クライアントトークン
ブラウザ、モバイル、TV アプリのようにエンドユーザーの端末で動くアプリから Datadog にデータを送るための認証情報です。API キーは利用者側に露出してしまうため、こうした用途には使えません。RUM やブラウザ、Android、iOS などのログ収集ライブラリがクライアントトークンを使います。クライアントトークンも組織に固有で、Organization Settings の Client Tokens タブで管理します。API キーと違い、削除したクライアントトークンには復元の猶予期間がありません。作成したユーザーが無効化されても有効なまま残ります。
設定ファイル datadog.yaml と conf.d
Agent 全体の接続設定 (api_key、site、proxy など) を持つ主設定ファイルが datadog.yaml です。場所は OS で異なり、Linux は /etc/datadog-agent/、macOS は /opt/datadog-agent/etc/、Windows は %ProgramData%\Datadog\ 配下です。各インテグレーションの設定は conf.d の <チェック名>.d/ フォルダーに置き、conf.yaml.example を conf.yaml に改名して有効化します。コンテナでは DD_ で始まる環境変数で渡します。
Agent の起動と状態確認
Linux では sudo systemctl start / stop / restart datadog-agent でサービスを操作し、sudo datadog-agent status で状態ページを表示します。Agent 6 以降はサブコマンド方式で、hostname、configcheck、diagnose、flare、version などがあります。Agent Manager GUI は Windows と macOS で既定有効 (ポート 5002、ローカルホストのみ)、Linux では既定で無効です。
Datadog サイトと site パラメータ
Datadog は US1 (datadoghq.com)、US3、US5、EU1 (datadoghq.eu)、AP1 (ap1.datadoghq.com、日本)、AP2、UK1、政府向けサイトなど、地域ごとに独立したサイトを運営しています。サイト間でデータは共有されないため、Agent の site パラメータ (Docker では DD_SITE) を自分の組織のサイトに合わせないとデータは届きません。既定値は datadoghq.com (US1) です。自分の組織のサイトは Datadog アプリの My Preferences ページ上部で確認できます。
ホスト名の決定規則
Agent は設定ファイルの hostname、DNS ホスト名、EC2 のインスタンス ID など複数の候補を集め、次の順で最初に条件を満たしたものを正規ホスト名にします。第 1 に設定ファイルで明示したホスト名 (ip- や domu で始まらないこと)、第 2 に DNS ホスト名 (EC2 の既定名 ip-… でないこと)、第 3 に EC2 のインスタンス ID、第 4 に EC2 既定名であっても DNS ホスト名です。localhost.localdomain のような一意でない名前は不採用となり次の規則に進みます。
ホストエイリアスと hostname_fqdn
正規ホスト名に選ばれなかった候補名は、そのホストのエイリアスとして登録されます。エイリアスは Infrastructure List の inspect パネルで見られますが、検索やフィルタには使えません。Agent v5 は hostname -f で FQDN を取得していましたが、v6 以降は OS の API で短いホスト名を得るため、更新で表示名が変わることがあります。v6.3 で追加された hostname_fqdn を true にすると v5 と同じ FQDN の挙動に戻せます (既定は false)。コンテナでは DD_HOSTNAME 環境変数で明示できます。
理解度チェック
学んだ内容を 5 問で確認します