vague memory

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

Datadog dogstream 注意点

ログ管理機能 ( Introducing logs in Datadog ) のリリースが控えていますが、地味にハマったので今更ながら dogstream での注意点を残しておきます。
ちなみにログ管理機能が含まれる予定の Agent version >= 6.0 からはパラメータ自体廃止されているようなので、6.0以降は機能が無くなるようです。
(カスタムメトリクスは DogStatsD 等の別手法で送信した方が良さそうです)



dogstream とは

ファイルに出力された値をメトリクスとして送信する機能です。

有効化

datadog.conf 内の dogstreams へ対象ログファイルを設定します。

dogstreams: /var/log/web.log, /var/log/db.log, /var/log/cache.log

公式ログフォーマット

metric unix_timestamp value [attribute1=v1 attributes2=v2 ...]

上記フォーマットに合致しないログについては、カスタムパーサを用意することで対応します。

注意点

本題です。 公式ドキュメントに記載はありますが、英語ページのみです。日本語ページには記載がありません。

A word of warning:
there is a limit to how many times the same metric can be collected in the same log-pass;
effectively the agent starts to over-write logged metrics with the subsequent submissions of the same metric,
even if they have different attributes (like tags).
This can be somewhat mitigated if the metrics collected from the logs have sufficiently different time-stamps,
but it is generally recommended to only submit one metric to the logs for collection once every 10 seconds or so.
This over-writing is not an issue for metrics collected with differing names.

同一ファイル内の同一メトリクス名での送信は値が上書かれる可能性があります。

以下のような形式でファイルへ出力していたとします。

# metric        unix_timestamp    value  attribute1           attribute2 attribute3
# ---------
publish_time    1514605081        593    metric_type=gauge    unit=ms    stage=prd
publish_time    1514605081        799    metric_type=gauge    unit=ms    stage=stg
publish_time    1514605083        693    metric_type=gauge    unit=ms    stage=stg
publish_time    1514605111        553    metric_type=gauge    unit=ms    stage=prd
publish_time    1514605111        588    metric_type=gauge    unit=ms    stage=stg
・・・

メトリクス名 publish_time とし、stageタグで系列分けが行えるようにします。 Datadog上での表示は以下のようになります。

f:id:htnosm:20180108015941p:plain

上書きが発生する場合

stage=prd の後に stage=stg が出力されているため、後者の値で上書きが発生します。 Datadog側に Datapoint として存在せず、送信できていないかのように見えます。

f:id:htnosm:20180108015954p:plain

公式ドキュメントによると10秒間に一度は出力する事が推奨とあります。 実際に、短時間(数秒)で出力されるログでは発生頻度は低かったですが、数十秒間隔の出力になるとほぼほぼ上書きが発生していました。

回避策

以下いずれかで回避可能です。

  • a) 数秒間隔で出力する
    • 上書きされる頻度は下がる
  • b) メトリクス名を分ける
    • グラフ作成時に複数メトリクス指定が必要になるので、属性(attribute)が増えてくると利用し難い
  • c) 出力ファイルを分ける
    • datadog.conf へ複数ファイル指定が必要

CloudWatch Agent を CLI で EC2 に導入

先日 CloudWatch Agent が発表されました。

SSM Agent 導入が前提、となるとマネジメントコンソールすら使う必要が無いだろうということで、AWS CLI (aws ssm) での導入方法です。

SSM Agent

CloudWatch Agent を使うには、SSM Agent がインストールされていることが前提条件になります。

SSM Agent 導入状況確認

query はお好みで。

$ aws ssm describe-instance-information \
  --query 'sort_by(InstanceInformationList[].{
    InstanceId:InstanceId, ComputerName:ComputerName, ResourceType:ResourceType, PingStatus:PingStatus,
    AgentVersion:AgentVersion, IsLatestVersion:IsLatestVersion
    PlatformType:PlatformType, PlatformName:join(`:`, [ PlatformName, PlatformVersion ])
  },&PlatformName)' \
  --output table
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|                                                                              DescribeInstanceInformation                                                                              |
+--------------+---------------------------------------------------+----------------------+------------------+-------------+---------------------------+---------------+----------------+
| AgentVersion |                   ComputerName                    |     InstanceId       | IsLatestVersion  | PingStatus  |       PlatformName        | PlatformType  | ResourceType   |
+--------------+---------------------------------------------------+----------------------+------------------+-------------+---------------------------+---------------+----------------+
|  2.2.120.0   |  ip-xxx-xx-x-xx.ap-northeast-1.compute.internal   |  i-xxxxxxxxxxxx8632f |  False           |  Online     |  Amazon Linux AMI:2017.09 |  Linux        |  EC2Instance   |
|  2.2.103.0   |  ip-xxx-xx-x-xx                                   |  i-xxxxxxxxxxxx2c23b |  True            |  Online     |  Amazon Linux:2.0         |  Linux        |  EC2Instance   |
・・・

