share facebook facebook facebook twitter twitter menu hatena pocket slack

2021.08.06 FRI

TerraformでDatadogのMonitorを書く

Shimpei Chiba

WRITTEN BY Shimpei Chiba

これは何

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ベースで算定もできるので、そこまで困ることもないのかな、と思ったりするのでした。

元記事はこちら

https://qiita.com/namely_/items/d1e01208709fb975715f

cloudpack

cloudpackは、Amazon EC2やAmazon S3をはじめとするAWSの各種プロダクトを利用する際の、導入・設計から運用保守を含んだフルマネージドのサービスを提供し、バックアップや24時間365日の監視/障害対応、技術的な問い合わせに対するサポートなどを行っております。
AWS上のインフラ構築およびAWSを活用したシステム開発など、案件のご相談はcloudpack.jpよりご連絡ください。