AWS API Call 数の取得

AWSの監視をCloudWatch以外(SaaS等)で行っている場合に、AWS API のコール数が気になります。
CloudTrail で証跡を保存、解析すれば詳細に分析できると思いますが、諸事情によりその手法が使えなかったので調べてみました。

---

---

AWSサービス

関連するAWSサービスの概要です。

CloudTrail Event

APIの実行履歴は CloudTrail Event で表示・取得できます。

• How CloudTrail Works - AWS CloudTrail
  • CloudTrail Workflow - AWS CloudTrail

CloudTrail は、作成時に AWS アカウントで有効になります。AWS アカウントでアクティビティが発生した場合、そのアクティビティは CloudTrail イベントに記録されます。

Trail(証跡)が有効である必要はありません。ここでのTrail(証跡)は S3 等への転送を指します。

Trail(証跡)

CloudTrail Event を S3バケットや CloudWatch Logs へ転送する設定が行なえます。

• Logging Data and Management Events for Trails - AWS CloudTrail

Amazon Macie

機械学習によるユーザ動向の分析が行えるサービスです。

• What Is Amazon Macie? - Amazon Macie

データソースとして AWS CloudTrail イベントログを利用できます。上記 Trail(証跡) を使用します。 また、現時点ではバージニアとオレゴンリージョンのみの提供です。

主要なSaaSのAPI実行間隔

AWSの統合機能がある主要な SaaS の API 実行間隔の情報です。

Datadog

• AWS Integration and CloudWatch FAQ – Datadog

We use the CloudWatch monitoring APIs to monitor your AWS resources. Our main use of these APIs is to gather raw metrics data through the GetMetricStatistics endpoint.

By default, we collect AWS metrics every 10 minutes.

デフォルトでは10分間隔で収集します。サポートへの依頼で間隔を変更することができます。

• Using Datadog's AWS Billing Integration to monitor your CloudWatch usage – Datadog

現時点では API コール数を参照する方法は用意されておらず、 AWS Biling インテグレーションを利用し、請求額を参照する事で把握する方法が紹介されています。

Mackerel

• AWSインテグレーション - Mackerel ヘルプ

5分ごとに取得対象となるメトリックの数だけAWSのAPIをコールして値を取得します。

New Relic

• Polling intervals for AWS integrations | New Relic Documentation

By default, the polling interval frequency is set to the maximum. You can change the polling frequency in the configuration settings.

サービス毎に異なり、デフォルトでは 1分 or 5分毎となるようです。[Configure]から設定変更も可能です。

• New AWS API for Cost Savings & Improved Performance - Support: Products & Agents / API - New Relic Explorers Hub

AWS Account Status Dashboard からAPIコール数を参照できるようです。

可視化してみる

New Relic の AWS Account Status Dashboard と同等の物を Datadog で作成してみます。

• GitHub - htnosm/dd-aws-apicall-metrics: Post AWS API Events metrics to Datadog

定期的に CloudTrail Event を収集し、サマリを Datadog のカスタムメトリクスとして登録します。
今回は Datadog AWSインテグレーション用IAMロールを対象とし、Datadog へ送信していますが、仕組み的に応用は効きそうです。

host を aws_account_no として登録しています。

尚、Datadog で Custom Metrics を扱うには有償プランである必要があるようです。

• Pricing | Datadog

留意点

LookupEvents を使用して CloudTrail Event を取得します。

• LookupEvents - AWS CloudTrail

The rate of lookup requests is limited to one per second per account. If this limit is exceeded, a throttling error occurs.

Lookup には1秒に1回の実行制限があります。

Events that occurred during the selected time range will not be available for lookup if CloudTrail logging was not enabled when the events occurred.

logging が有効であることが条件との記載がありますが、確認した限りではTrail(証跡)を有効化していないリージョンでも取得が行えていました。

• How CloudTrail Works - AWS CloudTrail

CloudTrail typically delivers log files within 15 minutes of account activity.

Event が即時反映されないように見えたので、ドキュメントにあるよう、15分前の値を取得しています。