IsLatestVersion ですが、 Amazon Linux 2017.09 版で確認した所 False が返ってきました。
最新版は 2.2.103.0 のはずですが、なぜか 2.2.120.0 が導入されており、マニュフェストに存在しないバージョンのため False となっていたようです。

  • 現時点での最新 Version は "2.2.103.0"
# https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/ssm-agent-manifest.json
{"Name":"amazon-ssm-agent-linux-amd64.tar.gz","Version":"2.2.103.0"}

SSM Agent インストール

未導入の場合はインストールする必要があります。 SSM Agent が居ないことには AWS Systems Manager から実行できないため、EC2インスタンス起動時なり、sshログインなりでインストールを行います。

SSM Agent アップデート

On an Amazon EC2 instance, the CloudWatch agent requires that the instance is running version 2.2.93.0 or later.

バージョン 2.2.93.0 以上が必要なため、SSM Agent が古い場合は AWS-UpdateSSMAgent を使用してアップデートを行います。

$ _DOCNAME="AWS-UpdateSSMAgent"
$ _INSTANCEs="i-xxxxxxxxxxxx2c23b,i-xxxxxxxxxxxx8632f"

$ aws ssm send-command \
  --document-name "${_DOCNAME}" \
  --targets "Key=instanceids,Values=${_INSTANCEs}"

send-command の結果確認

list-command-invocations で実行結果一覧が取得できます。

  • 一覧取得例
$ aws ssm list-command-invocations \
  --query 'sort_by(CommandInvocations[].{
    DocumentName:DocumentName, CommandId:CommandId, InstanceId:InstanceId, InstanceName:InstanceName, Status:Status, StatusDetails:StatusDetails, RequestedDateTime:RequestedDateTime
  }, &RequestedDateTime)' \
  --output table

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|                                                                                      ListCommandInvocations                                                                                       |
+--------------------------------------+-------------------------------+----------------------+---------------------------------------------------+--------------------+----------+-----------------+
|               CommandId              |         DocumentName          |     InstanceId       |                   InstanceName                    | RequestedDateTime  | Status   |  StatusDetails  |
+--------------------------------------+-------------------------------+----------------------+---------------------------------------------------+--------------------+----------+-----------------+
|  XXXXXXXX-ab3e-4aaa-bb72-xxxxxxxxxxxx|  AWS-UpdateSSMAgent           |  i-xxxxxxxxxxxx2c23b |  ip-xxx-xx-x-xx                                   |  1513519181.61     |  Success |  Success        |
|  XXXXXXXX-83d4-4628-a01e-xxxxxxxxxxxx|  AWS-ConfigureAWSPackage      |  i-xxxxxxxxxxxx2c23b |  ip-xxx-xx-x-xx                                   |  1513523228.34     |  Failed  |  Failed         |

get-command-invocation で実行結果詳細が取得できます。 StandardOutputContent と StandardErrorContent が出力結果となります。

  • 詳細取得例
    • command-id、instance-id を指定
$ _CMDID=XXXXXXXX-ab3e-4aaa-bb72-xxxxxxxxxxxx
$ _INSTANCE=i-xxxxxxxxxxxx2c23b

# jq有
$ aws ssm get-command-invocation \
  --command-id ${_CMDID} \
  --instance-id ${_INSTANCE} \
  | jq -r '.StandardOutputContent, .StandardErrorContent'

Updating amazon-ssm-agent from 2.2.120.0 to latest
Successfully downloaded https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/ssm-agent-manifest.json
updating amazon-ssm-agent to an older version, please enable allow downgrade to proceed

# jq無
$ aws ssm get-command-invocation \
  --command-id ${_CMDID} \
  --instance-id ${_INSTANCE} \
  --query '[ StandardOutputContent, StandardErrorContent ]' \
  | awk '{gsub(/\\n/,"\n"); print}'

