Datadogの使い方｜アカウント作成からAgent導入と最初の監視までの手順

Datadogは左メニューだけで20項目近くあり、アカウントを作った直後に何から触ればよいか迷いやすいツールです。手が止まるのは操作ではなく、サイトをどれにするか、1台目をどこに入れるか、どのモニターを最初に置くかという順序の判断にあります。2026年8月時点の公式ドキュメントとトライアル案内の記載をもとに、アカウント作成から最初のアラートが鳴るまでを一本の手順として並べます。

まとめ：Datadogを使い始める初日の作業順序と最初に作る監視

初日にやることは3つに絞れます。アカウント作成時にサイトを選ぶ、検証用の1台にAgentを入れてホスト一覧へ出ることを確認する、ホスト死活のモニターを1本だけ作る。ここまで通れば、以降はインテグレーションを足していく反復作業に変わります。

この順序にする理由は切り分けです。最初からログもAPMもまとめて有効にすると、画面に何も出ないときの原因がAgentなのか、サイト指定なのか、アプリ側の計装なのか判別できなくなります。1台・1経路ずつ通してから横へ広げると、詰まった箇所がその場で分かる。

無料トライアルは14日間、クレジットカード不要です（2026-08-15時点・Datadog公式のトライアル案内）。この2週間を全機能の見物に使うと、何も判断できないまま期限が来ます。自社の本番に近い構成を1系統だけ通し、費用が読めるかどうかを見る。機能の習得より課金単位の当たりを付けるほうが、後の意思決定で効いてきます。

アカウント作成前に決めるサイト選択と無料トライアル14日間の作業配分

サインアップ画面で入力するのはメールアドレスと会社情報ですが、その裏で決まっているものがあります。データの保管先となるサイトです。ここは後から気軽に切り替えられる設定ではないため、作成前に決めておく必要があります。

日本国内で使うならAP1、既存基盤に合わせるならUS1という選び方

Datadogは地域ごとに独立したサイトを持ち、公式のサイト一覧には9つが記載されています（2026-08-15時点）。日本向けはAP1で、URLはap1.datadoghq.com。既定として案内されることが多いUS1はapp.datadoghq.comです。

選び方の基準は2つです。監視対象のデータに国内保管の要件が掛かるならAP1。海外拠点や既存の別テナントと同じ画面で見たい事情があるならそちらに合わせる。サイトが違うアカウント同士は同じダッシュボードで並べられないため、後から2つ目を作ると分断が固定されます。サイトはAgentの送信先そのものでもあり、AP1のアカウントにUS1向けの手順でAgentを入れると、エラーらしいエラーが出ないまま画面に何も現れません。

無料トライアル14日間を検証に充てる場合の作業配分と確認の優先順位

14日間は、機能を一周するには短く、判断材料を集めるには足ります。配分としては、最初の3日で1台の疎通とダッシュボード表示まで、次の1週間で本番相当の台数へ広げて流量を測る、残りで費用の見積もりを立てる。この形なら期限内に採否を判断できます。

優先して確認したいのは、自社が必要とするインテグレーションが揃っているかです。公式が案内するインテグレーションは1,000以上あり、主要なミドルウェアやクラウドサービスはおおむね含まれます。社内固有のバッチやレガシーな業務システムは対象外で、その場合はカスタムメトリクスとして自前で送る設計になります。

逆に、ダッシュボードの見た目や通知文面の調整、権限ロールの細分化は契約後にいくらでも直せる領域で、14日を消費する価値は薄い。製品としての守備範囲を先に押さえたい場合はDatadogとは何かで機能の全体像を確認してから触り始めると、画面の迷子になりにくくなります。

APIキーとアプリケーションキーの発行手順と初期段階での権限分離

Datadogには性質の異なる2種類のキーがあります。Agentやインテグレーションがデータを送るために使うAPIキーと、APIから読み取り・操作を行うために使うアプリケーションキー。前者は組織に紐づき、後者は発行したユーザーに紐づきます。

