これは何
TerraformでDatadogのMonitorを書いた時のメモです。
各値がよくわからんなあと思ったので、まとめました。
記述例
#monitor
resource "datadog_monitor" "keepalive" {
name = "[${var.project_name}][EC2] Linux: 死活監視 "
type = "service check"
message = var.message
query = "\"datadog.agent.up\".over(\"datadog:enabled\",\"${var.project_account}\").by(\"host\").last(2).count_by_status()"
monitor_thresholds {
ok = 1
warning = 1
critical = 1
}
notify_no_data = true
no_data_timeframe = 2
new_host_delay = 300
renotify_interval = 0
timeout_h = 0
include_tags = true
notify_audit = false
tags = ["service:${var.project_name}"]
}
解説
nameはDDのモニターの名前です。
自分はここに、案件名などの変数を別で定義して、ここに入れるようにしてます。
typeは、モニターの種類ですね。
＊モニタータイプは、一度作成したら変更はできません。
性質に合わせて、以下から選ぶ模様。
composite, event alert, log alert, metric alert, process alert, query alert, rum alert, service check, synthetics alert, trace-analytics alert, slo alert, event-v2 alert.
【選び方】
| 拾いたいもの(?) | Monitor Type |
|---|---|
| 異常検知 | query alert |
| APM | query alert または trace-analytics alert |
| 複合条件 | composite |
| カスタム | service check |
| イベント | event alert |
| 予測値 | query alert |
| ホスト | service check |
| インテグレーション | query alert または service check |
| ライブプロセス | process alert |
| ログ | log alert |
| メトリクス | metric alert |
| ネットワーク | service check |
| 外れ値 | query alert |
| プロセス | service check |
| RUM | rum alert |
| SLO | slo alert |
| Watchdog | event alert |
| event-v2 | event-v2 alert |
参考
https://docs.datadoghq.com/ja/api/latest/monitors/
https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/monitor
messageは指定した閾値を超えたときに飛んでくる通知に含める文言ですね。
複数モニターで同じ文言を設定する場合は、変数定義しておくといいかも知れません。
queryは、知りたい値があるとき、監視対象に送る文字列、というイメージです。
【今回書いたクエリ算定式】
query = "\"datadog.agent.up\".over(\"datadog:enabled\",
\"${var.project_account}\").by(\"host\").last(2).count_by_status()"
【公式算定式の例】
query = "check".over(tags).last(count).count_by_status()
check：チェックする名前。
→例 datadog.agent.up
Datadog Agent は、ステータスが OK の datadog.agent.up というサービスチェックを報告します。
tags：引用符で囲まれた1 つ以上のタグ (カンマ区切り)、または “*"。
→例 .over("env:prod", "role:db")
今回書いたクエリでは、
datadog:enabled
${var.project_account}
by(\"host\")
→hostに付けられた、datadog:enabled、${var.project_account}というタグを拾ってくる、というイメージでしょうか。
count：最大しきい値 (options で定義) 以上である必要があります。
上限値は 100 です。
→例 ステータス 1 を critical、ステータス3 を OK、ステータス2 を warn と通知する場合は、count を 3 にする必要があります。
count_by_status()は、ググっても出てこなかったので、よくわかりませんでしたが、
自分の中では、対象のマシンからステータスをカウントする、みたいな感じかなあと理解してます。
（わかる方いれば教えてください。mm）
時間がなくて、考える余裕がない！でもコードで一応管理したい！という方は、GUIでQuery算出して、それをTFに入れ込む、というのもアリかも知れません。
monitor_thresholdsはモニターの閾値です。
notify_no_dataは、データの報告が停止したときに、このモニターが通知を行うかどうかですね。
ここではtrueでOnにしています。
no_data_timeframeは、データが報告されなくなってからモニターが通知するまでの時間を示す分単位の時間を入れます。Datadogは、メトリックアラートの場合は最低でもモニタのタイムフレームの2倍、サービスチェックの場合は2分を推奨しています。ここでは2分にしています。
new_host_delayは、モニター結果の評価を開始する前に、ホストが起動し、アプリケーションが完全に開始するまでの時間（秒）です。正の整数でなければなりません。
renotify_intervalは、モニターが現在の状態を再通知するまでの、最後の通知からの経過時間（分）です。解決していない場合のみ再通知します。
timeout_hは、モニターがデータを報告しない状態が何時間続くと、トリガー状態から自動的に解決されるかを示します。
include_tagsは、このモニターからの通知が自動的にそのトリガータグをタイトルに挿入するかどうかを示す値です。trueにしています。
notify_auditは、タグを付けたユーザーにこのモニターの変更を通知するかどうかを示す値です。
tagsは、モニターにつけるタグですね。
総じて
今の所、DDのクエリ算定がまだしっくりきていないなあという感じです。
まあこれは書いてれば分かってくるのかも？
時間がないときには、DDのGUIベースで算定もできるので、そこまで困ることもないのかな、と思ったりするのでした。