CloudWatch Agent

CloudWatch Agent インストール

AWS-ConfigureAWSPackage で AmazonCloudWatchAgent を指定することでインストールします。

  • InstanceID での指定例
$ _DOCNAME="AWS-ConfigureAWSPackage"
$ _INSTANCEs="i-xxxxxxxxxxxx2c23b,i-xxxxxxxxxxxx8632f"

$ aws ssm send-command \
  --document-name "${_DOCNAME}" \
  --targets "Key=instanceids,Values=${_INSTANCEs}" \
  --parameters "action=Install, name=AmazonCloudWatchAgent, version=latest"

・・・
Successfully installed arn:aws:ssm:::package/AmazonCloudWatchAgent 1.73.9

構成ファイルの作成

構成ファイルを Parameter Store に格納しておくことで、複数台へ適用が可能になります。 構成ファイル作成はおそらくウィザードで生成、Parameter Store への格納を行うのが最も簡単かと思います。

  • cloudwatch-agent-config-wizard
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

中身はJsonファイルなので一度作成してしまえば使い回し可能かと思います。

f:id:htnosm:20171218034458p:plain

構成ファイルを基に設定を反映

ドキュメント AmazonCloudWatch-ManageAgent を使用します。

  • InstanceID での指定例
$ _DOCNAME="AmazonCloudWatch-ManageAgent"
$ _INSTANCEs="i-xxxxxxxxxxxx2c23b,i-xxxxxxxxxxxx8632f"
# Parameter Store を指定
$ _CONF="agent-config-linux"

$ aws ssm send-command \
  --document-name "${_DOCNAME}" \
  --targets "Key=instanceids,Values=${_INSTANCEs}" \
  --parameters "action=configure, mode=ec2, optionalConfigurationSource=ssm, optionalConfigurationLocation=${_CONF}, optionalRestart=yes"

導入結果

CloudWatch への転送

amazon-cloudwatch-agent は CloudWatch エンドポイントへ 443 で転送します。

  • 東京リージョン
monitoring.ap-northeast-1.amazonaws.com

カスタムメトリクス CWAgent として CloudWatch へ登録されます。

f:id:htnosm:20171218034459p:plain

metrics_collection_interval を最短の 1sec で指定しておけば、秒単位でメトリクスを確認できます。

f:id:htnosm:20171218034500p:plain

Linux、EC2、Advanced 指定で標準取得できるメトリクスは以下のような感じです。

f:id:htnosm:20171218034501p:plain

CloudWatch Logsへの転送

ログ転送(logs_collected)設定を行っていれば CloudWatch Logs に転送されます。

f:id:htnosm:20171218034502p:plain

CloudWatch Logs Agent (awslogs) とは別の設定になります。awslogsの方が細かな設定が可能なようです。

Datadog logs(パブリックベータ) を試してみる

Datadog でのログ管理機能(パブリックベータ版)が発表されました。

Datadog Agent もメジャーバージョンアップとなり、色々と変わるようなので正式リリース前に触れてみます。
ベータではありますが、現行環境へすんなり導入できるかという観点で試します。 (利用するには Datadog 側へ申請し、 Activate されていることが前提になります。)

f:id:htnosm:20171211003900p:plain



既存環境へのインストール

公式の導入手順は以下になります。

  • Log Collection
    • Agent version >= 6.0
    • デフォルトではログ収集は無効になっている

取得する対象ログ別の設定方法は [Logs]->[Docs]->[Server]-> で確認できます。

f:id:htnosm:20171211003901p:plain

Datadog Agent 現行5系の最新版 5.20.2 が導入済みの環境で nginx のログ取得を設定します。

環境

distribution Version Nginx
Amazon Linux 2017.09 1.12.1
CentOS 7.4.1708 1.12.2
CentOS 6.9 1.10.2
Ubuntu 16.04.3 LTS 1.10.3
Ubuntu 14.04.5 LTS 1.4.6

Agent Ver 6 へのアップグレード

まず Datadog Agent のバージョンを 6 へ上げる必要があります。

導入済みバージョンが 5.17 以上からのバージョンアップは One-step installTo Upgrade、それ以外のバージョンと新規インストールは To Install Fresh のコマンド実行が基本になると思います。

5系までは dd-agent 配下のインストールスクリプトだったのものが、 6では datadog-agent 配下となっています。 併せて導入後のディレクトリ名称等も datadog-agent に変わります。