初期段階でやっておくと後が楽なのは、用途ごとにAPIキーを分けることです。Agent配布用、CI連携用、検証環境用。1本を全用途で使い回すと、漏洩時に全経路を止めることになります。キー名に用途が分かる文字列を入れておくと、半年後に「これは何のキーか」を調べる時間が消えます。

アプリケーションキーは、発行者が退職や異動で無効化されると、そのキーで動く自動化も止まります。個人アカウントではなくサービスアカウント側で発行するのが定石です。キーを使ったモニターやダッシュボードの操作をコード側から回す構成はDatadog APIの実装手順にまとめています。

Agent導入からホスト一覧に表示されるまでの最短経路と詰まる箇所

アカウントができたら次はAgentです。Agentは監視対象に常駐し、ホストからイベントとメトリクスを集めてDatadogへ送るプロセスで、最新のメジャーバージョンは7系（2026-08-15時点の公式ドキュメント記載）。ここでの目標は「Infrastructure Listに1台出る」ところまでです。

インストール方式4系統のうち検証の1台目に選ぶべき方式と判断基準

公式ドキュメントはインストール方式を4つのカテゴリで整理しています。この分類を知っておくと、自社環境に対応する手順ページへ最短でたどり着けます。

1台目にはホストベースを選んでください。失敗したときに見る場所が少ないからです。設定ファイルもログもホスト内で完結し、プロセスの稼働を直接確認できます。KubernetesのDaemonSetから始めると、Agentの問題なのかクラスタ側の権限やネットワークポリシーの問題なのかを最初の1回で切り分けられません。構成管理ツールへの組み込みは、手作業で1台通した後の展開フェーズの話です。各方式の設定ファイルの位置や環境変数の対応関係といった実装の詳細はDatadog Agent導入の実装手順で扱っています。

データが1件も届かないときにsiteとForwarderから見る確認順序

インストールコマンドは通ったのに画面に何も出ない。使い始めで最も多い状況です。原因の候補は多くないので、影響範囲の広い順に潰します。

1. Agentのプロセスが起動しているか
2. サイト指定が自社アカウントの地域と一致しているか
3. APIキーが有効で、正しく設定に入っているか
4. 送信先への通信がプロキシやセキュリティグループで遮られていないか
5. 個別インテグレーションの接続情報や権限が正しいか

2番目を3番目より先に置いているのは、サイトの取り違えが最も気付きにくい失敗だからです。AP1のアカウントにUS1向けのコマンドを実行しても、Agentは正常に起動しログにも決定的なエラーが残らず、データだけが別のリージョンへ飛びます。Agentの状態確認コマンドでForwarderの送信が失敗していれば原因は共通部分、Forwarderは成功しているのに特定のチェックだけ落ちていればそのインテグレーションの設定に絞り込めます。

Infrastructure・Logs・APM各画面を触る順序と最初に見る箇所

Agentが1台つながると、左メニューの各画面にデータが入り始めます。全部を順に開くと情報量に押し流されるため、見る順番を固定します。

Infrastructure ListとHost Mapで確認する台数とタグの整合

最初に開くのはInfrastructure Listです。Agentを入れたホストが一覧に並び、最終報告時刻とAgentのバージョン、付与されているタグが確認できます。ここで見るのは見栄えではなく2点だけ。想定した台数が出ているか、タグが意図どおり付いているか。

台数が合わないなら、足りていないホストではAgentが起動していないか送信先が違います。Host Mapに切り替えるとホストを色と大きさで並べた図で見られるため、数十台規模で「1台だけ報告が止まっている」状況を見つけやすくなります。

タグの確認をこの段階で必ず入れてください。envやserviceといったタグは、後のダッシュボードの絞り込みにもモニターの対象指定にも使われます。数台の段階で規則を直すのは数分の作業ですが、100台に配った後で直すと構成管理のテンプレートから全台再配布になります。タグの命名規約をどう組むかはDatadog運用のベストプラクティスで整理しました。

