✅ 概要
DatadogのMonitors機能を使ってSlackに通知を送る際に、WarningとCriticalが混在して重要なアラートが埋もれてしまう経験はありませんか?
例えば、CPU使用率が一時的に高くなっただけでSlackに大量のWarningが流れ込み、本当に対処すべきCriticalアラートが見逃されるケースもあります。そこで、本記事ではDatadog Monitorsを使い、SlackチャンネルごとにWarningとCriticalを分けて通知する方法を紹介します。今回はTerraformでの実装例を交えて解説します。
✅ ユースケース
- RDSのCPU使用率監視:
- Warning:CPU使用率80%を超えた場合 →
slack-warning-channel - Critical:CPU使用率90%を超えた場合 →
slack-critical-channel - 重要度の高い通知を見逃さないようにするために、各Slackチャンネルに分けて通知する設定。
✅ Terraformによる実装方法
📌 Terraformコード例
locals {
rds_cpuutilization_critical_thresholds = 90
rds_cpuutilization_warning_thresholds = 80
slack_channel_critical = "@slack-critical-channel"
slack_channel_warning = "@slack-warning-channel"
}
resource "datadog_monitor" "rds_cpuutilization" {
name = "RDS CPUUtilization Monitoring"
type = "query alert"
query = "avg(last_10m):avg:aws.rds.cpuutilization{name:{対象のリソース名}} by {hostname, name} > ${local.rds_cpuutilization_critical_thresholds}"
message = <<-EOT
{{#is_warning}}
【Warning Alert】
- 過去10分間の{{name.name}}の平均CPU使用率が閾値${local.rds_cpuutilization_warning_thresholds}%を超えました。
- ホスト名:{{hostname.name}}
${local.slack_channel_warning}
{{/is_warning}}
{{#is_warning_recovery}}
🔄 Warning状態から復旧しました。
${local.slack_channel_warning}
{{/is_warning_recovery}}
{{#is_alert}}
<!channel>
🚨【Critical Alert】
- 過去10分間の{{name.name}}の平均CPU使用率が閾値${local.rds_cpuutilization_critical_thresholds}%を超えました。
- ホスト名:{{hostname.name}}
${local.slack_channel_critical}
{{/is_alert}}
{{#is_alert_recovery}}
✅ Critical状態から復旧しました。
${local.slack_channel_critical}
{{/is_alert_recovery}}
EOT
monitor_thresholds {
critical = local.rds_cpuutilization_critical_thresholds
warning = local.rds_cpuutilization_warning_thresholds
}
}
✅ コード解説
- localsで閾値とSlackチャンネルを定義:
rds_cpuutilization_critical_thresholds: Criticalの閾値 (90%)rds_cpuutilization_warning_thresholds: Warningの閾値 (80%)- Slack通知を送るチャンネルをそれぞれ定義。
- Datadog Monitorの設定:
- RDSのCPU使用率を10分間の平均で監視。
is_warningとis_alertでSlackチャンネルを分けて通知。
- Terraform Apply:
terraform apply -auto-approve
✅ 注意点(重要!)
🔥 Recovery通知の設定ミスに注意
{{#is_recovery}}は、ALERT、WARNING、または NO DATA からモニターが回復した際に通知される。{{#is_alert_recovery}}は、モニターが ALERT 状態から OK に回復したときにのみ通知される。
❗️ 注意点:
{{#is_recovery}}を使うと、WarningとCritical両方の回復時に通知が来るため、二重通知になる可能性があります。- 通常は
{{#is_alert_recovery}}を使用することを推奨。
✅ 構成された条件変数の重要なポイント
Datadogのメッセージ設定では、構成された条件変数の使い方に注意が必要です。
- 外側に配置されたテキストや通知ハンドル: モニターの状態遷移ごとに起動されます。
- 条件変数 (
{{#is_alert}}など) の内側に配置されたテキスト: モニターの状態遷移がその条件に一致する場合にのみ呼び出されます。
公式ドキュメント:Datadog Monitorsの変数
注: 構成された条件変数の外側に置かれたテキストまたは通知ハンドルは、モニターの状態遷移ごとに起動されます。構成された条件変数の内側に置かれたテキストまたは通知ハンドルは、モニター状態の遷移がその条件に一致する場合にのみ呼び出されます。
https://docs.datadoghq.com/ja/monitors/notify/variables/?tab=is_alert
✅ 応用方法
- 複数のSlackチャンネルに分けることで、重要度に応じた通知管理が可能。
- 例えば:
- セキュリティ関連のアラート: 専用のSlackチャンネルを用意し、Critical通知のみを受け取るように設定。
- データベースのパフォーマンス監視: Warningは運用チーム、Criticalは開発チームに通知することで、効率的なトリアージを実現。
- 組織全体の通知管理: 複数のMonitorsをTerraformコードで統一的に管理し、簡単にスケーリング可能。
✅ まとめ
Datadog Monitorsを使ったSlack通知の分離方法を解説しました。この設定を使えば、SlackチャンネルをWarning用とCritical用に分けることで、運用効率を大幅に改善できます。特に、Recovery設定に注意しながらチャンネル分けを行うことがポイントです。
Terraformを使った設定例を参考に、プロジェクトに取り入れてみましょう!!!