Amazon Linux / CentOS6 / CentOS7

当方環境では手順通りでは正常に導入が行なえませんでした。 yumでのインストール時点で古いバージョンを参照してしまうようで、 One-step installManual install のいずれも失敗しました。

最終的に以下の手順で導入しています。通常だとyumのキャッシュクリアすれば解決しそうですが、rpmでも導入可能ということで残しておきます。

# rootで実行
# 5.20.2 アンインストール
# (設定ファイル格納場所 /etc/dd-agent は残る)
$ yum remove datadog-agent

・・・
Stopping Datadog Agent (using killproc on supervisord): [  OK  ]
  Erasing    : 1:datadog-agent-5.20.2-1.x86_64      1/1
  Verifying  : 1:datadog-agent-5.20.2-1.x86_64      1/1

Removed:
  datadog-agent.x86_64 1:5.20.2-1

Complete!

# rpm 指定でインストール
$ yum install "https://s3.amazonaws.com/yum.datadoghq.com/beta/x86_64/datadog-agent-6.0.0~beta.5-1.x86_64.rpm"

・・・
Running transaction
  Installing : 1:datadog-agent-6.0.0~beta.5-1.x86   1/1
Enabling service datadog-agent
No datadog.yaml file detected, not starting the agent
  Verifying  : 1:datadog-agent-6.0.0~beta.5-1.x86   1/1

Installed:
  datadog-agent.x86_64 1:6.0.0~beta.5-1

Complete!

# 導入後バージョン確認
$ datadog-agent version
Agent 6.0.0-beta.5 - Commit: 856c96d - Serialization version: 4.6

# 設定ファイルインポート
$ /opt/datadog-agent/bin/agent/agent import /etc/dd-agent /etc/datadog-agent
# checks.d のインポート(ファイルがある場合)
# $ sudo -u dd-agent -- cp /etc/dd-agent/checks.d/*.py /etc/datadog-agent/checks.d/

# アップグレードコマンド実行
# initスクリプトで正常起動ができないため再設定させる
$ DD_UPGRADE=true bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/datadog-agent/master/cmd/agent/install_script.sh)"

Ubuntu 14 / Ubuntu 16

To Upgrade のコマンドで問題ありませんでした。 インストール後の自動起動が失敗するようで、手動で起動する必要がありました。

# root で実行
$ DD_UPGRADE=true bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/datadog-agent/master/cmd/agent/install_script.sh)"
・・・
* DD_INSTALL_ONLY environment variable set: the newly installed version of the agent
will not be started. You will have to do it manually using the following
command:

     start datadog-agent

5.x -> 6.x での変更点

upstart 管理となったことで起動コマンド等が変更されています。
自動起動設定は /etc/init.d/ 配下ではなく、 /etc/init/datadog-agent.conf になります。

起動/停止/再起動

Amazon LinuxCentOS 6、Ubuntu 14 は以下のように変わります。 (Ubuntu 14 は service コマンドも利用可能です)

# <= 5.x.x
#service datadog-agent start
↓
# >= 6.0.0
initctl start datadog-agent

systemctl を使う CentOS 7、Ubuntu 16 は変わりません。

systemctl start datadog-agent

info (Agent 詳細情報出力)

info は廃止となったようで、datadog-agent の status で参照可能です。 その他の Datadog Agent の操作も全て datadog-agent コマンドを利用する形になるようです。

# <= 5.x.x
service datadog-agent info
↓
# >= 6.0.0
datadog-agent status

設定ファイル

datadog.conf、supervisor.conf は datadog.yaml へ集約されたようです。 また、conf.d/ 配下の .yaml が、 conf.d/.d/conf.yaml となっています。

# <= 5.x.x
/etc/dd-agent/conf.d/<integration>.yaml
↓
# >= 6.0.0
/etc/datadog-agent/conf.d/<integration>.d/conf.yaml

ログ収集有効化

設定ファイル修正

log_enabled に true を設定します。

# diff /etc/datadog-agent/datadog.yaml.org /etc/datadog-agent/datadog.yaml
< log_enabled: false
---
> log_enabled: true

nginx.yaml へ Log section を追記します。
尚、Start Logging with Datadog 上のサンプルをそのまま使おうとすると、/var/log/ 直下のログファイル指定となっているため動作しません。 (/var/log/nginx/ に修正する必要があります)