• Logging Amazon CloudWatch API Calls with AWS CloudTrail - Amazon CloudWatch https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/logging_cw_api_calls.html

CloudWatch supports logging the following actions as events in CloudTrail log files:

Trail に出力されるAPIのみが対象になります。 叩かれているであろう GetMetricStatistics 等は残念ながら対象外です。

没案

CloudWatch のカスタムメトリクスとして登録する方法も考えましたが、 リージョン跨いで参照したかったのと、APIコール数参照のためにAPIコール数を増やすのもいかがなものかと思い、止めました。

Datadog Logs Windows上の日本語ログ(SJIS)登録

Windows 上の Datadog Agent v6 でのログを tail で収集する場合、対象のログファイルは UTF8 である必要があるとのことです。

• Log Collection & Integrations

Note: If you are using the Windows 6 Agent and trailing files for logs - make sure that those files have a UTF8 encoding.

SJISのログを送信すると文字化けしてしまうので、UTF8へ変換しつつのログ送信を検証します。
Datadogのマニュアルに未サポートのログファイルに対しては、ログ転送ソフトを介して送信するよう案内があります。 td-agent 3 が Windows をサポートしたので、今回は td-agent(fluentd) を使用します。

---

---

環境

• Windows Server 2012 R2 Standard
  • Datadog Agent Version 6.3.3
  • td-agent Version v3.1.1 (Fluentd v1.0.2)

対象ログファイル

以下の様な Shift_JIS 日本語を含むログファイルを対象とします。

設定

Datadog Agent

ログ収集機能を有効化します。

• [Datadog Agent Manager] -> [Settings]
  • 実体は C:\ProgramData\Datadog\datadog.yaml

log_enabled: true

カスタムログ用ファイル格納

任意の名称で設定ファイルを格納します。

mkdir C:\ProgramData\Datadog\conf.d\customlog.d
echo. > C:\ProgramData\Datadog\conf.d\customlog.d\conf.yaml

ディレクトリとファイルを作成することで、 GUI にも表示されるようになります。

• [Datadog Agent Manager] -> [Checks] -> [Manage Checks]

Datadog Agent (v6)

datadog-agent(v6) 標準機能でのログ収集設定です。

• customlog.d\conf.yaml

logs:

  - type: file
    path: C:\log\test.log
    service: app
    source: customlog

結果例

• 文字化けする

fluentd(td-agent)

fluentd で変換して取り込む設定です。 2パターン検証しましたが、いずれでも日本語文字列の文字化けは回避できました。

td-agent3 から Windows をサポートしています。

• Installing Fluentd using .msi Installer (Windows)

現時点での最新版 version v3.1.1 からは beta の文字が取れていました。

文字コード変換には fluent-plugin-record-modifier の char_encoding を使用します。

• repeatedly/fluent-plugin-record-modifier

設定

プラグインインストール

td-agent をインストールすると td-agent command prompt が利用できますので、そこからプラグインをインストールします。

C:\opt\td-agent>fluent-gem install fluent-plugin-record-modifier
WARN: Unresolved specs during Gem::Specification.reset:
      win32-api (>= 1.4.5)
WARN: Clearing out unresolved specs.
Please report a bug if this causes problems.
Fetching: fluent-plugin-record-modifier-1.1.0.gem (100%)
Successfully installed fluent-plugin-record-modifier-1.1.0
Parsing documentation for fluent-plugin-record-modifier-1.1.0
Installing ri documentation for fluent-plugin-record-modifier-1.1.0
Done installing documentation for fluent-plugin-record-modifier after 0 seconds
1 gem installed

ログディレクトリ

pos ファイル格納用のディレクトリを作成しておきます。

C:\opt\td-agent>mkdir var\log

td-agent.conf

td-agent.conf は以下に格納されています。

C:\opt\td-agent\etc\td-agent\td-agent.conf

tail Input と record-modifier の設定を行います。

<source>
  @type tail
  path C:\log\test.log
  pos_file C:\opt\td-agent\var\log\test.log.pos
  tag fluentd.raw
  format none
</source>

<match fluentd.raw>
  @type record_modifier
  tag fluentd.encode
  char_encoding Windows-31J:utf-8