Metrics Explorerで指標を探しダッシュボードへ固定するまでの流れ

次はMetrics Explorerです。収集されているメトリクスを名前で検索し、タグで絞り込み、グラフとして描いて確かめる画面で、Datadogでの作業の起点になります。ホストのCPU使用率やメモリ使用量は、Agentを入れた時点で追加設定なく流れています。

使い方の勘所は、探索と常設を分けることです。Metrics Explorerは仮説を確かめる場所で、毎日見る指標はここで探した後にダッシュボードへ固定します。Datadogには主要なインテグレーションごとに既製のダッシュボードが用意されており、Agentでインテグレーションを有効化すると自動で使える状態になります。まずは既製のものを開き、足りない指標だけを自作のダッシュボードに足す順序が早い。

LogsとAPMを後から開く前提にする理由と有効化する際の前提条件

LogsとAPMは、Agentを入れただけでは何も表示されません。公式ドキュメントの記載でも、Agentが既定で集めるのはホストのイベントとメトリクスであり、ログ収集・トレース・プロセス監視は個別に有効化する扱いです。空の画面を見て「入っていない」と誤解しやすい箇所でもあります。

ログを有効にする前に決めておくのは、何を送らないかです。全コンテナ・全ファイルを無条件に送ると、ビルドログやデバッグ出力まで取り込まれます。収集対象を絞る指定を先に入れてから有効化してください。

APMはさらに前提が増えます。アプリケーション側にトレーサを組み込む計装作業が必要で、Agent側の受信設定だけでは1本もスパンが届きません。言語ごとのライブラリ導入とサンプリング設定を含む手順はDatadog APM導入の実装手順にまとめています。使い始めの2週間でここまで踏み込む必要はなく、インフラ側の可視化が安定してからで間に合います。

最初に作る監視3点セットと通知先を決めるときの実務上の判断基準

画面が見えるようになっても、それは監視ではありません。人が見ていないときに知らせてくれる仕組みを置いて初めて運用に載ります。最初に作るのは3本、加えて通知の運び先を決めます。

ホスト死活：Agentからの応答が途切れた状態を拾うモニター設定

1本目はホストの死活です。Datadogにはホストからの報告が途絶えたことを検知する種類のモニターがあり、対象をタグで指定して作ります。個別のホスト名で作らずenv:productionのようなタグで指定しておくと、サーバが増えたときにモニターを作り直す手間が消えます。

判定までの待ち時間は、短すぎると再起動やネットワークの瞬断で鳴り、長すぎると障害の発覚が遅れます。運用の実感としては、定期メンテナンスで数分の再起動が入る環境なら10分前後、常時稼働が前提の環境なら5分程度から始めて、誤報の頻度を見ながら調整する形が扱いやすい。

このモニターはDatadog自体の健全性チェックも兼ねます。Agentが止まればメトリクスもログもトレースも同時に途絶え、他のどのモニターも鳴らなくなる。死活を1本目に置くのは、監視の空白に気付ける仕組みを先に用意するためです。

ディスク使用率：閾値を80%と90%の二段に分ける実務上の理由

2本目はディスク使用率です。CPUやメモリより先にこちらを置く理由は、ディスク枯渇が復旧に時間の掛かる障害だからです。CPU高負荷はプロセスを止めれば戻りますが、ログで埋まったディスクは削除対象の特定から始まります。

閾値は一段ではなく二段に分けます。80%で警告、90%で重大。この分け方には運用上の意味があり、警告のうちは翌営業日の対応で構わないが、重大なら夜間でも動くという判断を閾値そのものに埋め込めます。単一の閾値で作ると、鳴った瞬間に「今すぐ起きるべきか」を人が毎回判断することになります。

外形監視：利用者側から落ちたことを検知する1本を置く場所と頻度