# diff /etc/dd-agent/conf.d/nginx.yaml /etc/datadog-agent/conf.d/nginx.d/conf.yaml
>
> #Log section
> logs:
>   - type: file
>     path: /var/log/nginx/access.log
>     service: nginx
>     source: nginx
>     sourcecategory: http_web_access
>
>   - type: file
>     path: /var/log/nginx/error.log
>     service: nginx
>     source: nginx
>     sourcecategory: http_web_access

新規ファイルで作成する場合

logs だけでは認識されず、init_config, instancesセクションも必須です。

init_config:

instances:
    [{}]

#Log section
logs:
  - type: file
    path: /var/log/nginx/access.log
    service: nginx
    source: nginx
    sourcecategory: http_web_access

対象ログの確認

  • 設定変更後は datadog-agent の再起動が必要
  • 起動後に書き込まれたログのみが対象
  • tcpポートは 10516 または 10514 (10516推奨)
  • datadog.yamllog_enabled: true (デフォルト無効)
  • dd-agent ユーザに対象ログファイルの読み込み権限が必要
# NG
$ sudo -u dd-agent ls /var/log/nginx/access.log
ls: cannot access /var/log/nginx/access.log: Permission denied
# 権限を付与して読み込みが可能なように修正
$ sudo -u dd-agent ls /var/log/nginx/access.log
/var/log/nginx/access.log

権限付与には3パターンの対処があります。

  • a) datadog-agent を root 権限で動かす(非推奨)
  • b) 対象ファイルに読み込み権限付与(ログローテーションにも注意)
  • c) rsyslog, fluentd 等を使用する

収集したログの参照

[Logs]->[Explorer]

f:id:htnosm:20171211003902p:plain

Screen Board に Log Stream を定義

f:id:htnosm:20171211003903p:plain

Infrastructure のホスト情報

本来はホストに紐付くログが表示されると思います。
今回導入した限りでは Infrastructure 側のホスト名が instance-id、Logs側のホスト名が ip-xxx-xxx-xxx-xxx となってしまい表示がされませんでした。 Aliasでも紐付くようにして欲しい所です。

f:id:htnosm:20171211003904p:plain


今回は導入のみで終わっていますが、Agent設定側での除外、マスク(置換)、複数行対応の機能もあります。
少量のログ送信しか試せておらず、ログ解析の検証もできていないのですが、 大量のホストから大量のログ情報が送信された場合、Explorer 画面が酷いことになりそうなのが懸念です。
Monitorにも対応してくれるのであろうと願いつつ、正式リリースを待ちたいと思います。

料金も気になる所ですが、現時点では価格未定とのことです。

collectd-cloudwatch を Amazon Linux 以外に導入してみる

導入対象EC2 が Amazon Linux の記事はよく見かけますが、他のディストリビューションでの情報があまりなかったため比較を行いました。



ディストリビューションと導入しやすさ

yum/apt での導入を前提としています。新しめのディストリビューションであれば特に苦労しません。

distribution Version python(Default) collectd 導入しやすさ
Amazon Linux 2017.09 2.7.12 5.7.1
CentOS 7.4.1708 2.7.5 5.7.1
CentOS 6.9 2.6.6 4.10.9 ×
Ubuntu 16.04.3 LTS 3.5.2 5.5.1
Ubuntu 14.04.5 LTS 2.7.6 5.4.0

Amazon Linux

提供元がAWSだけあって Amazon Linux は何も考えずに導入できます。

$ sudo yum install collectd collectd-python
$ curl -s -S -O "https://raw.githubusercontent.com/awslabs/collectd-cloudwatch/master/src/setup.py"
$ chmod u+x setup.py
$ sudo ./setup.py

CentOS

collectd は epel を利用しインストールします。

CentOS 7

README に記載がある collectd-python はパッケージが存在しなかったため未インストールです。

$ sudo yum install epel-release
$ sudo yum install collectd
$ curl -s -S -O "https://raw.githubusercontent.com/awslabs/collectd-cloudwatch/master/src/setup.py"
$ chmod u+x setup.py
$ sudo ./setup.py

CentOS 6

collectd 5.0.0 未満では collectd-cloudwatch は使用できません。

collectd は epel を利用してインストールしますが、4.10.9です。 また、 collectd-cloudwatch のインストールでエラーになります。

まず、python 2.6 では setup.py が動作しません。