</match>

a) fluent-plugin-datadog

Datadog 公式のプラグインです。

• DataDog/fluent-plugin-datadog

インストール

C:\opt\td-agent>fluent-gem install fluent-plugin-datadog
WARN: Unresolved specs during Gem::Specification.reset:
      win32-api (>= 1.4.5)
WARN: Clearing out unresolved specs.
Please report a bug if this causes problems.
Fetching: fluent-plugin-datadog-0.10.4.gem (100%)
Successfully installed fluent-plugin-datadog-0.10.4
Parsing documentation for fluent-plugin-datadog-0.10.4
Installing ri documentation for fluent-plugin-datadog-0.10.4
Done installing documentation for fluent-plugin-datadog after 0 seconds
1 gem installed

設定

以下の様に設定します。 (便宜的に store を使用していますが、出力先が一つであれば不要です)

<match fluentd.encode>
  @type copy
  <store>
    @type datadog
    @id awesome_agent
    api_key <your api key>

    # Optional
    include_tag_key true
    tag_key 'tag'

    # Optional parameters
    dd_source customlog
    dd_tags 'host:WIN-XXXXXXXXXXX,service: app,filename:test.log'
    dd_sourcecategory multibytes
  </store>
</match>

結果例

• 文字化け解消
• Host、Serviceが付かない
  • dd_tags で Tag を付与しているが、一覧上は抜けた状態

b) file Output Plugin

fluentd 標準で何とかする案です。変換後のファイルを Datadog Agent に読ませます。

• file Output Plugin

設定

以下の様に設定します。

<match fluentd.encode>
  @type copy
  <store>
    @type file
    path C:\log\test.utc8.log
    append true
  </store>
</match>

• customlog.d\conf.yaml

logs:

  - type: file
    path: C:\log\test.utc8.log\*.log
    service: app
    source: customlog

結果例

• 文字化け解消
• Datadog Agent 側の設定に沿って Host,Servce,Source が付与
• ログ部分は JSON 形式 {"message": ""}

サービス化

公式の手順通りに fluentd を Windows サービス化します。

• td-agent command prompt

fluentd --reg-winsvc i
fluentd --reg-winsvc-fluentdopt '-c C:/opt/td-agent/etc/td-agent/td-agent.conf -o C:/opt/td-agent/var/log/td-agent.log'

折角なので fluentd の監視 ( FluentD ) も入れます。

• td-agent.conf

<source>
  type monitor_agent
  bind 0.0.0.0
  port 24220
</source>

• Datadog (conf.d/fluentd.yaml)

init_config:

instances:
    -  monitor_agent_url: http://example.com:24220/api/plugins.json

---

まとめ

日本語ログは扱いに困ります。

• Windows での Datadog Agent(v6) Logs は UTF8 でないと文字化けする
• UTF8 へ変換することで文字化けは解消可能(今回は fluentd を利用)
  • a案 fluent-plugin-datadog は Host、Service が付与されない
  • b案 file Output で別ファイルに書き出す事場合は出力形式が変わる

公式プラグインがイマイチだったのでb案を試してみた感じですが、性能面は全く見てないので実際使えるかは要検証です。

Datadog win32_event_log (v6 日本語環境)

以前日本語環境のWindows上で、イベントログ送信がうまく動作しなかったので現状(v6)ではどうなっているのかを確認します。 また、 Logs での連携も追加されているので併せて確認します。

• DatadogAgent を Windows10(日本語環境) へインストール - vague memory
  • 以前確認した Version は 5.17

結果 Agent Version 6 でのマルチロケーション対応はされており、そのまま利用できました。

• 2019/01/09 追記

Win32eventlog について、検証に誤りがありました。 再度確認した所、Agent Version 5 同様、日本語対応は為されていませんでした。 システムアカウントの言語設定が日本語だと動作しません。 下記確認はログインユーザの言語設定のみ日本語にした状態での実施でした。

---

---

環境

確認した環境は以下です。

• Win 2012

Agent Version: 6.3.3
Go Version: 1.10.3 
Platform: Windows Server 2012 R2 Standard
Platform Version: 6.3 Build 9600