3本目は外形監視です。サーバのメトリクスが正常でも、利用者からアクセスできない状態は起こります。ロードバランサの設定ミス、証明書の期限切れ、DNSの障害。いずれもホスト側の指標には現れません。

置く場所は、サービスの中で最も業務の中心に近い1本です。トップページではなくログイン後の主要画面、あるいはヘルスチェック用のエンドポイント。到達可否だけでなく、想定した文字列が応答に含まれるかまで判定条件に入れると、200を返しながら中身が壊れている状態も拾えます。

実行頻度は1分間隔から始める必要はありません。5分間隔でも障害の発覚は十分早く、実行回数が課金に効くため本数を増やしたときの費用も読めます。Syntheticsで種別と頻度をどう決めるかは、テストの作り分けと頻度設計の手順にまとめています。

通知先とミュート：夜間に鳴らす条件を導入時に決めておく運用設計

モニターを作る前に決めておきたいのが通知先です。全部をメールに送ると誰も見なくなり、全部をチャットのメンションに送ると夜中に人が起きます。使い始めの段階では、警告レベルはチャットのチャンネルへ、重大レベルだけを当番の呼び出しへ、という2経路で足ります。

同時に決めるのがミュートの運用です。計画メンテナンスのたびにモニターを止めて戻し忘れる事故は必ず起きます。Datadogには対象や期間を指定して通知を抑止する仕組みがあり、期限付きで掛けられます。無期限のミュートを許すと監視が静かに死ぬため、「期限なしのミュートは作らない」を最初のルールにしておく。

通知文面の作り込みは後回しで構いません。ただし、どのホストのどのモニターが鳴ったかが1行目で分かる状態にはしておく。アラートの設計と絞り込みを本格的に組む段階の考え方はDatadog運用のベストプラクティスで扱っています。

使い始めの1か月で費用が膨らむ入口と初期設定で止めておく判断基準

ここは言い切ります。Datadogで請求が想定を超える原因は、機能を使いすぎたからではなく、初期設定で絞りを入れなかったからです。膨張の入口は限られており、最初の1か月で塞げます。

カスタムメトリクスとログのインデックスという2つの費用膨張要因

膨張要因の大半はこの2つに集約されます。カスタムメトリクスは、タグの組み合わせごとに別々の系列として数えられる仕組みです。ユーザーIDやリクエストIDのように値の種類が多いものをタグに入れると、系列数が組み合わせ爆発を起こします。1つのメトリクスのつもりが数万系列になっている、という状況はここから生まれます。

ログはもう一段分かりやすく、取り込んだ量と、検索できる状態で保持するインデックスの量で費用が決まります。取り込みは安く、インデックスは高い。したがって「全部取り込むが、検索対象にするのは絞る」という設計が成り立ちます。除外フィルタで大量に出るアクセスログを検索対象から外し、エラーレベルだけをインデックスするといった構成です。

使い始めから完璧な設計は不要ですが、値の種類が多いタグをメトリクスに付けないことと、ログを全インデックスしないことの2点は初日から守ってください。課金単位ごとにどこで費用が積み上がるかはDatadogの料金体系と費用が膨らむ課金単位に整理しています。

最初は入れないと決めてよい機能と、後から足すときの優先順序の基準

導入初期に手を出さなくてよい機能を挙げます。データベースモニタリング、Cloud SIEM、エラートラッキング、LLMの可観測性。いずれも価値はありますが、インフラの可視化とアラートが安定する前に並行して入れると、費用も設定も同時に膨らみます。

足す順序の基準は「今困っていること」に対応させることです。障害の原因究明に時間が掛かっているならAPM。ユーザーからの体感が悪いという申告が続くならRUM。DBのスロークエリが慢性化しているならデータベースモニタリング。困りごとが特定できていない段階で機能を増やしても、見ない画面が増えるだけです。

小規模構成でDatadogの導入自体を見送ってよい3つの具体的な条件

導入しないほうがよい場面も明示します。1つ目は、監視対象がサーバ1〜2台で、クラウド事業者の標準的な監視サービスで足りている場合です。設定と学習のコストは規模に比例しないため、既存の監視で困っていないなら移す理由が薄い。

2つ目は、アラートを受け取って動く人がいない場合です。監視ツールは通知の先に対応する体制があって初めて価値が出ます。担当者が1人で夜間の呼び出しに応じられないなら、まず外形監視だけを別サービスで置き、体制ができてから広げる。

3つ目は、システムがほぼマネージドサービスだけで構成され、自前のプロセスが存在しない場合です。Agentを常駐させる先がなく、クラウド側のインテグレーション連携だけで見える範囲に留まるなら、Datadogでなければ得られない情報は限られます。逆に、複数のクラウドとオンプレが混在し、メトリクスとログとトレースを1画面で突き合わせたいなら投資に見合う。監視基盤の設計から運用体制の立ち上げまで社内の手が足りない場合は、保守運用・内製化支援のように外部と組んで型を作る選択肢もあります。

よくある質問：Datadogの使い方と初期設定でつまずきやすい点

使い始めの段階で問い合わせが多い項目を、公式ドキュメントの記載と実務上の判断に分けて答えます。

Datadogは無料で使えますか？

14日間の無料トライアルが用意されており、クレジットカードの登録なしで開始できます（2026-08-15時点・公式のトライアル案内）。トライアル終了後も一部機能に無料枠の設定がありますが、本番運用の規模では有料プランが前提になります。トライアル期間中は全機能を触るより、本番に近い1系統を通して費用の当たりを付ける使い方が判断に直結します。

アカウント作成時のサイトはどれを選べばよいですか？

公式のサイト一覧には9つが記載されており、日本向けはAP1（ap1.datadoghq.com）です（2026-08-15時点）。データの国内保管が要件ならAP1、海外拠点や既存テナントと同じ画面で見たいならそちらに合わせます。サイトが異なるアカウント同士はダッシュボードを共有できず、Agentの送信先も変わります。

Agentを入れたのに画面へ何も表示されないときは何を見ますか？

サイト指定から確認してください。AP1のアカウントにUS1向けの手順でインストールすると、Agentは正常に起動しログにも明確なエラーが出ないまま、データだけが別のリージョンへ送られます。次にAgentの状態確認コマンドでForwarderの送信結果を見れば、原因が共通部分か個別の設定かを切り分けられます。

ログやAPMはAgentを入れれば自動で見られますか？

見られません。Agentが既定で集めるのはホストのイベントとメトリクスで、ログ収集・トレース・プロセス監視はそれぞれ有効化が必要です（公式ドキュメント記載・2026-08-15時点）。特にAPMはアプリケーション側にトレーサを組み込む計装作業が前提になります。ログを有効にする際は、収集対象を絞る指定を先に入れてから広げてください。

最初に作るべきモニターは何本くらいですか？

3本で足ります。ホストの死活、ディスク使用率、外形監視の1本。この3つで「サーバが落ちた」「ディスクが埋まる」「利用者からアクセスできない」という頻度の高い障害を拾えます。CPUやメモリは実際に鳴った経験を踏まえて閾値を決めるほうが誤報を減らせるため、数週間運用してから追加する順序が扱いやすい。

関連記事

• Datadog Agent導入の実装手順：本記事で1台通した後、ホスト・Docker・DaemonSetの各方式へ展開する詳細手順です。
• Datadog運用のベストプラクティス：タグ設計・監視対象の絞り込み・アラート設計・コスト抑制という運用の型をまとめています。
• Datadog RUM導入の実装手順：外形監視の次に利用者側の体感を計測する段階で使うブラウザSDKの導入手順です。
• datadog-ciの導入と使い分け：CI/CDパイプラインからDatadogへ情報を送る段階で使うコマンドラインツールを扱っています。
• Datadog OpenTelemetry連携の4方式：Agent経由で送るかOTLPで直接送るかという送信経路の選び分けを整理しています。