vague memory

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

AWS Athena 別リージョンS3でのエラー

QuickSight を使おうとした際に当たったエラーです。 QuickSight は現在東京リージョンでの提供が無いため、オレゴンリージョンから東京リージョンのS3を参照しました。

Athenaでのクエリ実行時に以下エラーメッセージが出力されます。(同一リージョンであれば問題無いです)

HIVE_CURSOR_ERROR: The bucket is in this region: null. 
Please use this region to retry the request
(Service: Amazon S3; Status Code: 301; Error Code: PermanentRedirect;

f:id:htnosm:20180301073027p:plain

暗号化されている場合は、S3とAthenaは同一リージョンにする必要があります。

If the data is encrypted in Amazon S3, it must be stored in the same region, and the user or principal who creates the table in Athena must have the appropriate permissions to decrypt the data.

仕様です。
が、エラーメッセージが解り難いと感じました。

Neustar Website Load Testing のサンプルスクリプト(VirtualUser)生成

Neustar Website Load Testing

米国の Neustar 社が提供しているサービスの一つで、Webサイトに対する負荷試験が行えます。 日本ではあまり馴染みが無いようで情報が少ないです。

有償サービスです。30日間のトライアルがあります。コーポレートサイトからは以下のようにリンクを辿ると行き着きます。

有償サービスだけあって至れり尽くせりな感じなので、ある程度大きな規模、複雑なシナリオの負荷試験を行う場合は選択肢の一つになると思います。

  • 負荷試験スケジュール設定が容易
  • 実行ロケーションが豊富
  • 試験結果レポート自動生成
    • 結果データをMySQL形式でダウンロード可能

test script

負荷試験実行には実行するスクリプトを作成する必要があります。

以前は neustar_script_recorder により Selenium IDE からスクリプト生成ができましたが、 Firefox 55 からは Selenium IDE が動作しなくなっています。

f:id:htnosm:20180205031417p:plain

neustar の Scripting ページにあったリンクも既に消えています。

f:id:htnosm:20180205031418p:plain

スクリプトの公式ドキュメントは以下になりますが、一から作成するのは中々骨が折れます。

biz.neustar.wpm.api (Neustar Web Performance Management Scripting API)

VirtualUser

GETやPOSTコマンドを使用してHTTPトラフィックをシミュレートします。 対して RealUser は実際のブラウザを使用したテストを行えます。が、VirtualUserより割高です。

サンプルスクリプト生成

本題です。
負荷試験用のスクリプトを作成するに当たり、ベースとなるサンプルスクリプトを生成します。
Neustar のアカウント登録は済ませている必要があります。

  • Scripting Overview ページから [CREATE SAMPLE SCRIPT]

f:id:htnosm:20180205031419p:plain

  • 対象URLを入力

f:id:htnosm:20180205031420p:plain

Google先生にご協力いただいています。

f:id:htnosm:20180205031421p:plain

この時点では RealUser 用のスクリプトです。 以下のようなスクリプトとなります(コメント行を除外したもの)。 openBrowser を基点としています。

var driver = openBrowser();
var c = driver.getHttpClient();
c.blacklistCommonUrls();
beginTransaction(function() {
    beginStep("Check Website", 30000, function() {
        driver.get("https://google.com");
        waitForNetworkTrafficToStop(2000, 15000);
    });
});
  • ページ下部にある [GENERATE BASIC SCRIPT] で VirtualUser 用に変換

f:id:htnosm:20180205031422p:plain

そのまま押下すると名前重複エラーとなるため、Name: に任意の名前を入力後、 [GENERATE BASIC SCRIPT] を押下します。

f:id:htnosm:20180205031423p:plain

変換されたものが別スクリプトとして作成されます。

以下のようなスクリプトとなります(一部抜粋)。 openHttpClient を基点としています。

var c = test.openHttpClient();
c.setFollowRedirects(false);
test.beginTransaction();
test.beginStep("Check Website");
c.get("https://google.com/", 301);
c.get("https://www.google.com/", 200);
c.get("https://www.google.com/logos/doodles/2018/elizabeth-blackwells-197th-birthday-5658618786480128.3-s.png", 200);
c.get("https://www.google.com/logos/doodles/2018/elizabeth-blackwells-197th-birthday-5658618786480128-l.png", 200);
c.get("https://ssl.gstatic.com/gb/images/i1_1967ca6a.png", 200);
c.get("https://www.google.com/xjs/_/js/k=xjs.s.en_US.raf7LOu-P_4.O/m=sx,sb,cdos,cr,elog,hsm,jsa,r,d,csi/am=wCLkeMEBEP8TgogEKwgsSAphGBA/rt=j/d=1/t=zcms/rs=ACT90oE6NwsHXuZlmER-n1nX33KRrVCWFQ", 200);
var req = c.newPost("https://www.google.com/gen_204?s=webaft&atyp=csi&ei=3mx2WrTeFOrA5gLhtIjABQ&rt=wsrt.574,aft.263,prt.118");
req.setRequestBody("", "text/plain", "UTF-8");
req.execute();
c.get("https://www.google.com/textinputassistant/tia.png", 200);
c.get("https://www.google.com/xjs/_/js/k=xjs.s.en_US.raf7LOu-P_4.O/m=d3l,aa,abd,async,dvl,foot,fpe,ifl,ipv6,lu,m,mu,sf,sonic/am=wCLkeMEBEP8TgogEKwgsSAphGBA/exm=sx,sb,cdos,cr,elog,hsm,jsa,r,d,csi/rt=j/d=1/ed=1/t=zcms/rs=ACT90oE6NwsHXuZlmER-n1nX33KRrVCWFQ?xjs=s1", 200);
c.get("https://www.gstatic.com/og/_/js/k=og.og2.en_US.1KX-mFknZ_0.O/rt=j/m=def/exm=in,fot/d=1/ed=1/rs=AA2YrTuYBNXI2WfsWOZ7BwnBUE80MWT3Og", 200);
c.get("https://apis.google.com/_/scs/abc-static/_/js/k=gapi.gapi.en.HtLvrA_npCQ.O/m=gapi_iframes,googleapis_client,plusone/rt=j/sv=1/d=1/ed=1/am=AAE/rs=AHpOoo8wHQU_A1WtgGgcOpQEfGjHuD8e-g/cb=gapi.loaded_0", 200);
c.get("https://www.google.com/images/nav_logo242.png", 200);
var req = c.newPost("https://www.google.com/gen_204?atyp=csi&ei=3mx2WrTeFOrA5gLhtIjABQ&s=webhp&imc=3&imn=3&imp=3&adh=&ima=2&ime=0&rt=aft.263,dcl.211,iml.263,ol.796,prt.118,xjs.529,xjsee.529,xjses.331,xjsls.176,wsrt.574,cst.0,dnst.0,rqst.266,rspt.302,rqstt.286,unt.249,cstt.249,dit.717&zx=1517710556974");
req.setRequestBody("", "null", "UTF-8");
req.execute();
c.get("https://adservice.google.com/adsid/google/ui", 204);
var req = c.newPost("https://shavar.services.mozilla.com/downloads?client=navclient-auto-ffox&appver=45.9.0&pver=2.2");
req.setRequestBody("mozstd-track-digest256;
mozstd-trackwhite-digest256;
", "text/plain", "UTF-8");
req.execute();
c.get("https://tracking-protection.cdn.mozilla.net/mozstd-track-digest256/1512580265", 200);
c.get("https://tracking-protection.cdn.mozilla.net/mozstd-trackwhite-digest256/1512580265", 200);
test.endStep();
test.endTransaction();

Validation Status: Invalid となっている通り、そのままだと実行できません。 残念ながら変換処理は完全な物では無いようです。

  • [View Validation Results] からエラー参照

f:id:htnosm:20180205031424p:plain

エラー内容に従いスクリプトを修正して、Validationを通します。

$ diff check.google.com.basic.js.org check.google.com.basic.js
37,38c37,38
< c.get("https://google.com/", 301);
< c.get("https://www.google.com/", 200);
---
> c.get("https://google.com/", 302);
> c.get("https://www.google.com/", 302);
56,58c56
< req.setRequestBody("mozstd-track-digest256;
< mozstd-trackwhite-digest256;
< ", "text/plain", "UTF-8");
---
> req.setRequestBody("mozstd-track-digest256; mozstd-trackwhite-digest256; ", "text/plain", "UTF-8");
  • [REVALIDATE]

f:id:htnosm:20180205031425p:plain

正常に実行できると実行結果を参照できます。

f:id:htnosm:20180205031426p:plain

Local Validator

VALIDATE をローカルで実行するツールが用意されています。

f:id:htnosm:20180205031427p:plain

ローカルで VALIDATE を通した後、Neustar上で VALIDATE を通すのが基本になるかと思います。 NeustarのWEB画面はお世辞にも軽いとは言えないので、何度も実行する事を考えると辛いです。

  • 実行例
# ダウンロードした local-validator.tar.gz を解凍後
# ./bin/validator "ScriptFile"

$ ./bin/validator check.google.com.basic.js
Neustar Web Performance Script Validator 4.27.33
Copyright (c) Neustar Inc - All Rights Reserved.
VNC Support is NOT Available
INFO 02/04 17:49:59 b.n.w.a.s.JavaScrip~ - LITE mode starting up
INFO 02/04 17:49:59 b.n.w.a.s.JavaScrip~ - Starting script executor 0
INFO 02/04 17:49:59 b.n.w.a.a.Webmetric~ - Using DNS Server: [10.0.2.4, 10.0.130.4]
INFO 02/04 17:50:04 b.n.w.a.s.JavaScrip~ - Script complete.
INFO 02/04 17:50:04 b.n.w.v.ValidationR~ - Saving validation logs to 'validation.txt'...
INFO 02/04 17:50:04 b.n.w.v.ValidationR~ - Saving Http Archive(HAR) to 'har.js'...

# 結果確認
$ cat validation.txt
***** TEST PASSED *****
=====================================================
Script Log
=====================================================
Tip: Calls to test.log('text') will log the supplied text to this field - great for debugging!

=====================================================
Transaction information
=====================================================
Start: Mon Feb 04 17:21:13 JST 2018
End: Mon Feb 04 17:21:20 JST 2018
Time Active: 6917ms
Time Paused: 0ms
Bytes Transfered: 1195973
Total Steps: 1


=====================================================
Check Website, 1
=====================================================
Start: Mon Feb 04 17:21:13 JST 2018
End: Mon Feb 04 17:21:20 JST 2018
Time Active: 6909ms
Time Paused: 0ms
Bytes Transferred: 1195973
Total Objects: 17

    272b    302 467ms   https://google.com/
    272b    302 505ms   https://www.google.com/
    4480b   200 143ms   https://www.google.com/logos/doodles/2018/elizabeth-blackwells-197th-birthday-5658618786480128.3-s.png
    42566b  200 280ms   https://www.google.com/logos/doodles/2018/elizabeth-blackwells-197th-birthday-5658618786480128-l.png
    7325b   200 147ms   https://ssl.gstatic.com/gb/images/i1_1967ca6a.png
    424795b 200 721ms   https://www.google.com/xjs/_/js/k=xjs.s.en_US.raf7LOu-P_4.O/m=sx,sb,cdos,cr,elog,hsm,jsa,r,d,csi/am=wCLkeMEBEP8TgogEKwgsSAphGBA/rt=j/d=1/t=zcms/rs=ACT90oE6NwsHXuZlmER-n1nX33KRrVCWFQ
    0b  204 164ms   https://www.google.com/gen_204?s=webaft&atyp=csi&ei=3mx2WrTeFOrA5gLhtIjABQ&rt=wsrt.574,aft.263,prt.118
    258b    200 129ms   https://www.google.com/textinputassistant/tia.png
    74553b  200 198ms   https://www.google.com/xjs/_/js/k=xjs.s.en_US.raf7LOu-P_4.O/m=d3l,aa,abd,async,dvl,foot,fpe,ifl,ipv6,lu,m,mu,sf,sonic/am=wCLkeMEBEP8TgogEKwgsSAphGBA/exm=sx,sb,cdos,cr,elog,hsm,jsa,r,d,csi/rt=j/d=1/ed=1/t=zcms/rs=ACT90oE6NwsHXuZlmER-n1nX33KRrVCWFQ?xjs=s1
    138813b 200 629ms   https://www.gstatic.com/og/_/js/k=og.og2.en_US.1KX-mFknZ_0.O/rt=j/m=def/exm=in,fot/d=1/ed=1/rs=AA2YrTuYBNXI2WfsWOZ7BwnBUE80MWT3Og
    138670b 200 1034ms  https://apis.google.com/_/scs/abc-static/_/js/k=gapi.gapi.en.HtLvrA_npCQ.O/m=gapi_iframes,googleapis_client,plusone/rt=j/sv=1/d=1/ed=1/am=AAE/rs=AHpOoo8wHQU_A1WtgGgcOpQEfGjHuD8e-g/cb=gapi.loaded_0
    16786b  200 198ms   https://www.google.com/images/nav_logo242.png
    0b  204 299ms   https://www.google.com/gen_204?atyp=csi&ei=3mx2WrTeFOrA5gLhtIjABQ&s=webhp&imc=3&imn=3&imp=3&adh=&ima=2&ime=0&rt=aft.263,dcl.211,iml.263,ol.796,prt.118,xjs.529,xjsee.529,xjses.331,xjsls.176,wsrt.574,cst.0,dnst.0,rqst.266,rspt.302,rqstt.286,unt.249,cstt.249,dit.717&zx=1517710556974
    0b  204 514ms   https://adservice.google.com/adsid/google/ui
    162b    400 578ms   https://shavar.services.mozilla.com/downloads?client=navclient-auto-ffox&appver=45.9.0&pver=2.2
    57526b  200 411ms   https://tracking-protection.cdn.mozilla.net/mozstd-track-digest256/1512580265
    289495b 200 405ms   https://tracking-protection.cdn.mozilla.net/mozstd-trackwhite-digest256/1512580265

WPM API

Neustar のWeb画面での各種操作(スクリプトやテスト実行)のAPIもあります。

まとめ

Neustar自体は負荷試験を欠ける側に気を使わなくて良いのは利点ですが、想定通りのテスト実行までの道のりは結構長く感じます。
実際の負荷試験シナリオはもっと複雑になるので、出力された物そのまま利用するだけでは不十分ですが、 取っ掛かりとしてサンプルスクリプト生成を行い修正していくのが楽なのかなと思います。

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