この記事は Datadog Advent Calendar 2025 シリーズ2 の19日目の記事です。
はじめに
JINSで、システムアーキテクト/プラットフォームエンジニアをしている佐藤(@Takuma3ato)です。
アイウエアの企画、製造、販売をしているJINSでは、現在、クラウドネイティブ化を進めていて、システム基盤をグローバル共通化していくプロジェクトに挑戦しています。また、システム開発の内製化も進めていて、その規模が大きくなっていくと同時に「自分たちのシステム開発力がどうであるか」を知りたくもなってきています。我々はo11yのツールとしてはDatadogを使っており、様々なシステムをカバーできるように利用拡大をしている最中ですが、実はこのDatadogで、システムの開発生産性もモニタリングすることができます。今日はその話をしたいと思います。まずはいつも通り結論を知りたい方向けのまとめから入ります。
3行まとめ
・DatadogはCI/CDプロセスのモニタリングができるサービスが複数あり、この分野に意外と力を入れてるっぽい
・パイプライン処理をモニタリングできるCI VisibilityはAWSとのインテグレーションがとっても簡単
・Four Keys(DORAメトリクス)をきちんと取る場合は、サービスの組み合わせが必要
全体像
Datadogでは、Datadog Software Deliveryの関連機能として、「CI Visibility」「Test Visibility」「CD Visibility」「Deployment Gates」「DORA Metrics」などが用意されていますが、今回お話しするのは「CI Visibility」です。CIプロセスの可視化が主な機能です。
JINSでは、リポジトリサービスとしては、AWS CodeCommitが中心でしたが、最近はGitHubも使うようにしています。ソースコードのビルドに使用しているサービスとしてはAWS CodePipelineです。「CI Visibility」は、AWS CodePipelineをサポートしています。
各機能のカバー範囲を下記の通り図示してみました(Gemini Nano Banana Proで作成しています)。大まかにはこの通りかと思いますが、1点気をつけることがあります。それは「DORA Metrics」は、Deployment events(Deployment Frequency, Change Lead Time、Change Failure Rate)とFailure events(Change failure rate, Time to restore)のデータを収集しますが、Datadog APMや、Datadog Incidents機能が別途必要で、Visibilityシリーズだけで計測できるわけではないことに注意が必要です。
Visibilityシリーズの全体像
やってみる
セットアップすること
モニタリング対象とするCIプロセスを決める
既出の通り、CI/CDプロセスにAWS CodePipelineを使用していますのでモニタリングするパイプラインを決めます。
AWS CodePipelineの画面
EventBridgeでルールを定義する
次に、該当のパイプラインでイベントが発火したことをキャッチし、必要な情報をDatadogに送信する処理を準備します。CI Visibilityのインテグレーションは至ってシンプルでして、Amazon EventBridgeがAWS CodePipelineのパイプライン処理のイベント情報を受け取り、そのイベント情報をDatadogプラットフォームのAPIにWebhookすることで実現できるようになっています。EventBridgeのコンソール画面で「API destinations」を指定し、Datadogプラットフォーム側のAPI(https://webhook-intake.datadoghq.com/api/v2/webhook)を設定します。その後、接続に関する設定(Datadog API Keyなど)を行います。
EventBridgeに定義するルールですが、全てのパイプラインをモニタリング対象にする場合は、下記を設定します。
{
"source": ["aws.codepipeline"],
"detail-type": ["CodePipeline Pipeline Execution State Change", "CodePipeline Action Execution State Change", "CodePipeline Stage Execution State Change"]
}
逆に、特定のパイプラインのみモニタリングする場合は、こちらを定義します。
{
"source": ["aws.codepipeline"],
"detail-type": ["CodePipeline Pipeline Execution State Change", "CodePipeline Action Execution State Change", "CodePipeline Stage Execution State Change"],
"detail": {
"pipeline": ["first-pipeline", "second-pipeline"] # first-pipeline と second-pipeline のパイプラインに対してのみ、インテグレーションが設定される。
}
}
以上でセットアップは終了です！
モニタリングの状況
AWS環境とDatadog環境が連携できるようになったら、後はパイプラインの実行を待つだけです。
Datadog側で検知できるようになったら、Pipelineのリストに表示されるようになります。
Datadog Pipelineの画面
パイプラインの実行結果を確認したい時は、別タブメニューのPipeline Executionsに情報がありますので、そちらを確認しましょう。
Datadog Pipeline Executionsの画面
そして、特定のPipelineの実行結果の詳細を確認することも可能です。この添付画像の場合は、Terraformを使用したパイプラインなので、Plan, Approve, Applyと処理プロセスが表示されていますが、アプリケーションビルドのパイプラインの場合は、表示項目が変わります。
Datadog Pipeline Executionsの特定のパイプラインの詳細情報
メモ
気づき事項としては、Pipeline Executionsにおいて、該当のPipelineのPipleline IDは値がセットされているのですが、Repository Nameには値がセットされていませんでした。調べたところ、AWS CodePipelineのイベントには、ソースリポジトリの詳細な情報がデフォルトでは含まれていないからだと思われます。Datadogにイベント情報を送信する際にこれらの情報を付加するカスタムをすることも可能ですが、ちょっと手間なのでそれはしませんでした。Pipeline Nameから該当リポジトリを推測できるように命名しておけば支障はありません。
コストについて
このように簡単にセットアップして、CIプロセスに関するたくさんの情報を取得できるCI Visibilityですが、気になるところはコストですね。コミッター数に応じた料金体系なのですが、この点については私から詳細を述べるというよりも、Datadogの公式サイトに価格情報が載っているのでそちらをご確認ください。自分たちでUsage状況を確認したい場合は、「Usage & Cost」ページで確認しましょう。
Datadog Usage & Costの画面
まとめ
今回お話ししたCI Visibility以外にも、Visibilityシリーズはいくつかあるので、JINSでもそれらを使ってみたいと思っています。その実装方法についてはまた別の機会でお話しできればと思います。この記事が、Datadogでの開発生産性モニタリングをしてみようという人のお役に立てば幸いです。
では、また。
Discussion