vague memory

うろ覚えを無くしていこうともがき苦しむ人の備忘録

Datadog Ansible Integration

Ansible の実行結果を Datadog へ連携できます。

Python 2.7 で試しました。 3系だと現状そのままだと Syntax Error となるので、 datadog_callback.py の一部書き換え(修正)が必要です。



Ansible Integration

Datadog 上で Ansible Integration を有効化します。(初回のみ)

f:id:htnosm:20170913013217p:plain

5分程で有効化が完了します。

f:id:htnosm:20170913013218p:plain

Setup

必要なライブラリ(datadogpy、pyyaml)をインストールしておきます。

$ pip list | grep -i -e "datadog" -e "pyyaml"
datadog (0.16.0)
PyYAML (3.12)

Ansible のコールバック機能を利用して連携します。 ansible-datadog-callback を適当なディレクトリに clone します。

datadog_callback.py があれば良いので、clone することは必須ではないです。

$ cd /tmp
$ git clone https://github.com/DataDog/ansible-datadog-callback.git 

Ansible へのコールバックプラグイン追加

既存の Playbook と同一階層に callback_plugins ディレクトリを作成し、 datadog_callback.py を格納します。

$ mkdir ansible/callback_plugins
$ cp /tmp/ansible-datadog-callback/datadog_callback.py ansible/callback_plugins

Datadog API キー用の yml を作成します。

$ echo "api_key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" > ansible/callback_plugins/datadog_callback.yml

以下のような階層になりました。

ansible
├── main.yml
├── callback_plugins
│   ├── datadog_callback.py
│   └── datadog_callback.yml
├── group_vars
│   └── main.yml
├── hosts
├── roles
│   ├── hogehoge
・・・

Ansible Playbook 実行

通常通り実行します。

$ cd ansible
$ ansible-playbook -i hosts main.yml

結果

メトリクスとしては、 タスクの正常、失敗、スキップ、到達不能、変更無しの数と Playbook の実行時間が取得できます。

Events

ansible-playbook実行時、成功/失敗のイベントが生成されます。 failure, unreachable だと Error として作成します。

f:id:htnosm:20170913013219p:plain

Event Monitor で失敗時に通知させるには、 sources:ansible, status:error と Playbook名で絞り込みます。

f:id:htnosm:20170913013221p:plain

Integration Dashboards

Ansible のダッシュボード で見ると以下のような感じになります。

f:id:htnosm:20170913013220p:plain

AWS EC2 Systems Manager を S3 へ同期

System Manager のインベントリデータをS3バケットへ集約できるようになったとのことで試してみました。

公式ドキュメント上にも EC2 -> System Manager -> S3 -> Athena -> QuickSight 連携方法がありました。

手順はドキュメント通りで問題無いので引っ掛かったポイントだけメモします。



インベントリ収集

  • [EC2] → [Systems Manager Shared Resources] → [Managed Instances] → [Setup Inventory]

Write Execution History to S3

インベントリのセットアップ時に Write Execution History to S3 でS3バケットへの書込設定があります。

f:id:htnosm:20170817204119p:plain

項目名の通り、収集実行結果の成否を書き込むだけで、インベントリデータが保存されるわけではありません。

  • S3格納パス
{{ S3 Bucket Name }}/{{ S3 Key Prefix }}/{{ InstanceId }}/{{ AssociationId }}/{{ datetime(UTC) }}/awssoftwareInventory/collectSoftwareInventoryItems/{stdout|stderr}
  • 出力例
# 成功時
s3://xxx.bucket/xxx.keyprefix/i-0f7d0577f65XXXXX/8611acf6-f9a1-49b9-8907-XXXXXXXXXXXX/2017-mm-ddThh-mm-ss.077Z/awssoftwareInventory/collectSoftwareInventoryItems/stdout
# 失敗時
s3://xxx.bucket/xxx.keyprefix/i-0f7d0577f65XXXXX/8611acf6-f9a1-49b9-8907-XXXXXXXXXXXX/2017-mm-ddThh-mm-ss.077Z/awssoftwareInventory/collectSoftwareInventoryItems/stderr

インスタンスは一度に一つのインベントリのみ