• Win 2018

Agent Version: 6.3.3
Go Version: 1.10.3 
Platform: Windows Server 2016 Datacenter
Platform Version: 10.0 Build 14393

• 日本語化

イベントビューアーは日本語で表示されている状態です。

サービスチェック

• Win 32 event log

Datadog Agent Manager にてインテグレーション設定を追加します。

• [Checks] -> [Manage Checks] -> [Add a Check]
  • [win32_event_log]

設定ファイルの内容は以下のようにしています。

• win32_event_log.d/conf.yaml

init_config:

instances:

  - log_file:
      - System
    type:
      - Error
    tags:
      - system

イベントビューアー上で "エラー" を発生させると、Datadog Events 上への通知を確認できます。

Logs

Logs での取得も確認します。

• Windows Event Log

設定ファイル(win32_event_log.d/conf.yaml)に logs ディレクティブ を追加します。

logs:
  - type: windows_event
    channel_path: System
    source: System
    service: eventlog
    sourcecategory: windowsevent

channel_path へは LogName を指定します。 LogName は PowerShell コマンドで参照できます。

Get-WinEvent -ListLog *

• Windows Event Viewer

• Datadog Logs

Status Remap

ここまでは特に躓かずに設定できたのですが、少々違和感が残ります。

イベントビューアー上、"エラー"や"警告"であるにも関わらず、Datadog Logs での Status が全て "INFO" になってしまいます。

他に良い方法があるかもしれませんが、下記の様に設定追加を行うことで Status を認識させる事ができました。(直接Remapすれば良さそうですが、効かなかったので一段噛ませています)

facet

facet と呼ばれる属性値を作成します。 Event.System.Level にイベントビューアー上のレベルに対応するエラーレベルがあります。

• [Logs] -> [Explorer]
  • 対象のログ詳細上の [ATTRIBUTES]
    • Create facet for @Event.System.Level

facet 作成後にログを受信すると左ペインにフィルタ用のチェックボックスが出力されます。

Pipelines

Windows Eventlog 用の Pipeline を作成します。

• [Logs] -> [Pipelines] -> [New Pipeline]
  • Filter: service:eventlog
  • Name: windowsevent

Category Processor

上記 Pipeline にカテゴリプロセッサを作成します。 作成済みの facet "@Event.System.Level" に対し、それぞれ以下の値を置き換えます。

Name	MATCHING QUERY	Event Viewer EntryType
Critical	@Event.System.Level:2	Error(エラー)
Warning	@Event.System.Level:3	Warning(警告)
Info	@Event.System.Level:4	Information(情報)

Status Remapper

作成したカテゴリをステータスに割り当てます。

Status Remap 結果

正常に認識されると Datadog Logs 上の Status での絞り込みが可能になります。

Datadog Logs アーカイブ機能の追加等

Datadog Logs のアップデートがありました。 大きく以下3つの機能が追加されています。

• Introducing Logging without Limits
  • Limitless Logs
    • ログ取り込みとインデキシング(フィルタリング)の分離
  • Archive Logs
    • ストレージ転送
  • Live Tail
    • リアルタイムログストリーム

既に公式ドキュメントも公開されていますが、ポイントを整理します。

---

---

Limitless Logs

• Logging without Limits

送信元でのフィルタを行わず、 Datadog 管理画面上でフィルタが可能です。 フィルタにより除外されたログは、Datadog Logs 課金対象からも除外されます。 後述 Archive の対象となるので、収集・保存のみ行える事になります。(保存先の料金は掛かります)

Live Tail には含まれるので、Live Tail で参照しつつ、除外条件を作成していく流れになると思います。

[Logs] -> [Pipelines] -> [INDEXES] -> [Add an Exclusion Filter] より除外フィルタを作成します。

クエリによる除外フィルタ、サンプリングレートの指定と有効/無効切替が行えます。

尚、送信元(Datadog Agent)側でフィルタしたい(送信対象としない)場合は、log_processing_rules で exclude_at_match や include_at_match を使用します。

Archive Logs

