share facebook facebook twitter menu hatena pocket slack

2017.03.31 FRI

Datadog の Monitors 定義をコード(YAML)で管理するツール chihuahua を再発明した

川原 洋平

WRITTEN BY 川原 洋平

tl;dr

既に Datadog の Monitors を管理するコマンドラインツールとして codenize-tools の Barkdog が有名で、他の codenize-tools ツール達と同じインターフェースで備えていて、ちゃんと使うなら Barkdog だなーと思っている。

codenize-tools/barkdog
barkdog - Barkdog is a tool to manage Datadog monitors.

github.com

しかし、朝、目が覚めて、何かが降りてきたのか知らないけど、Monitors の API 周りの勉強を兼ねて、自分でもコマンドラインツールを作ってみることにした。

作ったもの

チワワ。

inokappa/chihuahua
chihuahua - Datadog monitors を YAML DSL で管理してみる試みです

github.com

詳細は README を。

使い方

インストール

Gem では今のところ配布していない。

git clone https://github.com/inokappa/chihuahua.git
cd chihuahua
bundle install --path vendor/bundle

初期化

Monitors の定義を書き出すディレクトリを作成する。

bash-3.2$ bundle exec ./bin/chihuahua init
done.
bash-3.2$ tree monitors/
monitors/

0 directories, 0 files

上記のように monitors ディレクトリが作成されているはず。

既存設定の書き出し

チワワは既存設定の書き出しから始めることを想定している。また、必ず --project= オプションでプロジェクト名を指定する必要がある。これは、一つの Datadog アカウントに複数のプロジェクトの Monitors 設定が行われている場合、Monitors の Name キーや Tags キーによってプロジェクトを絞り込んで利用することを想定している。

export DATADOG_API_KEY=...
export DATADOG_APP_KEY=...

bundle exec ./bin/chihuahua export --project=your_project_name --tags=project:foo,stage:production

上記のように--tags= オプションでタグを指定することで、任意の Monitors 定義を取得することが出来る。
export オプションで書き出しを行うと以下のように monitors ディレクトリ以下にプロジェクト名のディレクトリが作成されて monitors.yml ファイルが作成されている。

$ bundle exec ./bin/chihuahua export --project=foo --tags=host:vagrant-ubuntu-trusty-64
Export...
6 monitors output done.

$ tree -a ./monitors/
./monitors/
└── foo
    ├── .filter.yml
    └── monitors.yml

1 directory, 2 files

新規登録

書き出された既存の Monitors 定義を利用して新しい Monitors 定義を登録してみる。

