obsdog

Datadog Fundamentals 認定 / 01 / 06

コンピューティングの基礎

このドメインで学ぶこと

このドメインは Datadog 固有の機能ではなく、Agent を運用する前提となるコンピューティングの基礎知識を扱います。YAML と JSON の設定ファイルやレスポンスを読み書きすること、Linux / macOS / Windows でファイル配置と権限がどう違うかを知ること、シェルで Agent を起動・停止・診断すること、Python のカスタムチェックの意図を読み取ること、CPU・メモリ・ストレージのメトリクスの意味を理解すること、IP・TCP と UDP・HTTP の違いを Agent の通信に当てはめることが範囲です。試験では「この設定の断片は何を意味するか」「この状況で使うプロトコルはどちらか」「どのコマンドで確認するか」のように、基礎知識を運用場面に結び付けて問われます。本ページは 2026 年 9 月時点の公式ドキュメントに基づきます。

公式ガイドの内容範囲

  • 設定ファイルの編集
  • OS の基礎
  • プログラミング言語の読解 (YAML / JSON / Python / シェル)
  • ハードウェアの概念 (CPU / メモリ / ストレージ)
  • シェルの操作
  • メタデータ
  • ネットワーキングの基礎 (IP / HTTP / TCP / UDP)

重要ポイント

  • datadog.yaml の既定パスは OS で異なる。Linux は /etc/datadog-agent/、macOS は /opt/datadog-agent/etc/。
  • チェック設定は conf.d/<チェック名>.d/conf.yaml。conf.yaml.example をリネームして有効化し、サイズ 0 のファイルは無視される。
  • Agent は <チェック名>.d/ 内の有効な YAML を全て読み込む。字下げが崩れた不正な YAML は読み込まれないので、設定は分割できても書式は厳密。
  • Agent の通信は常に Agent 側から Datadog へ開始され、大半は TCP 443 の HTTPS。Datadog から Agent へは接続しない。
  • DogStatsD は既定で UDP 8125 を待ち受ける。UDP は応答を待たないため、DogStatsD が停止してもアプリの処理は中断しない。
  • 送信先ドメインは CNAME で静的 IP 群を指し、https://ip-ranges.<サイト> の JSON に CIDR 一覧がある。許可リストには全ブロックを登録する。
  • systemd 環境の再起動は sudo systemctl restart datadog-agent、状態確認は sudo datadog-agent status。
  • Agent 自身のログは Linux では /var/log/datadog/agent.log。既定では 10 MB ごとにローテーションしバックアップ 1 本を残す。
  • タグは key:value 形式が推奨で、先頭は文字、最大 200 文字、メトリクスタグは小文字に正規化される。無限に増える値をタグにしない。
  • CPU・メモリ・ストレージは Agent 同梱の System check が system.cpu.* / system.mem.* / system.fs.* で収集する。

用語と概念

YAML 設定ファイルの読み書き (datadog.yaml / conf.yaml)

Agent の設定はほぼ全て YAML です。主設定 datadog.yaml には api_key や site、proxy、既定タグなどホスト全体の接続情報を書き、各インテグレーションの設定は conf.d/<チェック名>.d/conf.yaml に init_config と instances の 2 つのキーで書きます。YAML は字下げで階層を表すため、スペースの数が揃わないだけで意図と異なる構造になります。Agent はフォルダ内の有効な YAML を全て読み込むので設定を複数ファイルに分割でき、datadog.yaml.example が書き方を調べる第一の参照先です。

OS ごとのファイル配置と実行ユーザー

同じ Agent でも OS によって配置が違います。Linux は設定が /etc/datadog-agent/、ログが /var/log/datadog/ にあり、macOS は /opt/datadog-agent/ 配下、Windows は %ProgramData%\Datadog 配下です。Linux の Agent は dd-agent ユーザーで動くため、カスタムチェックのファイルは dd-agent が読める権限が必要で、手動実行も sudo -u dd-agent で行います。パッケージを削除しても設定や dd-agent ユーザー、ログは残ります。

シェル操作と Agent のサブコマンド

Agent 6 以降のコマンドラインはサブコマンド方式で、<Agent バイナリ> <サブコマンド> <オプション> の形です。サービスの起動・停止は OS のサービス管理 (systemd なら systemctl、AIX なら startsrc / stopsrc) に任せ、Agent の状態は status、読み込まれた設定は configcheck、接続診断は diagnose、サポート送付は flare で確認します。--help で一覧を見られるので、暗記より「どこで調べるか」が実務的です。設定を編集したら再起動しないと反映されません。