$ python -V
Python 2.6.6
$ sudo ./setup.py
Traceback (most recent call last):
  File "./setup.py", line 28, in <module>
    from subprocess import check_output, CalledProcessError, Popen, PIPE
ImportError: cannot import name check_output

python 2.7 にしても setup.py は別のエラーとなります。

$ python -V
Python 2.7.14
$ sudo ./setup.py
Traceback (most recent call last):
  File "./setup.py", line 964, in <module>
    main()
  File "./setup.py", line 957, in main
    install_plugin()
  File "./setup.py", line 869, in install_plugin
    install_packages(SYSTEM_DEPENDENCIES)
  File "./setup.py", line 261, in install_packages
    command = DISTRIBUTION_TO_INSTALLER[detect_linux_distribution()] + " ".join(packages)
  File "./setup.py", line 270, in detect_linux_distribution
    return DISTRO_NAME_REGEX.search(search_string).group(1).strip()
AttributeError: 'NoneType' object has no attribute 'group'

ディストリビューションの判断を /etc/os-release で行っているので、無理矢理通してみるとようやく未サポートのメッセージ表示となりました。

$ sudo ./setup.py
Installing dependencies ... OK
Installing python dependencies ... OK
Downloading plugin ... OK
Extracting plugin ... OK
Moving to collectd plugins directory ... OK
The minimum supported version of collectd is 5.0.0, and your version is 4.10.9. You need to upgrade collectd before proceeding with the plugin installation.

Ubuntu

collectd の設定ファイル格納場所が Redhat系(Amazon Linux含む) とは異なります。

Ubuntu16

python 2.7 を使えるようにしておく必要があります。

$ python -V
Python 2.7.14
$ sudo apt-get install collectd
$ curl -s -S -O "https://raw.githubusercontent.com/awslabs/collectd-cloudwatch/master/src/setup.py"
$ chmod u+x setup.py
$ sudo ./setup.py

Ubuntu14

インストール自体は他と同様です。

$ sudo apt-get install collectd
$ curl -s -S -O "https://raw.githubusercontent.com/awslabs/collectd-cloudwatch/master/src/setup.py"
$ chmod u+x setup.py
$ sudo ./setup.py

ディストリビューションと異なり、collectd が5.4のため、インストール時にデフォルトで設定されているメトリクスが使用できません。
公式ブログにもありますが、disk 以外の cpu/memory/swap は、 5.5 からパーセンテージが利用できるようになっています。

バージョン 5.5 以降の collectd を使用している場合は、4 つのメトリックスがデフォルトで発行されるようなりました。

デフォルト設定での導入結果

f:id:htnosm:20171106033047p:plain

その他

CloudWatch の Endpoint(monitoring.{{region}}.amazonaws.com) へ送信しているため、Outbound制限を掛けている場合は 443 ポートの許可が必要です。

Backlog Git README.md で画像表示

Backlog の GitMarkdown 内の画像を表示したいという要件があったので調べました。
Backlog上(ブラウザ)で画像を表示 したい場合です。(Markdownエディタ等での表示は考慮していません)

現時点ではリポジトリ内ファイル参照はサポートしていないようです。 Wikiを使いましょういうことなのでしょうが、Gitでドキュメント管理する場合等に使えるかもしれない小ネタです。



GitHub での構文

Images
![GitHub Logo](/images/logo.png)
Format: ![Alt Text](url)

Backlog Git 上の .md での画像表示

Backlog上(ブラウザ)で画像ファイル自体が表示できるので、そのURLを指定すれば可能です。