$ vim ./monitors/foo/monitors.yml
#
# 以下を追加
#
- query: avg(last_1m):avg:system.load.5{host:vagrant-ubuntu-trusty-64} > 1
  message: |-
    CPU load is very high on {{host.name}}
    @slack-datadog-notification
  name: Test 10 [{{#is_alert}}CRITICAL{{/is_alert}}{{#is_warning}}WARNING{{/is_warning}}]
    CPU load is very high on {{host.name}}
  type: metric alert
  options:
    thresholds:
      critical: 1.0
      warning: 0.8

上記のように monitors.yml に定義を追加する。ポイントは id キーを付与しないこと。
以下のように --dry-run オプションを付けて chihuahua export を実行すると、一応 登録する内容のチェックを行うことが出来る。

$ bundle exec ./bin/chihuahua apply --project=foo --dry-run
Apply...(dry-run)
Check add line.
---
query: avg(last_1m):avg:system.load.5{host:vagrant-ubuntu-trusty-64} > 1
message: |-
  CPU load is very high on {{host.name}}
  @slack-datadog-notification
name: Test 10 [{{#is_alert}}CRITICAL{{/is_alert}}{{#is_warning}}WARNING{{/is_warning}}]
  CPU load is very high on {{host.name}}
type: metric alert
options:
  thresholds:
    critical: 1.0
    warning: 0.8

定義する内容に問題なさ気であれば、--dry-run を外して登録する。

$ bundle exec ./bin/chihuahua apply --project=foo
Apply...
Add line.
{"tags"=>[], "deleted"=>nil, "query"=>"avg(last_1m):avg:system.load.5{host:vagrant-ubuntu-trusty-64} > 1", "message"=>"CPU load is very high on {{host.name}}\n@slack-datadog-notification", "id"=>1234567, "multi"=>false, "name"=>"Test 10 [{{#is_alert}}CRITICAL{{/is_alert}}{{#is_warning}}WARNING{{/is_warning}}] CPU load is very high on {{host.name}}", "created"=>"2017-03-11T13:01:57.454395+00:00", "created_at"=>1489237317000, "creator"=>{"id"=>22222, "handle"=>"inokara@gmail.com", "name"=>"ようへい かわはら", "email"=>"inokara@xxx.com"}, "org_id"=>11111, "modified"=>"2017-03-11T13:01:57.454395+00:00", "overall_state_modified"=>nil, "overall_state"=>"No Data", "type"=>"metric alert", "options"=>{"notify_audit"=>false, "locked"=>false, "silenced"=>{}, "thresholds"=>{"critical"=>1.0, "warning"=>0.8}, "new_host_delay"=>300, "require_full_window"=>true, "notify_no_data"=>false}}

更新

定義を少し更新してみる。

$ vim ./monitors/foo/monitors.yml
#
# query と thresholds を更新してみる
#
- query: avg(last_1m):avg:system.load.5{host:vagrant-ubuntu-trusty-64} > 2
  message: |-
    CPU load is very high on {{host.name}}
    @slack-datadog-notification
  id: 1234567
  name: Test 10 [{{#is_alert}}CRITICAL{{/is_alert}}{{#is_warning}}WARNING{{/is_warning}}]
    CPU load is very high on {{host.name}}
  type: metric alert
  options:
    thresholds:
      critical: 2.0
      warning: 0.8

以下のように --dry-run オプションを付けて chihuahua exportを実行すると、一応登録する内容のチェックを行うことが出来る。

$ bundle exec ./bin/chihuahua apply --project=foo --dry-run
Apply...(dry-run)
Check update line.
 ---
 tags: []
-query: avg(last_1m):avg:system.load.5{host:vagrant-ubuntu-trusty-64} > 1
+query: avg(last_1m):avg:system.load.5{host:vagrant-ubuntu-trusty-64} > 2
 message: |-
   CPU load is very high on {{host.name}}
   @slack-datadog-notification
 id: 1234567
 name: Test 10 [{{#is_alert}}CRITICAL{{/is_alert}}{{#is_warning}}WARNING{{/is_warning}}]
   CPU load is very high on {{host.name}}
 type: metric alert
 options:
   notify_audit: false
   locked: false
   silenced: {}
   thresholds:
-    critical: 1.0
+    critical: 2.0
     warning: 0.8
   new_host_delay: 300
   require_full_window: true
   notify_no_data: false

done.

定義する内容に問題なさ毛であれば、--dry-run を外して登録する。

$ bundle exec ./bin/chihuahua apply --project=foo
Apply...
Update line.
{"tags"=>[], "deleted"=>nil, "query"=>"avg(last_1m):avg:system.load.5{host:vagrant-ubuntu-trusty-64} > 2", "message"=>"CPU load is very high on {{host.name}}\n@slack-datadog-notification", "id"=>1234567, "multi"=>false, "name"=>"Test 10 [{{#is_alert}}CRITICAL{{/is_alert}}{{#is_warning}}WARNING{{/is_warning}}] CPU load is very high on {{host.name}}", "created"=>"2017-03-11T13:01:57.454395+00:00", "created_at"=>1489237317000, "org_id"=>11111, "modified"=>"2017-03-11T13:08:16.046036+00:00", "overall_state_modified"=>nil, "overall_state"=>"No Data", "type"=>"metric alert", "options"=>{"notify_audit"=>false, "locked"=>false, "silenced"=>{}, "thresholds"=>{"critical"=>2.0, "warning"=>0.8}, "require_full_window"=>true, "new_host_delay"=>300, "notify_no_data"=>false}}
done.

削除

って怖いのでダッシュボード上で指差し確認しながら削除する想定なので、削除は実装していない(というか出来ない。スキル的に)。ダッシュボードで削除した上で書き出しを行えば、一応、定義をコードで管理することが出来ると思う。

ということで

Datadog API の Monitors Tips

  • 新規登録は id キー不要
  • id がユニークキーとなる
  • id キーを指定することで任意の Monitors 定義を取得することが出来る
  • 新規登録時の必須オプションは type キーとquery キー

想定する使い方

  • 1 つの Datadog アカウントで複数のプロジェクトの Monitors を管理していて、プロジェクト毎に Monitors の管理を分けたいというニーズがある場合
  • 但し、上記のような使い方をする場合には Tags キーや Name キーを厳密に設定しておく必要があると思う

ちなみに、現時点(version 1.25.0)で Datadog API の Ruby Client では Monitors の定義を取得する get_all_monitors メソッドは :name オプションをサポートしていないので注意が必要(version 1.26.0 でサポート予定)。
以上。

codenize-tools

chihuahua を作るにあたり、Barkdog のオプション指定方法等を参考にさせて頂いた。codenize-tools ファミリーのツールって洗練されているなあと思った。

元記事はこちら

Datadog の Monitors 定義をコード(YAML)で管理するツール chihuahua を再発明した