AWS CloudWatchにカスタムメトリックスを登録する

aws_logo

ゴール

AWS のサービス(特に EC2)を監視するには

  • aws マネージドサービスにデフォルトでついてくる CloudWatch を利用(aws おまかせ)
  • カスタムメトリックスを CloudWatch に送信し、CloudWatch を利用(エージェントだけ自前実装)
  • new relic のような ASP サービスを利用(エージェントだけ自前インストール)
  • Zabbix などの監視システムを構築(サーバ、クライアントの両方を自分で面倒を見る)

といった方法がある。

今回は2つ目の方法をメモ。

監視内容

EC2 インスタンス(OS は amazon Linux)からカスタムメトリックスを CloudWatch に送信する。
実験に使いやすいインスタンスに nginx がインストールされていたので nginx のメトリックスを送ることにする。

nginx のメトリックスを取得

ngx_http_stub_status_module モジュールを利用してメトリックスを取得する。
amazon Linux から yum でインストールする nginx でも利用可能。

$ nginx -V の出力結果に --with-http_stub_status_module があるのを確認できる。

$ nginx -V
nginx version: nginx/1.4.7
built by gcc 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
TLS SNI support enabled
configure arguments: : --prefix=/usr/share/nginx ... --with-http_stub_status_module ...

server または location コンテキストにこのモジュールの設定を追加する

location /basic_status {
    stub_status on;
}

設定ファイルのシンタックスを確認

# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

設定ファイルを再読み込みする

# service nginx reload
Reloading nginx:                                           [  OK  ]

メトリックスを確認

$ curl http://localhost/basic_status
Active connections: 1
server accepts handled requests
 254 254 3190
Reading: 0 Writing: 1 Waiting: 0

クライアントの累計処理数や処理待ちのコネクション数などが取得可能。

加工しやすいようにレスポンスは CSV で返したい。

ngx_http_stub_status_module モジュールには組み込み変数が用意されているので活用させてもらう。
さらに、ローカルホストからのみアクセスを受け付けるようにする。

location /basic_status {
  stub_status on;
  allow 127.0.0.1;
  deny all;
  return 200 "$connections_active,$connections_reading,$connections_writing,$connections_waiting";
}

ここでは左から順にアクティブ/リクエスト処理中/レスポンス処理中/待ちなコネクション数を返している。

nginx の設定ファイルを再読み込みする

# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# service nginx reload
Reloading nginx:

メトリックスを確認

$ curl http://localhost/basic_status
1,0,1,0

CSV でかえってきている。

CloudWatch にカスタムメトリックスを送信

検証を優先し実装をサボるために AWS CLI からメトリックスを送信することにする。
重要なことは次のドキュメントに書かれている

Scenario: Publish Metrics to CloudWatch – Amazon CloudWatch
http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/PublishMetrics.html

最終的には cloudwatch put-metric-data を使って

$ aws cloudwatch put-metric-data --metric-name RequestLatency --namespace GetStarted --timestamp 2014-02-14T20:30:00Z --value 87 --unit Milliseconds

というようにしてメトリックスを送信する。

  • --timestamp を省略すると CloudWatch がデータ取得したタイムスタンプが初期値となる。フォーマットは AWS 流儀に習う。
  • --namespace は nginx にして --metric-name に各メトリックスを突っ込む。
  • nginx のメトリックスの性質上、--unitCount となる。

以上をまとめて

$ aws cloudwatch put-metric-data --namespace nginx --metric-name connections_active --timestamp 2014-02-14T20:30:00Z --value 87 --unit Count

とすれば良さそうなのだけれども、サーバ情報が含まれていないという大きな問題がある。

cloudwatch put-metric-data の AWS CLI のマニュアルを読んでも、サーバ情報を送信するオプションはない
どうすればよいかというと、メトリックスのフィルターなどで利用する dimension を活用する。

cloudwatch のマニュアルにも “Dimensions for Amazon EC2 Metrics” というセクションがあって、各インスタンスのメトリックスは以下の dimension でフィルターできるようになっていることがわかる。

  • AutoScalingGroupName
  • ImageId
  • InstanceId
  • InstanceType

