- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
CI Visibility を有効にすると、CI Pipeline または CI Test モニターを作成することができます。
CI モニターでは、CI データを視覚化し、それに対するアラートを設定することができます。例えば、CI Pipeline モニターを作成し、パイプラインやジョブが失敗した場合のアラートを受信します。CI Test モニターを作成し、失敗したテストや遅いテストに関するアラートを受信します。
Datadog で CI モニターを作成するには、メインナビゲーションで Monitors -> New Monitor –> CI の順に進みます。
Pipelines または Tests のどちらかのモニターを選択します。
Unique value count
に対してアラートを表示します。min
、avg
、sum
、median
、pc75
、pc90
、pc95
、pc98
、pc99
、または max
) を選択します。group by
が含まれる場合、グループパラメーターに従い、複数のアラートを各ソースに適用します。アラートイベントは、設定された条件を満たすと各グループに生成されます。たとえば、クエリを @ci.pipeline.name
でグループ化すると、エラーの数が多い場合に CI パイプラインごとに個別のアラートを受信することができます。数式と関数を使用して CI パイプラインを作成できます。これは、たとえばパイプラインの失敗率(エラー率)など、イベントの発生率のモニターを作成する場合に使用できます。
次の例は、ci.pipeline.name
(パイプラインごとに 1 回アラートする) でグループ化された “全パイプラインイベント数” (フィルターなし) に対する “失敗パイプラインイベント数” (ci.status=error
) の割合を計算する式を使ったパイプラインエラー率モニターの例です。詳しくは、関数の概要を参照してください。
myapp
というテストサービスの main
ブランチに対して失敗したテストを検索するには、クエリ @test.status:fail @git.branch:main @test.service:myapp
を使用します。Unique value count
に対してアラートを表示します。min
、avg
、sum
、median
、pc75
、pc90
、pc95
、pc98
、pc99
、または max
) を選択します。group by
がある場合、グループパラメーターにしたがって、すべてのソースに対してアラートが送信されます。設定された条件を満たす各グループに対してアラートイベントが生成されます。例えば、クエリを @test.full_name
でグループ化し、エラー数が多い場合に CI Test フルネーム毎に個別のアラートを受信することができます。テストのフルネームはテストスイートとテスト名の組み合わせで、例えば MySuite.myTest
のようなものです。Swift では、テストのフルネームはテストバンドルとスイートと名前の組み合わせで、例えば MyBundle.MySuite.myTest
のような名前になります。同じテストのフルネームで、異なるテストパラメーターや構成のテストがある場合、モニターの group by
で @test.fingerprint
を使用します。こうすることで、特定のパラメーターや構成でテストを実行した場合に警告を発することができます。@test.fingerprint
を使用すると、Commit Overview ページにある Test Stats, Failed and Flaky Tests セクションと同じ粒度レベルが提供されます。
例えば、同じフルネームのテストが Chrome では失敗し、Firefoxでは合格した場合、フィンガープリントを使用すると、Chrome のテスト実行時にのみアラートが発生します。
この場合、@test.full_name
を使用すると、Firefox 上でテストに合格していても、警告が表示されます。
数式と関数を使用して CI Test を作成できます。たとえば、これはテストの失敗率 (エラー率) など、イベントの発生率のモニターを作成する場合に使用できます。
以下は、テストエラー率モニターの例です。「テストイベント総数」(フィルターなし) に対する「失敗したテストイベント」(@test.status:fail
) の割合を計算する数式を使用し、@test.full_name
でグループ化 (テストごとにアラート) されています。詳しくは、関数の概要をご覧ください。
テストイベントで利用可能な CODEOWNERS
の情報を使って、異なるチームに通知を送信することができます。
以下の例では、次のロジックで通知を構成しています。
MyOrg/my-team
ならば、my-team-channel
Slack チャンネルに通知を送ります。MyOrg/my-other-team
ならば、my-other-team-channel
Slack チャンネルに通知を送ります。{{#is_match "citest.attributes.test.codeowners" "MyOrg/my-team"}}
@slack-my-team-channel
{{/is_match}}
{{#is_match "citest.attributes.test.codeowners" "MyOrg/my-other-team"}}
@slack-my-other-team-channel
{{/is_match}}
モニターの Notification message
セクションに、上記のコードスニペットのようなテキストを追加して、モニター通知の設定をします。is_match
句は必要なだけ追加することができます。Notification 変数については、条件付き変数の監視を参照してください
above
、above or equal to
、below
、below or equal to
の場合にトリガーされる5 minutes
、15 minutes
、1 hour
の間のしきい値、または custom
に 1 minute
~ 2 days
の値を設定します。<数値>
<数値>
高度なアラートオプション (評価遅延など) の詳細な手順については、モニターコンフィギュレーションページを参照してください。
Say what’s happening と Notify your team のセクションに関する詳しい説明は、通知のページを参照してください。
CI テストまたはパイプラインモニターがトリガーされると、サンプルまたは値が通知メッセージに追加されます。
モニター設定 | 通知メッセージに追加可能な値 |
---|---|
グループ化されていない Simple-Alert 数 | 最大 10 個のサンプル。 |
グループ化された Simple-Alert 数 | 最大 10 個のファセット値またはメジャー値。 |
グループ化された Multi-Alert 数 | 最大 10 個のサンプル。 |
グループ化されていない Simple-Alert メジャー | 最大 10 個のサンプル。 |
グループ化された Simple-Alert メジャー | 最大 10 個のファセット値またはメジャー値。 |
グループ化された Multi-Alert メジャー | 最大 10 個のファセット値またはメジャー値。 |
これらの通知の送信に、Slack、Jira、webhooks、Microsoft Teams、Pagerduty、電子メールを使用することができます。注: サンプルはリカバリ通知には表示されません。
サンプルを無効にするには、Say what’s happening セクションの一番下にあるチェックボックスをオフにします。チェックボックスの隣に表示されるテキストは、モニターのグループ化によって変わります(上記を参照)。
アラート通知に CI テスト 10 サンプルのテーブルを含めます。
アラート通知に CI パイプライン 10 サンプルのテーブルを含めます。
評価クエリにイベントカウントを使用するモニターは、指定された評価期間の後にデータがなく解決され、通知をトリガーします。例えば、5 分の評価ウィンドウでパイプラインエラーの数にアラートするように構成されたモニターは、パイプラインの実行がない 5 分後に自動的に解決されます。
代替案として、Datadog はレートフォーミュラの使用を推奨しています。例えば、パイプラインの失敗数 (カウント) のモニターを使う代わりに、(パイプラインの失敗数)/(全パイプライン実行数)
のようなパイプライン失敗の割合 (式) のモニターを使います。この場合、データがないときには分母の (全パイプライン実行数)
は 0
となり、割り算 x/0
は評価できません。モニターは 0
に評価する代わりに、以前の既知の状態を維持します。
この方法では、パイプラインの故障が多発してエラーレートがモニターのしきい値を超えたためにモニターがトリガーされた場合、エラーレートがしきい値を下回るまでクリアされません (その後、いつでもクリアできます)。
一般的なモニターの使用例を以下に示します。モニタークエリは、特定のブランチ、作成者、その他のアプリ内のファセットに対してフィルターをかけるように変更することができます。
duration
メトリクスは、パイプラインやテストのパフォーマンス低下を特定するために使うことができます。このメトリクスでアラートを出すことで、コードベースへのパフォーマンス後退を防ぐことができます。
テストモニターには、New Flaky Test
、Test Failures
、Test Performance
という共通のモニタータイプがあり、簡単にモニターを設定することができます。このモニターは、新しい不安定なテストがコードベースに追加されたときにアラートを送信します。クエリは Test Full Name
によってグループ化されているので、同じ新しい不安定なテストに対して何度もアラートが送られることはありません。
テスト実行が何度か再試行された後、同じコミット内で不安定性が発生した場合、flaky
とマークされます。もし複数回不安定性が発生した場合 (複数のリトライが実行されたため)、is_flaky
タグは不安定として検出された最初のテストランに追加されます。
同じブランチやデフォルトブランチ内でそのテストが不安定であると検出されていない場合、そのテスト実行は new flaky
としてマークされます。新しい不安定として検出された最初のテスト実行だけが、(再試行の回数に関係なく) is_new_flaky
タグでマークされます。
不安定テストについては、不安定テスト管理ガイドを参照してください。
コードカバレッジ率などのカスタムメトリクスを作成し、モニター内で使用することができます。以下のモニターは、コードカバレッジが一定の割合以下になるとアラートを送信し、長期間にわたってテストのパフォーマンスを維持するのに役立ちます。