インスタンスには、一度に 1 つのインベントリのみ関連付けることができます。インスタンスに 2 つ以上関連付けて設定した場合、その関連付けは実行されず、インベントリデータは収集されません。

重複設定を行った場合、stderr に以下のように出力されます。

aws:softwareInventory detected multiple inventory configurations associated to one instance. You can  associate multiple inventory configurations to an instance.
The association IDs are: e6df398e-a8fc-4b38-b349-XXXXXXXXXXXf and 8611acf6-f9a1-49b9-8907-XXXXXXXXXXX3.

リソースデータの同期

今回の本題です。特に引っ掛かる箇所は無いと思います。

  • [EC2] → [Systems Manager Shared Resources] → [Managed Instances] → [Resource Data Syncs] → [Create a Resource Data Sync]

同期とターゲット Amazon S3 バケットが異なるリージョンにある場合、データ転送料金がかかる場合があります。

特別理由が無いのであれば、S3バケットは同一リージョンに作成するのが良いと思います。

出力結果

  • S3格納パス
{{ Bucket Name }}/{{ Bucket Prefix }}/AWS:{{ Parameters }}/accountid={{ AWS AccountId }}/region={{ Region }}/resourcetype= ManagedInstanceInventory/{{ InstanceId }}.json
  • 出力例

    • バケット配下に Parameters 毎に出力
    • Athenaのパーティション向けにHiveフォーマットで階層が切られる
    • 出力形式はJSON
  • 出力例

# Parameters毎
$ aws s3 ls s3://{{ Bucket Name }}/{{ Bucket Prefix }}/
                           PRE AWS:AWSComponent/
                           PRE AWS:Application/
                           PRE AWS:InstanceDetailedInformation/
                           PRE AWS:InstanceInformation/
                           PRE AWS:Network/
# InstanceID.json
$ aws s3 ls s3://{{ Bucket Name }}/{{ Bucket Prefix }}/AWS:Application/accountid=XXXXXXXXXXXX/region=ap-northeast-1/resourcetype=ManagedInstanceInventory/
2017-mm-dd hh:mm:ss     123456 i-XXXXXXXXXXXXXXXXX.json

Athena でデータを使用

テーブル作成クエリもドキュメントに記載されていますので、順次実行していけば良いです。

バケット名とプレフィックスを書き換える必要がありますが、 ドキュメント内のクエリに不要な空白が入っていたり、置換前の名称が異なる部分があるので、少しだけ注意が必要です。

・・・
# 空白が入っている
) LOCATION 's3:// bucketname /bucketprefix/AWS:AWSComponent/'
・・・
# bucketname
) LOCATION 's3://bucketname/bucketprefix/AWS:WindowsUpdate/'
・・・
# bucket-name
) LOCATION 's3://bucket-name/bucketprefix/AWS:InstanceInformation/'
・・・
  • 利用例

f:id:htnosm:20170817204120p:plain

QuickSight でデータを使用

  • 利用例

f:id:htnosm:20170817204122p:plain

東京リージョン未対応

QuickSightは現時点では東京リージョンでは使用できません。 そのため、Athenaをデータソースとする場合はAthenaもQuickSightが対応しているリージョンを選択する必要があります。

f:id:htnosm:20170817204121p:plain


SSMエージェント導入等、少々手間は入りますがAWS内でソフトウェア管理が完結できるのは良いですね。

ansible pythonが無い場合の対処

Ubuntu 16.04.2 に対して ansible 実行しようとしたら python が見つからないよと怒られたのでメモ。

公式ドキュメントに記載があります。

python2 と python3 の共存問題のようです。



エラー内容と環境

  • エラー
fatal: [xxx.xxx.xxx.xxx]: FAILED! => {
    "changed": false,
    "failed": true,
    "module_stderr": "Shared connection to xxx.xxx.xxx.xxx closed.\r\n",
    "module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
    "msg": "MODULE FAILURE",
    "rc": 0
}
  • 環境
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.2 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.2 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
$ which python
$ which python3
/usr/bin/python3
$ ls -1 /usr/bin/python*
/usr/bin/python3
/usr/bin/python3.5
/usr/bin/python3.5m
/usr/bin/python3-jsondiff
/usr/bin/python3-jsonpatch
/usr/bin/python3-jsonpointer
/usr/bin/python3m

python2 で動かす

python2 をインストールします。 ansible で導入する場合は raw モジュールを使用します。

ansible コマンド例

ansible xxx.xxx.xxx.xxx --sudo -m raw -a "apt-get --yes install python python-simplejson" -i hosts
  • 導入後
$ which python
/usr/bin/python
$ python -V
Python 2.7.12

playbook 例

ansible-playbook で導入する場合は、 gather_facts: no の指定が必要です。

- hosts: xxxxxx
  become: yes
  gather_facts: no
  pre_tasks:
    - name: 'install python2'
      raw: apt-get --yes install python python-simplejson

python3 で動かす(Ansible 2.2以上)

※ 現時点ではプレビューとのことです。

インベントリで ansible_python_interpreter に python3 を指定します。

xxx.xxx.xxx.xxx ansible_python_interpreter=/usr/bin/python3

/usr/bin/python だけが無い場合

/usr/bin/python2 は有るが /usr/bin/python が無い場合などは、以下いずれかで対応できるかと思います。

Ansible 2.2以上

インベントリで ansible_python_interpreter に python2 を指定します。

xxx.xxx.xxx.xxx ansible_python_interpreter=/usr/bin/python2

Ansible 2.2未満

きちんと検証はしていませんが、シンボリックリンクで動作はするようです。

ln -s /usr/bin/python2 /usr/bin/python

参考URL

DynamoDB Auto Scaling 関連リソース

AWSマネジメントコンソールで新規テーブルを作成すると、デフォルトで Auto Scaling が有効な状態で作成されるようになっているそうです。(変わっていないAWSアカウントもありましたので、既存環境はIAM Role等々を用意しないと切り替わらないのかもしれません。)

  • デフォルトで Auto Scaling 有効

f:id:htnosm:20170714184101p:plain

  • デフォルトで Auto Scaling 無効(既存)

f:id:htnosm:20170714184102p:plain

以下、既存テーブルへ適用しようとした際に調査した内容です。

DynamoDB Auto Scaling 設定値

設定できる最小/最大値は以下の通りです。

  • Provisioned capacity
    • Auto Scaling を有効化した場合は設定不可
  • Auto Scaling
    • Target utilization (%)
      • 20 〜 80
    • Minimum provisioned capacity
      • 1 〜 5
    • Maximum provisioned capacity
      • 5 〜 10000
    • IAM Role
      • AWSマネジメントコンソール上でのデフォルトは DynamoDBAutoscaleRole

DynamoDB Auto Scaling 有効化で作成されるリソース

IAM Role

規定では DynamoDBAutoscaleRole です。 後述のポリシー(DynamoDBAutoscalePolicy)、Trust Relationshipが付与されます。

DynamoDBAutoscalePolicy

"Document": {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "dynamodb:DescribeTable",
                "dynamodb:UpdateTable",
                "cloudwatch:PutMetricAlarm",
                "cloudwatch:DescribeAlarms",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:SetAlarmState",
                "cloudwatch:DeleteAlarms"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

Trust Relationship

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "application-autoscaling.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Application Auto Scaling

スケーリングは DynamoDB での管理ではなく、 Application Auto Scaling での管理となります。

ScalableTarget

テーブル単位で ReadCapacityUnits と WriteCapacityUnits がそれぞれ作成されます。

"ScalableTargets": [
    {
        "ScalableDimension": "dynamodb:table:ReadCapacityUnits",
        "ResourceId": "table/dummy-table",
        "RoleARN": "arn:aws:iam::999999999999:role/service-role/DynamoDBAutoscaleRole",
        "CreationTime": 9999999999.99,
        "MinCapacity": 1,
        "ServiceNamespace": "dynamodb",
        "MaxCapacity": 5
    },
    {
        "ScalableDimension": "dynamodb:table:WriteCapacityUnits",
        "ResourceId": "table/dummy-table",
        "RoleARN": "arn:aws:iam::999999999999:role/service-role/DynamoDBAutoscaleRole",
        "CreationTime": 9999999999.99,
        "MinCapacity": 1,
        "ServiceNamespace": "dynamodb",
        "MaxCapacity": 5
    }
]

ScalingPolicy

テーブル単位で ReadCapacityUnits と WriteCapacityUnits がそれぞれ作成されます。
加えて、スケーリング判断用の CloudWatch Alarm が4つ付随します。

"ScalingPolicies": [
    {
        "PolicyName": "DynamoDBReadCapacityUtilization:table/dummy-table",
        "ScalableDimension": "dynamodb:table:ReadCapacityUnits",
        "ResourceId": "table/dummy-table",
        "CreationTime": 9999999999.999,
        "PolicyARN": "arn:aws:autoscaling:ap-northeast-1:999999999999:scalingPolicy:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:resource/dynamodb/table/dummy-table:policyName/DynamoDBReadCapacityUtilization:table/dummy-table",
        "PolicyType": "TargetTrackingScaling",
        "TargetTrackingScalingPolicyConfiguration": {
            "TargetValue": 70.0,
            "PredefinedMetricSpecification": {
                "PredefinedMetricType": "DynamoDBReadCapacityUtilization"
            }
        },
        "Alarms": [
            {
                "AlarmName": "TargetTracking-table/dummy-table-AlarmHigh-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
                "AlarmARN": "arn:aws:cloudwatch:ap-northeast-1:999999999999:alarm:TargetTracking-table/dummy-table-AlarmHigh-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
            },
            {
                "AlarmName": "TargetTracking-table/dummy-table-AlarmLow-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
                "AlarmARN": "arn:aws:cloudwatch:ap-northeast-1:999999999999:alarm:TargetTracking-table/dummy-table-AlarmLow-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
            },
            {
                "AlarmName": "TargetTracking-table/dummy-table-ProvisionedCapacityHigh-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
                "AlarmARN": "arn:aws:cloudwatch:ap-northeast-1:999999999999:alarm:TargetTracking-table/dummy-table-ProvisionedCapacityHigh-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
            },
            {
                "AlarmName": "TargetTracking-table/dummy-table-ProvisionedCapacityLow-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
                "AlarmARN": "arn:aws:cloudwatch:ap-northeast-1:999999999999:alarm:TargetTracking-table/dummy-table-ProvisionedCapacityLow-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
            }
        ],
        "ServiceNamespace": "dynamodb"
    },
・・・略
]

CloudWatch Alarm

AlarmHigh のみ 5分間、その他は 15分間での設定になっています。 Description に DO NOT EDIT OR DELETE と有り、閾値時間変更は推奨されないようです。

  • AlarmLow
  • AlarmHigh
  • ProvisionedCapacityLow
  • ProvisionedCapacityHigh

AWS CLI チュートリアル

CLI を使用したチュートリアルが公開されていますので、一通り実行してみるとイメージを掴みやすいかと思います。

Using the AWS CLI to Manage DynamoDB Auto Scaling - Amazon DynamoDB

チュートリアル実施時の注意点としては下記のような感じでしょうか。

DynamoDB Auto Scaling 設定は、aws dynamodb ではなく、aws application-autoscaling です。

マネジメントコンソールから作成すると、ScaleOutCooldown/ScaleInCooldown はデフォルト0で作成されます。 マネジメントコンソール上からの変更方法は現時点では提供されていないようです。

Mackerel 自動復旧させないアラートは手動復旧しないとその後のアラートが通知されないことがあるので気を付ける

経緯

Mackerel のチェック監視に prevent_alert_auto_close オプションが追加されました。

自動復旧しないアラート ということで、ログ監視に利用できるかと考えたのですが、思っていた内容とは少し異なる動きでした。

やりたかったこと

  • check-log でのアラート発生時の後に通知される 復旧通知(OK)を無くしたい

f:id:htnosm:20170614214813p:plain

ログの監視なのでアラート通知されればよく、復旧通知は不要と思っています。

実際

test_1.log を prevent_alert_auto_close = true として、2つのログファイルに同一タイミングで同一メッセージを出力して確認します。

[plugin.checks.test_1_log]
command = '''
  check-log \
    --file /var/log/test_1.log \
    --pattern 'ERROR' \
    --warning-over 0 \
    --critical-over 0 \
    --return
'''
prevent_alert_auto_close = true

[plugin.checks.test_2_log]
command = '''
  check-log \
    --file /var/log/test_2.log \
    --pattern 'ERROR' \
    --warning-over 0 \
    --critical-over 0 \
    --return
'''

アラート1回目

test_1 は復旧通知が無いため、要望を満たせたように見えます。

  • test_1 (Auto Close 無し)

f:id:htnosm:20170614214814p:plain

  • test_2 (Auto Close)

f:id:htnosm:20170614214815p:plain

  • 通知結果

f:id:htnosm:20170614214816p:plain

アラート2回目

test_1 はアラートが発生しません。

  • 通知結果

f:id:htnosm:20170614214817p:plain

アラート3回目

test_1 を手動で復旧してから、再度ログ出力を行います。 f:id:htnosm:20170614214818p:plain

  • 通知結果

f:id:htnosm:20170614214819p:plain

結論

アラートの復旧を行った状態でないと、次回以降のチェック時にアラート状態であっても通知は行われません。

チェック監視のアラート通知
アラートが発生した場合と、アラート発生後にアラートの状態が変更した場合にアラートの通知が行われます。「アラートの状態が変更した場合」には以下の2つの場合があります。

ステータスが変更になった場合

ex. CRITICAL -> WARNING, WARNING -> CRITICAL, CRITICAL -> OK

ステータスがOKになった場合も含みます

チェックプラグインが送信してくるメッセージの内容が変わった場合

ということで、 prevent_alert_auto_close オプション はログ監視(特にエラー時にのみ出力されるログ)には向かないようです。

復旧通知の無効化や、某abbixの 障害イベントを継続して生成 のような機能の実装を待ちます。

Datadog 通知先振分あれやこれや

Datadog Monitor 通知先の振り分け設定パターンです。

f:id:htnosm:20170611174402j:plain

前提

通知先のインテグレーション設定を済ませておきます。 今回は Slack インテグレーションで試してます。

f:id:htnosm:20170611174403p:plain

ちなみに今回は通知先しか設定していませんが、同様に通知する本文も振り分け先により変更できます。

基本形

Monitor設定画面の Notify your team から定義済みの通知設定を選択することで、本文(Say what’s happening) に自動的に入力されます。 複数設定も可能です。

f:id:htnosm:20170611174404p:plain

メールアドレス通知については定義済み通知先の他に、直接指定も可能です。

(例えばuser@example.comなら@user@example.comと記述)。

アラートレベルで振分

テンプレート変数を利用し、Alert/Warning/Recoveryなどで通知先を振り分けます。

本文に以下のように記載することで、正しい値であればNotify your teamが自動入力されます。

f:id:htnosm:20170611174405p:plain

タグの値で振分

テンプレート変数の亜種です。 match変数を利用し、指定したタグの値により通知先を振り分けます。

f:id:htnosm:20170611174406p:plain

{{#is_match “タグ変数” “文字列”}}
ここに、一致した場合に表示する本文を記述します。
{{/is_match}}

ドキュメントに記載が無いですが、 exact_match 変数が存在します。 使い方は match と同じです。

{{#is_exact_match “タグ変数” “文字列”}}
ここに、一致した場合に表示する本文を記述します。
{{/is_exact_match}}

match と exact_match の違いは、 match = 中間一致、exact_match = 完全一致 のようです。

タグで指定

ドキュメントに記載はありません。明確に駄目とも記載は無いので今の所は利用可能なようです。
通知先を設定する @〜 部分にタグを埋め込みます。
Monitor画面上は通知先が決定されていないため、Notify your teamには値が入りません。 また、同一タグ名で複数値がある場合はカンマ区切りで設定され、両方へ通知が成されるようです。

f:id:htnosm:20170611174407p:plain

例として、 対象に slack_channel_name というタグを付与しています。

slack_channel_name:alert_yabai   i-04bxxxxxxxxx51fc0
slack_channel_name:alert_sodemonai  i-093xxxxxxxxx1b20d
  • alert_sodemonai

f:id:htnosm:20170611174408p:plain

  • alert_yabai

f:id:htnosm:20170611174409p:plain

Terraform Datadog Provider の Import と tf 変換

Terraform Datadog Provider で利用できるリソースの内、Downtime,Monitor,User がインポートに対応しています。

Downtime,MonitorはそれぞれのID、UserはDatadogアカウントのメールアドレスを指定することでインポートが可能です。

# Downtime
terraform import datadog_downtime."リソース名" "ダウンタイムID"
# Monitor
terraform import datadog_monitor."リソース名" "モニターID"
# User
terraform import datadog_user."リソース名" "ユーザメールアドレス"

使用する ID などはそれぞれ以下のページで確認できます。

インポート例

$ terraform import datadog_monitor.monitor1 XXXX773
datadog_monitor.monitor1: Importing from ID "XXXX773"...
datadog_monitor.monitor1: Import complete!
  Imported datadog_monitor (ID: XXXX773)
datadog_monitor.monitor1: Refreshing state... (ID: XXXX773)

Import success! The resources imported are shown above. These are
now in your Terraform state. Import does not currently generate
configuration, so you must do this next. If you do not create configuration
for the above resources, then the next `terraform plan` will mark
them for destruction.

存在しないIDを指定するとエラーになります。

$ terraform import datadog_monitor.not_exists_monitor XXXX779
datadog_monitor.not_exists_monitor: Importing from ID "XXXX779"...
Error importing: 1 error(s) occurred:

* datadog_monitor.not_exists_monitor (import id: XXXX779): import datadog_monitor.not_exists_monitor (id: XXXX779): API error 404 Not Found: {"errors":["Monitor not found"]}

インポート後の状態

tfファイルは生成されないため、そのまま実行すると削除(destroy)となります。
以下はいくつかのリソースをインポートした後に plan を実行した例です。

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

datadog_downtime.daily_mute: Refreshing state... (ID: XXXXXX759)
datadog_user.new_user: Refreshing state... (ID: new@example.com)
datadog_downtime.cpu_exceeds: Refreshing state... (ID: XXXXXX289)
datadog_monitor.datadog-agentup: Refreshing state... (ID: XXXX789)
datadog_monitor.clock_in_sync: Refreshing state... (ID: XXXX121)
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

- datadog_downtime.cpu_exceeds

- datadog_downtime.daily_mute

- datadog_monitor.clock_in_sync

- datadog_monitor.datadog-agentup

- datadog_user.new_user


Plan: 0 to add, 0 to change, 5 to destroy.

tfstate から tf ファイルを生成する

tfファイルを一から書くのは骨が折れるのでスクリプト化してみました。tfファイル生成後に plan を実行すると差分が無くなる事が確認できます。

# 変換用スクリプトをダウンロード
$ wget https://gist.github.com/htnosm/c617ea274e5daf690f19ebe1fc0176f7/raw/b9dcb03417890b9493115b285f1ecd3c148880d0/tf-dd-prov-imp2tf.py
# 変換実行
$ ./tf-dd-prov-imp2tf.py
# downtime.tf、monitor.tf、user.tfが生成される
$ ls -1 *.tf
downtime.tf
main.tf
monitor.tf
user.tf
# plan 確認
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

datadog_downtime.cpu_exceeds: Refreshing state... (ID: XXXXXX289)
datadog_user.new_user: Refreshing state... (ID: new@example.com)
datadog_downtime.daily_mute: Refreshing state... (ID: XXXXXX759)
datadog_monitor.datadog-agentup: Refreshing state... (ID: XXXX789)
datadog_monitor.clock_in_sync: Refreshing state... (ID: XXXX121)
No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, Terraform
doesn't need to do anything.
$
  • tf-dd-prov-imp2tf.py

Convert tfstate to tf for datadog_monitor on Terra …

ドキュメントとの差異等

変換を試した際に公式ドキュメントと実際の設定値での差分や、記載されていない仕様があったので残しておきます。

Downtime 引数 recurrence はインポート未サポート

繰り返し設定がされている Downtime をインポートしても、tfstateに recurrence の値は設定されませんでした。
recurrence を追加したリソースを再度インポートしても取得できなかったため、現状では仕様のようです。

Downtime 引数 active の記載無し

ドキュメントに記載がありませんが、 active 引数が無いと差分として出力されます。
意味としては、そのDowntimeによる mute 状態となっている(true)か、なっていない(開始時刻待ち)(false)かです。