• Archives on AWS S3

AWS S3 へのアーカイブ機能です。 AWS インテグレーションで使用している AWS アカウントとは関連無く、任意の S3 バケットへのログ転送が行えます。

転送されるログは、PIPELINES(Processor)経由後のログです。INDEXES(Exclusion Filter)有無は関係ありません。

公式ブログ上に (with support for other endpoints to come) とあるので、今後S3以外のストレージが追加されそうですが、現状は AWS S3 のみのサポートです。

設定には Datadog の管理者権限(Admin User) が必要です。管理者以外は設定の参照は可能ですが、変更はできません。

[Logs] -> [Pipelines] -> [ARCHIVES] で送信先のS3バケットを指定します。

Configure S3 Bucket

送信先S3バケットに公式記載のバケットポリシーを設定します。

• https://docs.datadoghq.com/logs/s3/#create-and-configure-an-s3-bucket

Define Archive

S3 Bucket と Path を設定します。

設定後から、取り込まれたログが Pipeline 経由後、S3バケットに転送されます。 15分程待つとS3バケットへの転送されていることが確認できます。

Changes have been made to this archive. It can take a few minutes before the next upload attempt.

フォーマット

/my/s3/prefix/dt=20180515/hour=14/archive_143201.1234.7dq1a9mnSya3bFotoErfxl.json.gz

• gzip された JSON
• 日付、時間の HIVE フォーマット

以下 Nginx access.log のJSON出力例です。 attributes はパース結果が反映されます。

