はじめに：QAエンジニアの新たな挑戦 📝
こんにちは！QAエンジニアのAyakaです。
今年の4月にQAチームが立ち上がったばかりで、まさにゼロからチームと仕組みを構築している最中です。
私たちのチームが最初のミッションとして掲げたのが、サービス品質の可視化でした。
- 開発チームがより能動的にパフォーマンス改善に取り組めるような環境を作りたい
- 障害が起きてから受動的に動くのではなく、その予兆をデータに基づいて捉えたい
そんな思いから、Datadogの導入プロジェクトがスタートしました。
本記事では、私たちがインフラ監視からAPM、ログ収集、そしてダッシュボード完成に至るまで、数々の壁にぶつかりながらも、どのようにしてそれを乗り越えてきたのか、その全記録を共有します。
Datadogの導入を検討されている方や、同じように品質可視化に取り組む方にとって、少しでも参考になれば幸いです。
Datadog導入の冒険：立ちはだかる数々の壁 🧗
まずは、監視の土台となるインフラ、APM、ログのデータをDatadogに集めることから始めました。
しかし、この初期段階で、私たちは早速いくつかの手強い壁に直面することになります。
第1の壁：監視が止まっても自動で復旧させたい！ (IAMポリシーとの格闘)
最初に構築したのは、Datadog Agentが停止した際に自動で再起動させる仕組みです。
- Agentが5分以上停止したらアラートが飛ぶモニターを作成。
- 上記モニターをトリガーに、AWS Systems Manager (SSM) を使ってAgentを再起動する「Workflow Automation」を構築。
完璧な計画に見えましたが、設定画面でなぜか「AWS SSM」のアクションが表示されません。
調査の結果、Datadog用のIAMロールにSSMの実行権限 (ssm:SendCommand) が不足していることが判明。
「権限を追加するだけか」と安堵したのも束の間、今度はIAMポリシーの文字数制限という新たな壁が立ちはだかります。試行錯誤の末、SSM用の権限を別ポリシーに切り出してアタッチすることで、この問題を乗り越えました。基本的な設定項目こそ、慎重に確認すべきだと痛感した出来事です。
第2の壁：APMでURLがわからない！ (web.configとの格闘)
次に、テストサーバー (Windows/IIS/Blazor) にAPMを導入しました。
しかし、APMの画面で表示されるリソース名がGUID形式のID（例: 4c37d...）になってしまい、どのURLへのアクセスなのか全く判別できませんでした。
解決策は、DD_TRACE_ROUTE_TEMPLATE_RESOURCE_NAMES_ENABLED=true という環境変数の設定でした。
しかし、OSの環境変数ではなぜか反映されず…。最終的に、IISアプリケーションの web.config に直接この環境変数を記述し、アプリケーションプールをリサイクルすることで、ようやく人間が読める形式で表示されるようになりました。
<aspNetCore processPath="dotnet" arguments=".\MyApplication.dll" ...>
<environmentVariables>
<environmentVariable name="DD_TRACE_ROUTE_TEMPLATE_RESOURCE_NAMES_ENABLED" value="true" />
</environmentVariables>
</aspNetCore>
第3の壁：ログが届かない！ (設定ファイルとの格闘)
ログ収集でも、私たちは存分に回り道を経験しました。IISのアクセスログを収集するため、datadog.yamlに設定を記述したものの、一向にログが届きません。
Agentの実行ユーザーにログフォルダへの読み取り権限がなかったり、YAMLのインデントミスがあったりと、一つずつ原因を潰していきました。
最終的に、Datadogサポートの推奨に従い、conf.d/logs.d/conf.yaml という専用の設定ファイルに記述するベストプラクティスに変更したところ、あっさりとログが流れ始めました。遠回りはしましたが、結果的により良い構成を学ぶことができました。
Before/After比較：Datadogがもたらした変化 ✨
Datadog導入による変化を比較（クリックして展開）
このプロジェクトを経て、私たちのチームの動き方は大きく変わりました。
| 項目 | Before（Datadog導入前） | After（Datadog導入後） |
|---|---|---|
| 障害検知 | ユーザーからの報告や、感覚的な気づきに依存。 | Agent停止やエラー急増を自動検知し、即時通知。 |
| 原因調査 | 複数サーバーにログインし、ログをgrepする長い道のり。 | APMトレースでボトルネック箇所やエラー発生源をピンポイントで特定。 |
| 性能把握 | 「なんだか遅い気がする」という曖昧な感覚。 | レイテンシ(p95)やRPSをリアルタイムに数値で把握。 |
| 状況共有 | 口頭や文章での複雑な説明が必要。 | 共通のダッシュボードを見て、全員が同じ状況を瞬時に理解。 |
Datadogとの奮闘で得たもの：学びと心得 💪
今回のプロジェクトを通して、技術的な知見だけでなく、多くの学びがありました。
-
「動かない」には必ず理由がある
権限、設定のわずかな記述ミス、推奨される構成など、基本に立ち返ることの重要性を学びました。 -
公式ドキュメントとサポートは最高の味方
一人で悩まず、公式な情報源を頼ることが、結果的に解決への一番の近道でした。 -
"見える化"は最高の共通言語
開発チームとのレビュー会では、具体的なデータに基づいた建設的な議論ができました。特に「顧客ごとの情報を把握したい」といった具体的な要望を引き出せたのは大きな収穫です。 -
ツール導入はチームの巻き込みが成功の鍵
どんなに良いツールも、使われなければ意味がありません。開発者にも閲覧権限を共有し、皆で活用していく方針を確認しました。
今後の展望：そして開発チームとの新たな航海へ 🚀
ダッシュボードは完成しましたが、私たちの旅はまだ始まったばかりです。
今後は、開発チームと連携しながら、以下のステップに進んでいく予定です。
- アプリケーションログの本格収集と活用
- データベースモニタリング(DBM)の導入
- より実践的なアラート設定（エラー率、データ量など）の強化
まとめ
Datadogの導入プロジェクトは、多くの壁がありましたが、それらを乗り越えるたびにチームとして成長できたと実感しています。そして何より、サービスの品質をデータに基づいて語れるようになったことが最大の成果です。
この記事が、これからDatadogを導入する方や、同じように品質の可視化に取り組む方々の助けになれば、これほど嬉しいことはありません。
最後までお読みいただき、ありがとうございました！
Discussion