# raw
![代替文字列](https://{{ Backlog Space }}.backlog.jp/git/{{ Backlog Project }}/{{ Git Repository }}/raw/{{ branch }}/{{ Path }}/{{ File }})

# preview
![代替文字列](https://preview-{{ Backlog Space }}.backlog.jp/git/{{ Backlog Project }}/{{ Git Repository }}.git/{{ branch }}/{{ Path }}/{{ File }})

尚、HTML直書きは未対応でした。

practice
├── TEST1.md
├── TEST2.md
└── img
    └── logo.png
  • Backlogスペース名: hoge
  • Backlogプロジェクト名: PCT
  • Gitリポジトリ名: practice
  • Gitブランチ: master
## Raw

- Markdown

![raw md](https://hoge.backlog.jp/git/PCT/practice/raw/master/img/logo.png)

- HTML

<img src="https://hoge.backlog.jp/git/PCT/practice/raw/master/img/logo.png" alt="raw html" title="raw html">

## Preview

- Markdown

![preview md](https://preview-hoge.backlog.jp/git/PCT/practice.git/master/img/logo.png)

- HTML

<img src="https://preview-hoge.backlog.jp/git/PCT/practice.git/master/img/logo.png" alt="preview html" title="preview html">

f:id:htnosm:20171005134852p:plain

リポジトリ内ファイル参照(未サポート)例

相対パスでの指定だと表示されません。

- Markdown

![md](img/logo.png)

- HTML

<img src="img/logo.png" alt="html" title="html">

f:id:htnosm:20171005134851p:plain


DatadogAgent を Windows10(日本語環境) へインストール

今更ながら、初めて Windows へ DatadogAgent をインストールしました。
Linux との違いを中心にメモ。

基本的には公式ドキュメント一読でほぼ事足ります。

目次

インストール

環境

Agent version
    5.17.2
Platform
    Windows-10-10.0.15063
Python version
    2.7.12, 64bit

以下デフォルトインストールです。

f:id:htnosm:20170923014827p:plain

起動/停止

Datadog Agent Manager

GUIで各種操作を行えるツールです。

  • Setting・・・Datadog.conf、各種インテグレーションファイルの編集
  • Log and Status・・・Agent Status、各種ログの参照
  • Actions・・・Agent起動・停止、サポートケース起票(Flare)

f:id:htnosm:20170923014828p:plain f:id:htnosm:20170923014829p:plain

各種インテグレーションファイルの編集は、[Save] しただけでは有効化されないため、[Enable] を押下して有効化する必要があります。

Service

Windowsサービスからも起動/停止が可能です。

f:id:htnosm:20170923014830p:plain

各種ディレクト

インストールディレクト

C:\PROGRAM FILES\DATADOG\DATADOG AGENT
├─agent
├─bin
├─dist
├─embedded
└─LICENSES

設定ファイル・ログ

Datadog Agent Manager を使用せずに直接参照・編集も可能です。
因みに、Datadog Agent Manager の [Enable/Disable] は conf.d 配下の 〜.yaml をリネームしています。

C:\PROGRAMDATA\DATADOG
│  datadog.conf    # Datadog Agent の設定ファイル
├─checks.d         # カスタムチェックファイル
├─conf.d           # Integrations の設定ファイル
└─logs             # 各種ログファイル
        collector.log
        dogstatsd.log
        forwarder.log
        service.log

Event Viewer Integration

WindowsイベントログをDatadogへ連携するインテグレーションが用意されています。

type でエラーレベルでの絞り込みができるようになっていますが、 マルチバイト(というかマルチロケーション)非対応で、 日本語環境では動作しません。 以下のように元のインテグレーションファイルを編集して、カスタムチェックを作成して回避しました。

  • win32_event_log_ja(差分)
--- win32_event_log.py
+++ win32_event_log_ja.py
@@ -1,3 +1,12 @@
+#!/usr/bin/python
+# -*- coding: cp932 -*-
+'''
+日本語環境用イベントログ監視
+'''
+import sys
+reload(sys)
+sys.setdefaultencoding('cp932')
+
 # (C) Datadog, Inc. 2010-2016
 # All rights reserved
 # Licensed under Simplified BSD License (see LICENSE)
@@ -87,6 +96,19 @@
         if ltypes:
             query['Type'] = []
             for ltype in ltypes:
+                if ltype == 'Critical':
+                    ltype = '重大'
+                elif ltype == 'Error':
+                    ltype = 'エラー'
+                elif ltype == 'Warning':
+                    ltype = '警告'
+                elif ltype == 'Information':
+                    ltype = '情報'
+                elif ltype == 'Audit Success':
+                    ltype = '成功の監査'
+                elif ltype == 'Audit Failure':
+                    ltype = '失敗の監査'
+
                 query['Type'].append(('=', ltype))
         if source_names:
             query['SourceName'] = []
@@ -223,9 +245,11 @@
     def _alert_type(self):
         event_type = self.event['Type']
         # Convert to a Datadog alert type
-        if event_type == 'Warning':
+        if event_type == '警告':
             return 'warning'
-        elif event_type == 'Error':
+        elif event_type == '重大':
+            return 'error'
+        elif event_type == 'エラー':
             return 'error'
         return 'info'

win32_event_log_ja.py を checks.d、win32_event_log_ja.yaml(中身はwin32_event_log.yamlと同じ) を conf.d に格納して使用します。

f:id:htnosm:20170923014831p:plain

WindowsでのカスタムCheckのテスト

日本語ドキュメントには shell.exe を使用するように記載がありますが、agent version 5.12 以上の場合の確認方法は下記になります。 (現時点で日本語ドキュメントには旧バージョンの確認方法しか記載がありません。)

<INSTALL_DIR>/embedded/python.exe <INSTALL_DIR>agent/agent.py check <CHECK_NAME>

今回インテグレーションは Event Viewer のみ導入しましたが、他にもロケール問題が出る物があるのかもしれません。 (イベントログのエラーレベル位、Windows側が英語で出力すれば良いのではと思いますが)
Datadog公式でマルチロケール対応が成されることを期待します。

Datadog EC2インスタンスIDの取得

Datadog Agent でのホスト名はルールに従って決定されます。

host名を固定化している場合、datadog.conf 内で明示的に hostname: を指定している場合等には、 指定値が優先されます。
監視対象 AWS EC2インスタンスの instance-id を取得したいと思ったのですが、上記設定が入っていたため tag では保持していませんでした。

ドキュメントの Host Aliases にある通り、 Host としては hostname: の設定値となり、 Alias として instance-id を持っている状態です。



Alias

Datadog Agent の info 情報で取得できる Hostnames を保持しているようです。
Infrastructure List 画面で確認できます。

  Hostnames
  =========

    ec2-hostname: ip-XXX-XX-XX-XXX.ap-northeast-1.compute.internal
    local-ipv4: XXX-XX-XX-XXX
    hostname: XX01
    socket-hostname: XX01
    local-hostname: ip-XXX-XX-XX-XXX.ap-northeast-1.compute.internal
    instance-id: i-XXXXX77e
    public-ipv4: XX.XX.XXX.XX
    socket-fqdn: localhost.localdomain

f:id:htnosm:20170919023321p:plain

JSON API permalink

Infrastructure 画面以外で Alias を取得する方法として JSON API permalink が用意されています。 画面下部からリンクURLを取得できます。
内容は Infrastructure 画面で参照できる値をJSON形式で取得できます。

f:id:htnosm:20170919023322p:plain

尚、現時点で公式ドキュメントの記載は見つけられませんでしたので、仕様変更が入るかもしれません。 Knowledge Base に少しだけ記載があります。

インスタンスIDの取得

他のAPI同様に利用できるようなので curl コマンドでの取得を試します。 API Key、Application Key が必要になります。

EC2インスタンスの値としては以下のようになっていました。 aws_id で目的のインスタンスIDを取得できます。

  • host_name : Datadog上のHostname
  • aws_name : AWS上のEC2タグ
  • aws_id : AWS EC2 Instance ID
$ apikey=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
$ appkey=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
$ hostname=XX01
$ curl -s -S "https://app.datadoghq.com/reports/v2/overview?api_key=${apikey}&application_key=${appkey}" \
  | jq '.rows[] | select(.host_name == "'${hostname}'") | { host_name:.host_name, aws_name:.aws_name, aws_id:.aws_id }'
{
  "host_name": "XX01",
  "aws_name": "XXXXXXXXX-XX01",
  "aws_id": "i-XXXXX77e"
}

因みに取得できる基本項目は以下です。オプション付与で他にも色々取得できるようです。 infrastructure で表示している項目は全て保持していると思われます。

{
  "rows": [
    {
      "display_name": "i-XXXXXXXXXXXXXXXXX",
      "name": "i-XXXXXXXXXXXXXXXXX",
      "tags_by_source": {
        "Amazon Web Services": [
          "availability-zone:ap-northeast-1a",
          "iam_profile:xxxxx",
          "image:ami-XXXXX2f5",
          "instance-type:t2.micro",
          "kernel:none",
          "name:XXXXX",
          "region:ap-northeast-1",
          "security-group:sg-XXXXXXXX"
        ]
      },
      "up": true,
      "aws_name": "XXXXX",
      "host_name": "i-XXXXXXXXXXXXXXXXX",
      "has_metrics": false,
      "aws_id": "i-XXXXXXXXXXXXXXXXX",
      "id": XXXXXXXXX,
      "last_seen": 1503457664
    },
・・・