JSON の読解 (ip-ranges と API レスポンス)

Datadog の API はリソース指向の URL に GET / POST / PUT / DELETE を送り、HTTP ステータスコードで成否を示し、レスポンスは常に JSON です。JSON はオブジェクトと配列の入れ子で、キーは二重引用符で囲みます。代表的な JSON が https://ip-ranges.<サイト> の IP 一覧で、version と modified の後に agents / api / apm / logs などのセクションが並び、それぞれ prefixes_ipv4 と prefixes_ipv6 に CIDR 表記の配列を持ちます。

Python カスタムチェックの読解

カスタムチェックは checks.d/<名前>.py に AgentCheck を継承したクラスを書き、check(self, instance) の中で self.gauge('メトリクス名', 値) でデータを送ります。設定は conf.d/<名前>.yaml で、ファイル名を .py と一致させます。custom_ 接頭辞が推奨され、最新 Agent では Python 3 互換が必須です。収集間隔は min_collection_interval (既定 15 秒) をインスタンス単位で指定しますが、他のチェックとキューを共有するため厳密な周期は保証されません。

ハードウェア資源の概念と System check

CPU・メモリ・ストレージは System check が収集します。CPU は system.cpu.user (ユーザー空間)・system (カーネル)・idle・iowait (IO 待ち)・stolen (仮想 CPU のハイパーバイザー待ち) を割合で表します。メモリは system.mem.total / used / usable をバイトで表し、usable は MemAvailable に相当します。ストレージは容量に加えて system.fs.inodes.in_use の inode 使用率も重要で、inode が尽きるとファイルを作れません。

メタデータとしてのタグ

タグはメトリクス・ログ・トレースに次元を追加するメタデータで、key:value 形式が推奨です。先頭は文字で始め、文字・数字・アンダースコア・マイナス・コロン・ピリオド・スラッシュが使え、それ以外はアンダースコアに変換されます。長さは key と value を合わせて最大 200 文字で、メトリクスタグは小文字に正規化されます。key は最初のコロンまでなので env:staging:east の key は env です。ホストのタグは同じホストのデータに継承されます。無限に増える値をタグにするとメトリクス数が膨らむため避けます。

ネットワーキングの基礎: IP アドレス・CIDR・DNS と許可リスト

Agent の送信先はサイトごとのドメイン名で、CNAME レコードとして静的 IP 群を指します。許可リストにはドメイン名か、https://ip-ranges.<サイト> で公開される CIDR ブロックを使います。CIDR は 192.168.1.0/24 のようにネットワーク部の長さを示す表記です。使用中の IP は入れ替わるため全ブロックを登録します。プロキシ経由にする場合は datadog.yaml の proxy か DD_PROXY_HTTPS などの環境変数を使い、no_proxy にはドメイン・CIDR・単一 IP・ホスト名を書けます。

TCP と UDP、HTTP と HTTPS の使い分け

TCP は接続を確立して到達を確認しながら送るプロトコル、UDP は接続なしで送りっ放しにするプロトコルです。Agent から Datadog への送信はほとんどが TCP 443 上の HTTPS で、失われてはならないデータを確実に届けます。一方、アプリからローカルの Agent へカスタムメトリクスを渡す DogStatsD は UDP 8125 を使い、応答を待たないのでアプリを遅らせず、DogStatsD が落ちてもアプリは止まりません。ログを TCP で直接送る方式は配送保証が無いとして非サポートで、HTTP intake が推奨です。

環境変数と設定ファイルの優先順位

Agent の多くの設定は datadog.yaml のキーと DD_ 接頭辞の環境変数の両方で指定できます。環境変数は設定ファイルの値を上書きします。ただし DD_TAGS は空白区切りなので DD_TAGS="test:this is a test" と書くと test:this、is、a、test の 4 つのタグに分裂します。空白を含む値は YAML 側で書けばアンダースコアに変換されます。コンテナで外部から DogStatsD を受けるには DD_DOGSTATSD_NON_LOCAL_TRAFFIC=true が必要です。

理解度チェック

学んだ内容を 5 問で確認します