はじめに
こんにちは。
先日、Datadogの認定試験である
Datadog Log Management Fundamentals
を受験し、無事合格しました！
今回は、これから受験される方のために、
- 当日までに実際にやった対策
- 試験を受けてみて感じたリアルな所感
- 技術的なハマりポイント
についてまとめました。
受験者のバックグラウンド
受験時の筆者のスキルについてです。
- 監視・運用を主軸としたエンジニア
- Datadog のログ・メトリクス・APM を利用
- 認定試験「Datadog Fundamentals」合格済み
「Datadog 完全初心者」ではありませんが、「Datadogのプロ」と名乗れるほどでもない……という立ち位置です。
だからこそ、自分の知識はベストプラクティスに沿っているかを確認する良い機会だと思い受験をしました。
当日までにやった勉強法
試験対策として実施したのは、主に以下の3点です。
1. 公式ラーニングパスを一通り実施
Datadog Learning Center: Log Management Fundamentals
Datadog公式が用意している、本試験を受験する方向けのハンズオンです。
結果的に、これをちゃんとやることが一番の近道かもしれないと感じました。試験範囲が体系的に網羅されています。
2. 公式模試
Practice Exam
Datadog公式が用意している、全25問の公式模試です。
慣れない英語試験ということもあり、ここで試験の全体感を掴めたのが良かったです。
3. 問題集（Udemy）
Datadogの試験3つを対策できる全部入り問題集（Ultimate Practice Tests）を活用しました。
ただ、正直なところUdemyと似たような問題は、本番ではあまり出なかったという印象です。
丸暗記ではなく、解説を読んで理解を深める用途で使うのがおすすめです。
実際に受けてみた所感
試験時間は2時間、問題数は90問です。
実際に受けてみて感じた感想を挙げておきます。
- 基本3択なのはありがたい
選択肢が少ないので、消去法で絞り込みやすいです。 - 英語はシンプル
問題文は短く、長くても2〜3行程度。複雑な表現も少なめでした。 - 「スコア対象外」の問題に注意
90問中15問は採点対象外が含まれています。合計90問解くことになるので、時間配分には注意が必要です。 - 合格ラインは62%（47/75問）
数字だけ見ると低く感じますが、油断していると足元をすくわれます。 - Pipeline や Grok が意外と出る
個人的にノーマークだった Pipeline の詳細設定や Grok パース周りが結構聞かれました。ここを勉強しておけばもっと楽だったかもしれません。 - UI操作の経験が活きる
「コンソールを触っていれば即答できる」という問題がありました（例：この操作をするとどんなログが見えるか？など）。座学だけでなく実機に触れることの重要性を感じました。
試験対策：ここだけは押さえたい技術ポイント
ここからは、試験中や勉強中に「これは整理しておかないと間違えるな」と感じた技術的な要点をまとめます。
1. Log Explorer のクエリ構文
実務でなんとなく検索していると忘れがちですが、構文の基本は押さえておきましょう。
- タグ検索：
env:prod - 属性（Facet）検索：
@http-status:200 - 全文検索：
”error” - 除外検索：
-env:prod（マイナスを付ける）
2. ログ処理の流れ（Log Flow）
ログが生成されてから閲覧できるようになるまでの流れは非常に重要です。
- Agent：
exclude_at_match等でフィルタリング - Ingestion：Datadog側へ送信
- Processing：Pipeline でのパース（Grok）、共通属性への加工
- Indexing：Exclusionフィルターでの除外、インデックスへの保存
- Archive：S3等へのアーカイブ
「どの段階でログを捨てるのがコスト最適か？」といった問いに答えるために必須の知識です。
3. include / exclude / mask の使い分け
我々エンジニアは、障害調査のために「とりあえずログは全部出しておこう」「debugログもないと不安」と考えがちです。
しかし、Datadogのベストプラクティスは
- 「そのログ、本当にインデックス（課金）する必要ある？」
- 「メトリクスに変換したらログ本体は捨ててよくない？」
- 「ノイズを送ってくるな、Agent側でフィルタしろ」
それらの使い分けを表にしました。
| 設定名 | 動作 | 使いどころ |
|---|---|---|
| include_at_match | 一致したものだけ送る | ノイズが多い環境で、必要なログだけをホワイトリスト形式で送りたい時 |
| exclude_at_match | 一致したものを捨てる | HealthcheckやDebugなど、不要なログが明確な時 |
| mask_sequences | 一部を伏字にする | 機密情報（クレカ・トークン）を保護したい時 ※ログ自体は送られます |
4. Saved View / Monitor / Metric の使い分け
収集したログを「どう使いたいか」によって、作成すべきリソースが異なります。
- みんなで同じ画面を見たい → Saved View
（チームへの共有、監査用。あくまで「見る」だけ） - Slackに通知飛ばして叩き起こしてほしい → Log Monitor
（緊急対応が必要。気づくため） - ログの件数や値の傾向を追いたい→ Generate Metric
（ログとして残すと高いし消えるから、数字（メトリクス）に変換して長期保存。追うため）
特に「長期傾向分析（Trend）」という単語が出たら、「Metric」が第一候補です。
5. コンソール操作とトラブルシューティング
トラブルシューティングの観点も問われました。
- Live Tail にはあるのに Log Explorer (Index) にない
→ Exclusion Filter でインデックスから除外されている可能性が高い。 - コンテナのログが飛んでこない
→ Agentの設定不備や権限周りを確認。 - ログのコストが高すぎる
→ どの段階で除外すべきか、Indexの保持期間（Retention）は見合っているか。
おわりに
Datadog Log Management Fundamentals は、単なる機能暗記の試験ではなく、
「Datadog が考えるログ運用のベストプラクティス」
を理解しているかどうかが問われる試験でした。
これから受験される方は、公式ドキュメントやラーニングパスをベースにしつつ、実際にコンソールを触って「ログの流れ」をイメージできるようにしておくと合格に近づくと思います。
この記事が、これから受験される方の参考になれば幸いです。
簡単30秒