{
  "_id": "AWS1oRxxxxxxxxx1bnTi",
  "date": "2018-07-ddThh:mm:ss.0000",
  "service": "nginx",
  "host": "i-xxxxxxxxxxxxxxxxx",
  "attributes": {
    "http": {
      "status_code": 200,
      "referer": "-",
      "useragent": "Datadog Agent/0.0.0",
      "method": "GET",
      "url": "/",
      "version": "1.1",
      "url_details": {
        "path": "/"
      },
・・・・
  },
  "source": "nginx",
  "message": "127.0.0.1 - - [dd/Jul/2018:hh:mm:ss.0000] \"GET / HTTP/1.1\" 200 396 \"-\" \"Datadog Agent/0.0.0\"",
  "status": "ok"
}

画面上に Main Archive とあるので、複数指定が可能なのかと思いましたが、現状で設定できるのは単一送信先のようです。(契約プラン等で変わるのかもしれません)

また、faset(tag)によるパスやファイルの振り分けは行われません。S3上へ転送したログを検索する際は Athena 等を利用する必要がありそうです。

Live Tail

• Live Tail

(ほぼ)リアルタイムにログイベントを参照できます。

• PIPELINES(Processor)経由後、INDEXES(Exclusion Filter)前
• ストリーム表示の一時停止は可能
• 過去へ遡る事はできない

リアルタイム版 Explorer のような感じです。

Slack ユーザメンションの仕様変更 (Datadog例)

結構前からアナウンスはされているのですが、すぐ忘れるので残しておきます。
Datadog だけでは無いですが、Slack側仕様変更により、Slack上の個別ユーザへメンションする際の指定の仕方が変わります。

• A lingering farewell to the username | Slack

The undocumented approach to mentioning users via the API — <@username> — will no longer function after September 12, 2018. Please reference with the user ID format (<@U123>) instead

既に始まっていて、使えなくなっている状況もあるようです。

• Slack APIでユーザー宛のメンションができなくなったので対策した - Qiita

2023/03/06 グループIDの取得方法と公式リンクを追記しました。

Datadog Monitor → Slack

Slack Integration を設定することでSlackへの通知が可能です。 @slack-〜 でSlackチャンネルへの通知設定を入れている状態で以下のようにするとユーザメンションになります。

旧

不等号(<>) で囲って @ユーザ名

<@slackbot>

新

不等号(<>) で囲って @ユーザID

<@USLACKBOT>

username_like_string とやらも使えるようですが、 試した所特に Alias としては機能していないようでした。Slackとしては非推奨のようなので利用しない方が良いかと思います。

• いずれも Slack 上では @slackbot として見える

<@USLACKBOT|slackbot> 
<@USLACKBOT|hoge>

グループ

`<!subteam^ID>`

アナウンスメンション

• Slack でアナウンスをする – Slack
• Basic message formatting | Slack

@here や @channel での通知設定も可能です。

<!here>
<!channel>

チャンネルIDのリンク

#general のようなチャンネルのリンクを通知に載せたい場合は #にチャンネルIDです。
存在しないIDを指定すると #unknown-channel と変換されました。

<#channelid>

Slack の ID

APIで取得するか、後述する方法で取得できます。

• API
  • https://api.slack.com/methods/users.list/test
  • https://api.slack.com/methods/channels.list/test
  • https://api.slack.com/methods/usergroups.list/test

ユーザID (member ID)

クライアントからは以下のように取得が可能です。

• [View profile] -> [Copy member ID]

チャンネルID

対象のチャンネルを右クリック -> [Copy URL]

# XXXXXXXXX = Channel ID
https://*****.slack.com/messages/XXXXXXXXX

グループID

[Peaple & user groups] -> [User groups] -> 対象のグループを右クリック -> [Copy]

---

別途お知らせはあると思いますが、 <@username> 形式は 2018/09/12 で廃止されるとのことなのでお気をつけください。

• 公式ドキュメント: Formatting text for app surfaces | Slack

Terraform Datadog Provider を使用した Monitor のテンプレート化

Datadog Monitor の定義を Terraform で管理できます。

• Provider: Datadog

が、Datadog側がJSONで定義されており少々書き難いのと、 Monitor毎に同じ記載を繰り返す部分(通知本文や通知先)をテンプレート化できないものかと思い、考えてみた結果をメモ。

Terraform の Template Provider で実現します。 バージョンによっては動作しないですし、もっと良い方法・書き方が有りそうではあります。

---

目次

---

要件

• 複数 Monitor の通知本文、通知先を一括変更したい
• 通知先をアラートレベルにより変更したい
• 通知本文をヒアドキュメント化したい
  • 改行文字(\n)入れつつ、1行で書くのを止めたい

環境

$ terraform version
Terraform v0.11.3
+ provider.datadog v1.0.3
+ provider.template v1.0.0

ファイル構成

使用したファイルは tf-dd-prov-monitor-template に上げています。

.
├── datadog_key.auto.tfvars      # APIKey定義
├── datadog_monitor.auto.tfvars  # 通知先定義
├── datadog_monitor.tf           # provider定義
├── datadog_monitor_template.tf  # template定義
├── ec2.tf
├── templates                    # テンプレートファイル群
│   ├── message.tmpl             # 通知本文用
│   └── notify.tmpl              # 通知先用
├── terraform.tfstate
└── terraform.tfstate.backup

以下、上から順にファイル内容の説明です。

datadog_key.auto.tfvars

Datadog の API Key、 Application Key 値を設定します。 git 管理する場合等は .gitignore に入れる候補になるかと思います。

datadog_api_key=""
datadog_app_key=""

datadog_monitor.auto.tfvars

通知先のリストを設定します。 @slack-〜 が通知先です。(例ではSlackのみですがメールアドレス等や他インテグレーションでも良いです)
アラートレベルにより通知先が変更できるようにします。

# all
notify_all = [
  "@slack-alert0",
  "@slack-alert-all",
]
# only alert
notify_is_alert = [
  "@slack-alert1",
  "@slack-alert-only",
]
notify_is_alert_recovery = []
・・・

datadog_monitor.tf

Datadog Provider を定義します。 公式Doc通りです。

• Provider: Datadog - Terraform by HashiCorp

# Variables
variable "datadog_api_key" {}
variable "datadog_app_key" {}

# Configure the Datadog provider
provider "datadog" {
  version = "~> 1.0"
  api_key = "${var.datadog_api_key}"
  app_key = "${var.datadog_app_key}"
}

datadog_monitor_template.tf

今回の肝になるテンプレート定義です。 定義した通知先リスト変数を並べて、テンプレートに渡します。

# 通知先リスト変数定義
variable "notify_all" { type = "list" }
variable "notify_is_alert" { type = "list" }
variable "notify_is_alert_recovery" { type = "list" }
・・・
# 通知先リストを文字列置換
locals {
  notify_all_join = "${ length(var.notify_all) == 0 ? "" : join(" ", var.notify_all) }"
  notify_all = " ${local.notify_all_join} "
  # is
  notify_is_alert_join = "${ length(var.notify_is_alert) == 0 ? "" : join(" ", var.notify_is_alert) }"
  notify_is_alert = " {{#is_alert}} ${local.notify_is_alert_join} {{/is_alert}} "
  notify_is_alert_recovery_join = "${ length(var.notify_is_alert) == 0 ? "" : join(" ", var.notify_is_alert) }"
  notify_is_alert_recovery = " {{#is_alert_recovery}} ${local.notify_is_alert_recovery_join} {{/is_alert_recovery}} "
・・・
}
# テンプレートファイルを定義
## 変数渡し無し
data "template_file" "message" {
  template = "${file("./templates/message.tmpl")}"
}
## 変数渡し有り
data "template_file" "notify" {
  template = "${file("./templates/notify.tmpl")}"
  vars {
    notify_all = "${ local.notify_all_join == "" ? "" : local.notify_all }"
    # is
    notify_is_alert = "${ local.notify_is_alert_join == "" ? "" : local.notify_is_alert }"
    notify_is_alert_recovery = "${ local.notify_is_alert_recovery_join == "" ? "" : local.notify_is_alert_recovery }"
・・・
  }
}

templates/

例では2つしか置いてませんが、定義を増やす事でテンプレートは増やせます。

message.tmpl

通知本文用のテンプレート、変数引渡し無しverの例になります。

Metric Value: {{value}} {{comparator}} threshold: {{#is_warning}}{{warn_threshold}}{{/is_warning}}{{#is_warning_recovery}}{{warn_threshold}}{{/is_warning_recovery}}{{#is_alert}}{{threshold}}{{/is_alert}}{{#is_alert_recovery}}{{threshold}}{{/is_alert_recovery}}

- Host: {{host.name}}

notify.tmpl

通知先用のテンプレート例です。変数引渡しを行い、アラートレベルにより通知先リストを設定させます。

More information: [Ops Guide](http://example.com)

Notify:${notify_all}${notify_is_alert}${notify_is_alert_recovery}${notify_is_warning}${notify_is_warning_recovery}${notify_is_recovery}${notify_is_no_data}${notify_is_not_alert}${notify_is_not_alert_recovery}${notify_is_not_warning}${notify_is_not_warning_recovery}${notify_is_not_recovery}${notify_is_not_no_data}

作成例

ec2.tf に datadog_monitor の resource 定義をします。
message、escalation_message にテンプレートを設定(data.template_file.〜.rendered 部分)します。

例では2つの resource を定義し、message に個別の記述と、テンプレート記述設定をしています。

resource "datadog_monitor" "ec2_cpuutilization" {
  type = "query alert"
  name = "[TEST] EC2 CPU Utilization"
  query = "max(last_5m):max:aws.ec2.cpuutilization{name:test-instance-al2-0} by {host,name,region} > 99"
  message = "# [TEST] EC2 CPU Utilization\n${data.template_file.message.rendered}${data.template_file.notify.rendered}"
  escalation_message = "**Renotify**\n# [TEST] EC2 CPU Utilization\n${data.template_file.message.rendered}${data.template_file.notify.rendered}"
・・・
}

resource "datadog_monitor" "ec2_status_check_failed" {
  type = "query alert"
  name = "[TEST] EC2 StatusCheckFailed"
  query = "min(last_15m):max:aws.ec2.status_check_failed{name:test-instance-al2-0} by {host,name,region} > 0"
  message = "# [TEST] EC2 StatusCheckFailed\n${data.template_file.message.rendered}${data.template_file.notify.rendered}"
  escalation_message = "**Renotify**\n# [hoge] EC2 StatusCheckFailed\n${data.template_file.message.rendered}${data.template_file.notify.rendered}"
・・・
}

作成結果

---

通知本文の一部を共通化し、一括更新を行うことができるようになりました。
懸念は Terraform の更新頻度が高いため、仕様変更により動作しなくなる可能性でしょうか。
Datadog側標準機能でテンプレート化、通知先グループの設定などを実装して欲しい所です。

Nagios ntpチェック

Nagios を利用して時刻同期の監視を行う場合にプラグインが複数有り、ヘルプのみだと腑に落ちなかったので簡単にまとめます。

公式プラグイン集をベースに確認します。

• Nagios Plugins | The home of the official Nagios® Plugins

---

目次

---

Nagios ntp plugins

公式プラグインとして用意されているのは以下です。

• check_ntp
• check_ntp_peer
• check_ntp_time

check_ntp は現在は非推奨となっており、 check_ntp_peer または check_ntp_time を利用します。

check_ntp_peer = ntpサーバの正常性チェック
check_ntp_time = ntpプロトコルを利用して時刻同期のチェック
となります。
check_time というプラグインもありますが、こちらは timeプロトコルを利用して時刻同期のチェックを行うようです。 (timeサービスでの時刻同期を行っている環境に出会ったことが無いので今回は割愛)

check_ntp_peer

• nagios-plugins/check_ntp_peer.c at master · nagios-plugins/nagios-plugins
  • NTPサーバの正常性をチェック
  • localhost(監視対象ホスト)とNTPサーバ間の時刻はチェックしない

/usr/lib64/nagios/plugins/check_ntp_peer -H localhost -w 1 -c 2

-H には監視対象のntpdが動作しているホストを指定します。 上記の場合 localhost 上で動作している ntpd の同期状態をチェックします。
ntpd が動作していること が前提です。ntpdが同期対象としているNTPサーバとの比較になります。

独自NTPサーバを参照している等で不正な値(実際の時刻とはずれている)を返してきている場合でも、参照しているNTPサーバとの同期が取れている状態であれば正常と判断されます。

chrony 未サポート

chrony は未サポートです。 check_ntp_peer は mode 6 で実装されており、 chronyd は mode 6 をサポートしません。
現在公式プラグインでは chronyd の正常性チェックプラグインは無いようです。

• check_ntp_peer with Chrony
• check_ntp_peer relies on insecure NTPd implementation · Issue #57 · nagios-plugins/nagios-plugins
• check_ntp_peer make use of ntp mode 6, supported only ntpd daemon · Issue #1526 · monitoring-plugins/monitoring-plugins
• RFCでのmode定義
  • RFC 5905 - Network Time Protocol Version 4: Protocol and Algorithms Specification
    • Protocol Modes

          +-------------------+-------------------+------------------+
          |  Association Mode | Assoc. Mode Value | Packet Mode Value|
          +-------------------+-------------------+------------------+
          | Symmetric Active  |         1         | 1 or 2           |
          | Symmetric Passive |         2         | 1                |
          | Client            |         3         | 4                |
          | Server            |         4         | 3                |
          | Broadcast Server  |         5         | 5                |
          | Broadcast Client  |         6         | N/A              |
          +-------------------+-------------------+------------------+

check_ntp_time (check_ntp)

• nagios-plugins/check_ntp_time.c at master · nagios-plugins/nagios-plugins

  • localhost(監視対象ホスト)とNTPサーバ間の時刻差をチェック

/usr/lib64/nagios/plugins/check_ntp_time -H ntp.nict.jp -w 1 -c 2

-H には監視対象ホストと比較するNTPサーバを指定します。 localhost を指定した場合は自分自身のNTPサーバとの比較となるため、殆ど意味を成しません。

監視対象ホスト上で時刻同期サービス(ntpd、chronyd、etc...)の起動有無は問いません。

参考URL

• 或るプログラマの一生 » Nagios の check_ntp_peer と check_ntp_time の違い
• Nagiosプラグインの紹介 - インフラエンジニアway - Powered by HEARTBEATS
• NTP監視について – QUICK GUARD スタッフブログ
• Trouble With check_time command - View topic • Support Forum • Nagios