Monitor of “Datadog Monitor”

9 min readDec 21, 2021

Datadog Monitor 便利ですよね。

今回は、Monitor の数が増えた際に発生する、監視漏れという懸念に対して、適切に監視を行えているかを監視するツールを作ったという話をしたいと思います。

Background

Datadog Monitor の Query は様々なパターンに対応しています。

例えば、こういうものです。
以下は stage: production, monitor: enabled という tag がついた AWS の RDS の CPU 使用率が80%を超えているものがあれば、Alert を発火するという Query になります。

avg(last_5m):avg:aws.rds.cpuutilization{stage:production,monitor:enabled} by {dbinstanceidentifier} > 80

この例だと、stage タグに production が付いていても、monitor タグを付け忘れていると、特定の RDS が監視対象に入らないということが発生します。これが今回取り上げたい「監視漏れ」の例となります。

また、今後の説明がしやすいように、Query の構成要素の呼称を確認します。

aws.rds.cpuutilization は監視対象となる Metric
{stage:production,monitor:enabled} は監視対象を絞り込む Scope
avg:~ by {dbinstanceidentifier} は Metric をどの単位/どの集計関数で集計するか
avg(last_5m):~ > 80 は Alert の発火条件

クエリ

Datadog では、メトリクス、ログ、トレース、モニター、ダッシュボード、ノートブックなどのすべてのグラフで同じ基本機能は使用しています。このページでは、グラフエディターのクエリについて説明します。上級レベルのユーザーは、JSON…

docs.datadoghq.com

Why Need Scoped Monitor

監視漏れを防ぐためのプラクティスとして、Scope に wildcard を利用するという方法があります。

avg(last_5m):avg:aws.rds.cpuutilization{*} by {dbinstanceidentifier} > 80

このように wildcard scope を使う利点として、監視漏れがなくなることが上げられます。Datadog と連携させている AWS Account の全ての RDS が監視対象に入ることが保証されます。

一方で、全ての Resource に対して、同一の監視設定が当たってしまう問題もあります。そういった背景から、「監視漏れ」のリスクがある Scope を指定して、個別に監視の閾値を設定するシチュエーションは多いのではないでしょうか。

以下は Production/Staging とで監視の閾値を変えるという例です。
本番環境と比べてテスト環境では安い Resource を利用するため、それに合わせて閾値を変えたいといったケースは多いと思いますが、ここでタグ付けをミスると「監視漏れ」が起きてしまいます。

# production
avg(last_5m):avg:aws.rds.cpuutilization{stage:production} by {dbinstanceidentifier} > 80# staging 環境は緩める
avg(last_5m):avg:aws.rds.cpuutilization{stage:staging} by {dbinstanceidentifier} > 90

workaround として、Monitor が増えるごとに、そこでカバーされないものを一律で拾うための Monitor を negative scope を組み合わせて作っておくという手があります。negative scope を足し忘れても誤検知するだけなので、監視漏れは防げます。

また、wildcard で最も緩い閾値の Monitor を作るという手もあります。
どちらにしろ、追加で設定することや考慮することが増えてあまりいいアイデアではないように思えます。

# こっちは厳しい閾値でも大丈夫
avg(last_5m):avg:aws.rds.cpuutilization{!stage:production,!stage:staging} by {dbinstanceidentifier} > 70# こっちは緩い閾値じゃないと駄目
avg(last_5m):avg:aws.rds.cpuutilization{*} by {dbinstanceidentifier} > 95

Solution

Monitor Of DataDog から modd という名前のツールを作りましたhttps://github.com/terakoya76/modd

機能としてはシンプルで、以下の手順で監視漏れ Resource の一覧を出力します。

Datadog API から Monitor のリストを取得
Monitor で監視している Metrics を元に、Resource 一覧を AWS API から取得
Metrics を元に Monitor をグルーピング。同一グループの複数の Scope を実際に評価し、それに該当する Resource を監視できているか確認する。
監視漏れの可能性がある Resource を一覧出力

以下が動作例です。
RDS の xxx-db が監視漏れであることがわかります。

$ export DD_CLIENT_API_KEY=xxxxx
$ export DD_CLIENT_APP_KEY=yyyyy$ ./modd
unsupported metrics: aws.applicationelb.un_healthy_host_count
unsupported metrics: aws.elb.healthy_host_count
unsupported metrics: aws.applicationelb.un_healthy_host_count.maximum
unsupported metrics: aws.applicationelb.target_response_time.p99
unsupported metrics: aws.autoscaling.group_total_instances
unsupported metrics: aws.autoscaling.group_max_size
unsupported metrics: aws.applicationelb.healthy_host_count
{
  "aws.elasticache.cache_misses": [],
  "aws.elasticache.cpuutilization": [],
  "aws.elasticache.curr_connections": [],
  "aws.elasticache.database_memory_usage_percentage": [],
  "aws.elasticache.engine_cpuutilization": [],
  "aws.elasticache.replication_lag": [],
  "aws.elasticache.swap_usage": [],
  "aws.es.alerting_index_statusred": [],
  "aws.es.alerting_index_statusyellow": [],
  "aws.es.automated_snapshot_failure": [],
  "aws.es.cluster_index_writes_blocked": [],
  "aws.es.cpuutilization.maximum": [],
  "aws.es.free_storage_space.minimum": [],
  "aws.es.jvmmemory_pressure.maximum": [],
  "aws.es.master_cpuutilization": [],
  "aws.es.master_reachable_from_node": [],
  "aws.es.search_rate": [],
  "aws.rds.aurora_replica_lag": [],
  "aws.rds.burst_balance": [
    "xxx-db"
  ],
  "aws.rds.cpuutilization": [
    "xxx-db"
  ],
  "aws.rds.database_connections": [
    "xxx-db"
  ],
  "aws.rds.disk_queue_depth": [
    "xxx-db"
  ],
  "aws.rds.dmllatency": [],
  "aws.rds.free_storage_space": [
    "xxx-db"
  ],
  "aws.rds.replica_lag": [
    "xxx-db"
  ],
  "aws.rds.select_latency": [],
  "aws.rds.total_storage_space": [
    "xxx-db"
  ]
}

RDS はサービス（DB Instance）ごとに閾値を変えたいケースが多く、Monitor をサービスごとに分けた結果、実際の環境でも監視漏れが発生していました。

また、出力からわかるように、現在 support している Resource は限られています。取り急ぎ自分が必要な分だけ実装しましたが、今後 Support する Resource を増やしていきたいです。

監視漏れに悩んでいる方がいらっしゃいましたら、ご参考ください。
また、こういう風にすればそもそも監視漏れは生じないよというプラクティスがありましたら、教えていただけると幸いです。

Monitor of “Datadog Monitor”

Background

クエリ

Why Need Scoped Monitor

Solution

Written by Hajime Terasawa