vague memory

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

AWS API Call 数の取得

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



AWSサービス

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

CloudTrail Event

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

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

f:id:htnosm:20180917013940p:plain

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

Trail(証跡)

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

Amazon Macie

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

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

f:id:htnosm:20180917013936p:plain

主要なSaaSAPI実行間隔

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

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分間隔で収集します。サポートへの依頼で間隔を変更することができます。

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

Mackerel

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

New Relic

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]から設定変更も可能です。

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

可視化してみる

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

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

f:id:htnosm:20180917013932p:plain

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

f:id:htnosm:20180917020345p:plain

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

留意点

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

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(証跡)を有効化していないリージョンでも取得が行えていました。

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

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

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

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

没案

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

f:id:htnosm:20180917013928p:plain

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

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

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) を使用します。

f:id:htnosm:20180811161224p:plain



環境

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

対象ログファイル

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

f:id:htnosm:20180811162717p:plain

設定

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

結果例

  • 文字化けする

f:id:htnosm:20180811161216p:plain

fluentd(td-agent)

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

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

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

f:id:htnosm:20180811163048p:plain

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

設定

プラグインインストール

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

f:id:htnosm:20180811162934p:plain

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 公式のプラグインです。

インストール

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 を付与しているが、一覧上は抜けた状態

f:id:htnosm:20180811161355p:plain f:id:htnosm:20180811161351p:plain

b) file Output Plugin

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

設定

以下の様に設定します。

<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": ""}

f:id:htnosm:20180811161347p:plain

サービス化

公式の手順通りに 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'

f:id:htnosm:20180811163137p:plain

折角なので 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

f:id:htnosm:20180811161336p:plain


まとめ

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

  • 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 での連携も追加されているので併せて確認します。

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



環境

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

  • 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
  • 日本語化

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

f:id:htnosm:20180730032744p:plain

サービスチェック

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 上への通知を確認できます。

f:id:htnosm:20180730032741p:plain

Logs

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

設定ファイル(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 *

f:id:htnosm:20180730032737p:plain

  • Datadog Logs

f:id:htnosm:20180730032733p:plain

Status Remap

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

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

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

facet

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

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

f:id:htnosm:20180730032730p:plain

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

f:id:htnosm:20180730032831p:plain

Pipelines

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

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

f:id:htnosm:20180730032828p:plain

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(情報)

f:id:htnosm:20180730032824p:plain

Status Remapper

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

f:id:htnosm:20180730032821p:plain

Status Remap 結果

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

f:id:htnosm:20180730032818p:plain

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

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

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

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



f:id:htnosm:20180720143657p:plain

Limitless Logs

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

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

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

f:id:htnosm:20180720141750p:plain

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

f:id:htnosm:20180720141746p:plain

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

Archive Logs

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バケットに公式記載のバケットポリシーを設定します。

Define Archive

S3 Bucket と Path を設定します。

f:id:htnosm:20180720141741p:plain

設定後から、取り込まれたログが 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

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

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

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

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

結構前からアナウンスはされているのですが、すぐ忘れるので残しておきます。
Datadog だけでは無いですが、Slack側仕様変更により、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

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

Datadog Monitor → Slack

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

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

<@slackbot>

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

<@USLACKBOT>

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

  • いずれも Slack 上では @slackbot として見える
<@USLACKBOT|slackbot> 
<@USLACKBOT|hoge>

アナウンスメンション

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

<!here>
<!channel>

チャンネルIDのリンク

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

<#channelid>

Slack の ID

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

ユーザID (member ID)

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

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

f:id:htnosm:20180514031355p:plain

チャンネルID

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

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

f:id:htnosm:20180514030521p:plain


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

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

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

が、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通りです。

# 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}"
・・・
}

作成結果

f:id:htnosm:20180503180952p:plain f:id:htnosm:20180503180953p:plain


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

Nagios ntpチェック

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

f:id:htnosm:20180430175450j:plain

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


目次


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

/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 の正常性チェックプラグインは無いようです。

          +-------------------+-------------------+------------------+
          |  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)

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

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

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

参考URL