この本家の流儀に習い InstanceIddimension で送信する。
InstanceIdAWS のメタデータAPI から取得できる

$ curl http://169.254.169.254/latest/meta-data/instance-id
i-01234567

最終的に

$ aws cloudwatch put-metric-data --dimensions InstanceId=$INSTANCEID --timestamp $TIMESTAMP --namespace nginx --metric-name connections_active --value $VALUE --unit Count

というように送信すればよい。

shell スクリプトにまとめる

#!/bin/sh
# publish nginx metrics to CloudWatch

# retrieve ec2 intance id
INSTANCEID=`curl http://169.254.169.254/latest/meta-data/instance-id`
echo $INSTANCEID;
TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%S.000Z)
echo $TIMESTAMP

# nginx metrics
NGINX_STATUS=`curl http://localhost/basic_status`
echo $NGINX_STATUS;

# csv to array
IFS=,
set $NGINX_STATUS
unset IFS

# publish metrics to CloudWatch
aws cloudwatch put-metric-data --dimensions InstanceId=$INSTANCEID --timestamp $TIMESTAMP --namespace nginx --metric-name connections_active  --value $1 --unit Count
aws cloudwatch put-metric-data --dimensions InstanceId=$INSTANCEID --timestamp $TIMESTAMP --namespace nginx --metric-name connections_reading --value $2 --unit Count
aws cloudwatch put-metric-data --dimensions InstanceId=$INSTANCEID --timestamp $TIMESTAMP --namespace nginx --metric-name connections_writing --value $3 --unit Count
aws cloudwatch put-metric-data --dimensions InstanceId=$INSTANCEID --timestamp $TIMESTAMP --namespace nginx --metric-name connections_waiting --value $4 --unit Count

CloudWatch でデータを確認

Management Console で CloudWatch の画面に行き、サイドメニューの “Custom Metrics…” から nginx を選択。

1 週間分のconnections_active メトリックスのカウントをグラフ化したのが次のグラフ(検証環境なのでアクセスはしょぼい)

その他

namespaceについて

一つの aws アカウントで複数プロジェクトを運用することも多いと思うので namespaceprojectname/nginx のように運用する単位でプリフィックスを切るとよい。

JSON 形式で送信

metric-data は JSON で一括送信しても OK。

$ aws cloudwatch put-metric-data --namespace "nginx" --metric-data '
[
  {
    "MetricName": "connections_active",
    "Value": 1,
    "Unit": "Count"
  },
  {
    "MetricName": "connections_waiting",
    "Value": 1,
    "Unit": "Count",
    "Dimensions": [
      {
        "Name": "InstanceId",
        "Value": "YOUR-INSTANCE-ID"
      }
    ]
  }
]
'

カスタムメトリックスを削除

カスタムメトリックスを明示的に削除する手段は、マネージメントコンソールにも API にも存在しない。
2週間待って、CloudWatch から自然消滅するのを待て、ということらしい。
via http://stackoverflow.com/questions/23229268/how-do-you-delete-an-aws-cloudwatch-metric

Advertisements
Tagged with: , , , ,
Posted in aws

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Archives
  • RT @__apf__: How to write a research paper: a guide for software engineers & practitioners. docs.google.com/presentation/d… /cc @inwyrd 4 months ago
  • RT @HayatoChiba: 昔、自然と対話しながら数学に打ち込んだら何かを悟れるのではと思いたち、専門書1つだけ持ってパワースポットで名高い奈良の山奥に1週間籠ったことがある。しかし泊まった民宿にドカベンが全巻揃っていたため、水島新司と対話しただけで1週間過ぎた。 それ… 5 months ago
  • RT @googlecloud: Ever wonder what underwater fiber optic internet cables look like? Look no further than this deep dive w/ @NatAndLo: https… 5 months ago
  • @ijin UTC+01:00 な時間帯で生活しています、、、 10 months ago
  • RT @mattcutts: Google's world-class Site Reliability Engineering team wrote a new book: amazon.com/Site-Reliabili… It's about managing produc… 1 year ago
%d bloggers like this: