#collectd

20+ Top Server Management and Monitoring Tools

Enterprises run multiple servers to deliver business critical services for their end users. Some of them include database servers, core app servers, caching servers, web servers, and more. Performance of each of these servers are critical because even if one of the servers fail, then it impacts the delivery of business critical services.

Therefore it is imperative to know any performance issues…

こんにちは、インフラストラクチャー部の沼沢です。

今回は collectd を使って php の OPcache の情報を CloudWatch に連携する具体例をご紹介したいと思います。

関連記事: nginx の各種情報を collectd を使って CloudWatch に連携する php-fpm のステータス情報を collectd を使って CloudWatch に連携する

前提

Amazon Linux AMI release 2016.09

collectd 5.4.1

php 関連 5.6.28

nginx 1.10.1

jq 1.5

なお、collectd については以下と同等の状態ができあがっているという前提で進めます。 新しい collectd の CloudWatch プラグイン | Amazon Web Services ブログ collectdのCloudWatchプラグインを試してみた ｜ Developers.IO

opcache_get_status の値を CloudWatch に連携

opcache_get_status とは、OPcache のキャッシュヒット率などのステータス情報を取得するための関数です。 詳細は PHP: opcache_get_status - Manual をご確認ください。

ローカルから curl http://localhost/opcache.php を実行できるようにするため、DocumentRoot 直下に以下の内容の opcache.php を配置します。

<?=json_encode(opcache_get_status(false)) ?>

curl http://localhost/opcache.php を実行すると以下のような json が返ってくる状態になっているとします。

$ curl -s http://localhost/opcache.php | jq { "opcache_enabled": true, "cache_full": false, "restart_pending": false, "restart_in_progress": false, "memory_usage": { "used_memory": 10936200, "free_memory": 123281528, "wasted_memory": 0, "current_wasted_percentage": 0 }, "interned_strings_usage": { "buffer_size": 8388608, "used_memory": 438304, "free_memory": 7950304, "number_of_strings": 4822 }, "opcache_statistics": { "num_cached_scripts": 1, "num_cached_keys": 1, "max_cached_keys": 7963, "hits": 21, "start_time": 1485163987, "last_restart_time": 0, "oom_restarts": 0, "hash_restarts": 0, "manual_restarts": 0, "misses": 1, "blacklist_misses": 0, "blacklist_miss_ratio": 0, "opcache_hit_rate": 95.454545454545 } }

URL を叩いて返ってきたレスポンスから情報を取得したい場合には、curl プラグインを利用しましたが、今回は json なので curl_json プラグインの登場です。

Plugin:cURL-JSON - collectd Wiki

…と言いたいところですが、curl_json プラグインはうまく動かすことができなかったので、今回は exec プラグインを利用して、curl と jq の合わせ技で実現したいと思います。 exec プラグインは、collectd が外部スクリプトを実行して、そのスクリプトが決まったフォーマットで標準出力した内容を拾ってくれるというものです。

Plugin:Exec - collectd Wiki

こちらも参考にさせていただきました。 collectd の exec プラグインで俺のデータを CloudWatch に飛ばす - ようへいの日々精進XP

exec プラグインを利用して、この json の中から、memory_usage に関する3つの項目 (used, free, wasted) を CloudWatch に連携していきます。

1. 外部スクリプトの作成

exec プラグインでは前述の通り外部スクリプトを実行して値を取得するため、そのスクリプトを用意します。 今回は、http://localhost/opcache.php のレスポンスの json から情報を取得するため、 curl で実行結果を受け取って jq で値を抽出するスクリプトを用意します。

今回用意したスクリプトは以下です。 このスクリプトを /usr/lib/collectd/opcache_stat.sh に配置します。

#!/bin/sh HOSTNAME="${COLLECTD_HOSTNAME:-localhost}" INTERVAL="${COLLECTD_INTERVAL:-60}" while sleep "${INTERVAL}"; do opcache_stat=`curl -s http://localhost/opcache.php` used_memory=`echo ${opcache_stat} | jq -r '.memory_usage.used_memory'` free_memory=`echo ${opcache_stat} | jq -r '.memory_usage.free_memory'` wasted_memory=`echo ${opcache_stat} | jq -r '.memory_usage.wasted_memory'` echo "PUTVAL \"${HOSTNAME}/exec-opcache_stat/memory-used_memory\" interval=${INTERVAL} N:${used_memory}" echo "PUTVAL \"${HOSTNAME}/exec-opcache_stat/memory-free_memory\" interval=${INTERVAL} N:${free_memory}" echo "PUTVAL \"${HOSTNAME}/exec-opcache_stat/memory-wasted_memory\" interval=${INTERVAL} N:${wasted_memory}" done

このスクリプトでは、${INTERVAL} 秒毎に、http://localhost/opcache.php のレスポンスを受け取り、以下のフォーマットに従って標準出力への echo を繰り返します。

PUTVAL "{Host 名}/{Plugin 名}-{PluginInstance 名}/{Type}-{Metrics 名}" interval={インターバル(秒)} N:{計測値}

PUTVAL

(恐らく)フォーマットに従って標準出力した値を collectd が拾うための接頭辞だと思います

詳細はこちら → Plain text protocol - collectd Wiki#PUTVAL

Host 名

その通り、ホスト名です。

/opt/collectd-plugins/cloudwatch/config/plugin.conf に設定している host と同じもの（＝${COLLECTD_HOSTNAME} の値）を指定すると良い感じになります

Plugin 名

このプラグインの名前を指定します

今回は exec プラグインを使用しているので exec を指定していますが、任意の名前で構いません(例えば "opcache" 等)

PluginInstance 名

CloudWatch のメトリクスの画面で表示される PluginInstance に表示される名前

大項目を Host 名とした場合、PluginInstance は中項目のようなもの

後で出てくる画像を見ていただければどこに出てくるものかわかると思います

任意の値で構いませんので、識別しやすい名前を付けると良いと思います

Type

php-fpm のステータス情報を collectd を使って CloudWatch に連携する にも出てきましたが、types.db にあるものの中から指定します

types.db については以下を参照 types.db(5) – collectd – The system statistics collection daemon

Metrics 名

PluginInstance 名と同じようなものです

小項目という扱いがわかりやすいかと思います

インターバル(秒)

何秒間隔で値を取っているか、ということを明示するために指定します

N:{計測値}

"N" のところは、Unixtime 形式のタイムスタンプを指定するのですが、"N" を指定すると現在時刻という意味の指定になります

計測値には該当する値を指定します

2. collectd の設定ファイル (/etc/collectd.conf) に以下の設定をする

以下の設定ファイルを /etc/collectd.d/opcache.conf に配置する

LoadPlugin exec <Plugin exec> Exec nginx "/usr/lib/collectd/opcache_stat.sh" </Plugin>

Exec {スクリプト実行ユーザ} "{スクリプトの場所}" という指定の仕方をします。 対象のスクリプトを実行できるユーザなら何を指定しても良いですが、root は指定できませんのでご注意ください。 今回は php を nginx で動かしているので、nginx ユーザでこのスクリプトを実施するように指定しています。

3. 設定後、collectd を再起動

$ sudo service collectd restart

4. blocked_metrics に以下のものが追加されていることを確認する

$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics 〜略〜 exec-opcache_stat-memory-used_memory exec-opcache_stat-memory-free_memory exec-opcache_stat-memory-wasted_memory 〜略〜

5. CloudWatch に送る対象として、上記をホワイトリストに追記する

$ sudo sh -c 'echo "exec-opcache_stat-.*" >> /opt/collectd-plugins/cloudwatch/config/whitelist.conf'

6. 設定後、collectd を再起動

$ sudo service collectd restart

7. blocked_metrics から追加されたものが消えているのを確認する

$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics

8. CloudWatch 上でグラフ化されていることを確認する

しばらく待つと CloudWatch に以下の通り OPcache の メトリクスが追加されます。

まとめ

今回は php の OPcache のステータス情報を、exec プラグインを利用して CloudWatch に連携してみましたが、exec プラグインを利用すればどんな値でも連携可能ということになるかと思います。

全国の Ansible 派のみなさん、こんにちは。 ブログの投稿頻度急上昇中、インフラストラクチャー部の沼沢です。

今回は Ansible で対話型のスクリプトを自動化する際に利用する expect モジュールについてです。 先日、expect モジュールを利用していて罠にハマったので、その内容と対処法をご紹介したいと思います。

Linux には対話形式の入力を自動化する expect というコマンドがあります。 Linuxの対話がめんどくさい?そんな時こそ自動化だ！-expect編- - Qiita

Ansible にも、このコマンドと同じことを実現するモジュールがあり、それが expect モジュールです。覚えやすいですね。 expect - Executes a command and responds to prompts — Ansible Documentation

では、この expect モジュールを使って対話スクリプトの自動化をしてみます。

前提

本投稿は以下を対象としています。

Ansible 2.1 以上のバージョン

対向: Amazon Linux AMI release 2016.09

ec2:DescribeInstances が許可された IAM ロールが付いた EC2 インスタンス

基本的な使い方

まずは expect モジュールの基本的な使い方を、例を使ってご紹介します。 例えば、以下はユーザ名とパスワードを求められるようなスクリプトを Ansible で実行しようとした場合の例です。

- tasks: - name: ユーザ名とパスワードが必要なスクリプトを実行 expect: command: sh example.sh chdir: /tmp responses: "^Enter User Name: .*": "user1" "^Enter Password: .*": "password"

上記の task では以下のことを実行しています。

/tmp に移動してから sh example.sh を実行

"^Enter User Name: .*" に一致する文字列で入力待ち状態になったら "user1" と入力して Enter

"^Enter Password: .*" に一致する文字列で入力待ち状態になったら "password" と入力して Enter

見ての通り、responses では 質問で入力待ちになる際の文字列を指定する正規表現 と、その際に入力する文字列 を指定します。

ある日、罠にハマる

この使い方で、collectd の CloudWatch プラグインのセットアップスクリプト(※)を自動化しようとした際に罠にハマりました。 ※参考: 新しい collectd の CloudWatch プラグイン | Amazon Web Services ブログ

setup.py では、以下の4つの入力が求められます。

Choose AWS region for published metrics: 1. Automatic [ap-northeast-1] 2. Custom Enter choice [1]: Choose hostname for published metrics: 1. EC2 instance id [i-xxxxxxxxxxxxxxxxx] 2. Custom Enter choice [1]: Choose authentication method: 1. IAM Role [hogehoge-ec2-role] 2. IAM User Enter choice [1]: Choose how to install CloudWatch plugin in collectd: 1. Do not modify existing collectd configuration 2. Add plugin to the existing configuration Enter choice [2]:

Enter choice [x]: という質問でそれぞれ入力待ちになり、未入力で Enter を押した場合は [x] の数字が選択される事になりますが、今回は以下のように入力したいと考えていました。

Choose AWS region for published metrics: 1. Automatic [ap-northeast-1] 2. Custom Enter choice [1]: 1 Choose hostname for published metrics: 1. EC2 instance id [i-xxxxxxxxxxxxxxxxx] 2. Custom Enter choice [1]: 2 Enter hostname [ip-xxx-xxx-xxx-xxx]: web01 ← EC2 の Name タグの値 Choose authentication method: 1. IAM Role [hogehoge-ec2-role] 2. IAM User Enter choice [1]: 1 Choose how to install CloudWatch plugin in collectd: 1. Do not modify existing collectd configuration 2. Add plugin to the existing configuration Enter choice [2]: 2

これを自動化しようとして Ansible を以下のように書きました。

## ※※注※※ この Ansible は expect モジュールの部分が期待通りに動きません ## - tasks: - name: collectd インストール yum: name=collectd state=present - name: pexpect インストール (expectモジュールの利用に必要) pip: name=pexpect state=present - name: EC2 インスタンス ID 取得 shell: curl http://169.254.169.254/latest/meta-data/instance-id changed_when: False register: instance_id - name: EC2 インスタンスの Name タグの値を取得 shell: > aws ec2 describe-instances \ --region ap-northeast-1 \ --query 'Reservations[].Instances[?InstanceId==`{{ instance_id.stdout }}`].Tags[][?Key==`Name`].Value' \ --output text changed_when: False register: instance_name - name: collectd の CloudWatch プラグインのセットアップスクリプト取得 get_url: url=https://raw.githubusercontent.com/awslabs/collectd-cloudwatch/master/src/setup.py dest=/var/tmp/setup.py mode=0755 - name: collectd の CloudWatch プラグインセットアップ expect: command: ./setup.py chdir: /var/tmp responses: "Enter choice \\[\\\u001b\\[92m1\\\u001b\\[0m\\]: ": "1" "Enter choice \\[\\\u001b\\[92m1\\\u001b\\[0m\\]: ": "2" "Enter hostname \\[\\\u001b\\[92m.*\\\u001b\\[0m\\]: ": "{{ instance_name.stdout }}" "Enter choice \\[\\\u001b\\[92m1\\\u001b\\[0m\\]: ": "1" "Enter choice \\[\\\u001b\\[92m2\\\u001b\\[0m\\]: ": "2"

もう既に正規表現がややこしいですね。 上記で書いてある通り、この expect モジュールの書き方では期待している入力を行ってくれません。しかも エラーにもならない ので質が悪いです。 ※そういう書き方をした自分が一番悪い

上記を実行すると、上から "1"、"1"、"1"、"2" が入力されて処理が終わります。

なぜ期待通りに動かないか

よく見たらドキュメントにしっかりと書いてありました。

responses で定義した正規表現で同じ質問が連続でマッチした場合は、最初に定義した回答が全ての質問に適用されるようです。 どういうことかというと、今回の対話スクリプトの入力待ちの部分だけに注目すると、

Enter choice [1]: Enter choice [1]: Enter choice [1]: Enter choice [2]:

上記の4つのうち、3つ目までは入力待ち時の質問の文字列が全く同じ なのです。 で、expect モジュールの responses を再度確認すると、このように書いていました。

"Enter choice \\[\\\u001b\\[92m1\\\u001b\\[0m\\]: ": "1" "Enter choice \\[\\\u001b\\[92m1\\\u001b\\[0m\\]: ": "2" "Enter hostname \\[\\\u001b\\[92m.*\\\u001b\\[0m\\]: ": "{{ instance_name.stdout }}" "Enter choice \\[\\\u001b\\[92m1\\\u001b\\[0m\\]: ": "1" "Enter choice \\[\\\u001b\\[92m2\\\u001b\\[0m\\]: ": "2"

1〜3つ目までは同じ質問が続いているため、最初に定義してある入力待ちの質問を指定する正規表現が 1〜3つ目までの質問全てと一致しているため、その回答である "1" が1〜3つ目まで全てに入力されるということになります。

2つ目で "2" が入力されてほしいのにスルーされて悲しい気持ちです。

ではどうするか

これもドキュメントに書いてありました。

この例のように書くことで、同じ質問が連続しても順番に従って回答してくれるようです。 そして今回の場合には以下のように書くことで期待通りの動きをするようになりました。(抜粋)

- name: collectd の CloudWatch プラグインセットアップ expect: command: ./setup.py chdir: /var/tmp responses: "Enter choice \\[\\\u001b\\[92m1\\\u001b\\[0m\\]: ": - "1" - "2" - "1" "Enter hostname \\[\\\u001b\\[92m.*\\\u001b\\[0m\\]: ": - "{{ instance_name.stdout }}" "Enter choice \\[\\\u001b\\[92m2\\\u001b\\[0m\\]: ": - "2"

同じ質問に対して、回答内容を配列で順番に渡すことで、その順番通りに回答をしてくれます。

1回目の Enter choice [1]: では "1"

2回目の Enter choice [1]: では "2"

3回目の Enter choice [1]: では "1"

1回目の Enter hostname [1]: では取得した Name タグの値

1回目の Enter choice [2]: では "2"

これで無事にやりたいことが実現できました。

注意

同じ質問に対して別の回答をする機能は、バージョン 2.1 で実装されたものなので、2.1 未満のバージョンを使っている場合は、同じ質問では同じ回答しかできないという悲しい結果になるのでご注意ください。

まとめ

こんにちは、インフラストラクチャー部の沼沢です。

前回の nginx に引き続き、collectd を使って php-fpm の情報を CloudWatch に連携する具体例をご紹介したいと思います。

参考: nginx の各種情報を collectd を使って CloudWatch に連携する

前提

Amazon Linux AMI release 2016.09

collectd 5.4.1

php 関連 5.6.28

本投稿の例は、以下と同等の状態ができあがっているという前提で進めます

新しい collectd の CloudWatch プラグイン | Amazon Web Services ブログ

collectdのCloudWatchプラグインを試してみた ｜ Developers.IO

collectd の設定ファイルについては、デフォルトで記述されいてるコメントアウトの部分は基本的に無視して追記していくスタイルを取ります

LoadPlugin だけはコメントアウト解除で対応

pm.status_path の値を CloudWatch に連携

pm.status_path とは、php-fpm のプロセス数などのステータス情報を取得するための設定です。 詳細は PHP: 設定 - Manual をご確認ください。

ローカルから curl http://localhost/www-status を実行して以下のような結果が返ってくる設定ができているものとします。

$ curl http://localhost/www-status pool: www process manager: static start time: 22/Dec/2016:18:32:27 +0900 start since: 406243 accepted conn: 8806 listen queue: 0 max listen queue: 0 listen queue len: 0 idle processes: 4 active processes: 1 total processes: 5 max active processes: 1 max children reached: 0 slow requests: 0

URL を叩いて返ってきたレスポンスから情報を取得したい場合には、curl プラグインを利用します。

Plugin:cURL - collectd Wiki

curl プラグインを利用して、このレスポンスの中から、プロセスに関する4つの項目 (idle, active, total, max active) を CloudWatch に連携していきます。

余談ですが、レスポンスが json や xml の場合には curl_json プラグイン や curl_xml プラグイン を利用したほうがスマートに設定できます。 これらはまた別の機会にご紹介したいと思います。

1. プラグインをインストール

curl プラグインを利用する場合、 collectd-curl をインストールします。

$ sudo yum install collectd-curl

2. collectd の設定ファイル (/etc/collectd.conf) に以下の設定をする

#LoadPlugin curl のコメントアウトを外す

以下を追記する

<Plugin curl> <Page "www"> URL "http://localhost/www-status" <Match> Regex "^idle processes: *([0-9]+)" DSType "GaugeLast" Type "phpfpm_processes" Instance "idle" </Match> <Match> Regex "^active processes: *([0-9]+)" DSType "GaugeLast" Type "phpfpm_processes" Instance "active" </Match> <Match> Regex "^total processes: *([0-9]+)" DSType "GaugeLast" Type "phpfpm_processes" Instance "total" </Match> <Match> Regex "^max active processes: *([0-9]+)" DSType "GaugeLast" Type "phpfpm_processes" Instance "max_active" </Match> </Page> </Plugin>

上記では、以下をそれぞれ取得するように設定しています。

1つ目の Match: 計測期間内で取れた最後の idle processes の値

2つ目の Match: 計測期間内で取れた最後の active processes の値

3つ目の Match: 計測期間内で取れた最後の total processes の値

4つ目の Match: 計測期間内で取れた最後の max active processes の値

DSType “GaugeLast” は計測期間(デフォルト10秒)内の最後の数値を取得するという意味です。

DSType については以下ご参考まで。 collectd.conf(5) – collectd – The system statistics collection daemon#plugin_tail

3. types.db に Type を追加

Type には、types.db ファイルに定義してあるものしか指定できません。 上記の設定では Type "phpfpm_processes" を指定していますが、phpfpm_processes はデフォルトでは用意されていないため、これを追加する作業を行います。

types.db(5) – collectd – The system statistics collection daemon

types.db ファイルは、デフォルトでは /usr/share/collectd/types.db にあると思いますが、types.db ファイルの場所は設定ファイルで指定することができます。

TypesDB "/usr/share/collectd/types.db"

このファイルに以下を追記します。

phpfpm_processes value:GAUGE:0:65535

4. 設定後、collectd を再起動

$ sudo service collectd restart

5. blocked_metrics に以下のものが追加されていることを確認する

$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics 〜略〜 curl-www-phpfpm_processes-idle curl-www-phpfpm_processes-active curl-www-phpfpm_processes-total curl-www-phpfpm_processes-max_active 〜略〜

6. CloudWatch に送る対象として、上記をホワイトリストに追記する

$ sudo sh -c 'echo "curl-www-phpfpm_processes-.*" >> /opt/collectd-plugins/cloudwatch/config/whitelist.conf'

7. 設定後、collectd を再起動

$ sudo service collectd restart

8. blocked_metrics から追加されたものが消えているのを確認する

$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics

9. CloudWatch 上でグラフ化されていることを確認する

しばらく待つと CloudWatch に以下の通り php-fpm の メトリクスが追加されます。

まとめ

今回は php-fpm のステータス情報を CloudWatch に連携してみましたが、nginx の時も今回も、こうやっていざやってみると設定はとても簡単な印象があります。

こんにちは、インフラストラクチャー部の沼沢です。

今年の10月頃に、collectd の CloudWatch プラグインが出たのは記憶に新しいです。 新しい collectd の CloudWatch プラグイン | Amazon Web Services ブログ

その後、数々の所謂「試してみたブログ」等もたくさん出回っていますが、あまり具体的な設定の解説をしているものは少ない印象です。 しかも、collectd には日本語のドキュメントは無く、日本語で書かれているブログ等もそう多くはありません。 そのため、深い使い方をするとなると英語のドキュメントを読み解きながら進める必要があり、ここで挫折してしまう方も多いのではないでしょうか。

そんな中、nginx の各種情報について collectd を使って CloudWatch のカスタムメトリクスを作成する機会がありましたので、1つの具体例としてご紹介したいと思います。

前提

Amazon Linux AMI release 2016.09

collectd 5.4.1

nginx 1.11.6

本投稿の例は、以下と同等の状態ができあがっているという前提で進めます

新しい collectd の CloudWatch プラグイン | Amazon Web Services ブログ

collectdのCloudWatchプラグインを試してみた ｜ Developers.IO

collectd の設定ファイルについては、デフォルトで記述されいてるコメントアウトの部分は基本的に無視して追記していくスタイルを取ります

LoadPlugin だけはコメントアウト解除で対応

stub_status の値を CloudWatch に連携

stub_status とは、コネクション数等を確認する nginx のモジュールです。 詳細は Module ngx_http_stub_status_module をご確認ください。

location /nginx-status { stub_status on; }

上記が /etc/nginx.conf に設定されいてる状態でローカルからこのパスにアクセスすると、以下のような情報が取得できます。

$ curl http://localhost/nginx-status Active connections: 6 server accepts handled requests 142929 142929 100818 Reading: 0 Writing: 1 Waiting: 5

これを CloudWatch でグラフ表示していきます。

1. プラグインをインストール

collectd では nginx 専用のプラグインが用意されていますので、そちらを利用します。

$ sudo yum install collectd-nginx

2. collectd の設定ファイル (/etc/collectd.conf) に以下の設定をする

#LoadPlugin nginx のコメントアウトを外す

以下を追記する

<Plugin nginx> URL "http://localhost/nginx-status" </Plugin>

3. 設定後、collectd を再起動

$ sudo service collectd restart

4. blocked_metrics に以下のものが追加されていることを確認する

$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics 〜略〜 nginx--nginx_connections-active nginx--connections-accepted nginx--connections-handled nginx--nginx_requests- nginx--nginx_connections-reading nginx--nginx_connections-writing nginx--nginx_connections-waiting 〜略〜

5. CloudWatch に送る対象として、上記をホワイトリストに追記する

$ sudo sh -c 'echo "nginx--.*" >> /opt/collectd-plugins/cloudwatch/config/whitelist.conf'

6. 設定後、collectd を再起動

$ sudo service collectd restart

7. blocked_metrics から追加されたものが消えているのを確認する

$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics

8. CloudWatch 上でグラフ化されていることを確認する

しばらく待つと CloudWatch に以下の通り nginx のメトリクスが追加されます。

$request_time の値を CloudWatch に連携

$request_time とは、nginx がリクエストを受け取り、レスポンスを返してからアクセスログに書き込むまでの経過時間のことです。

Module ngx_http_log_module

/etc/nginx.conf に以下のように設定したとします。

〜略〜 log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" ' '"$request_time"'; 〜略〜

上記のように、ログの末尾(※)に $request_time が出力されるように設定した後、nginx を再起動すると設定が反映され、$request_time が記録されるようになります。 (下記の例だと "0.214")

xxx.xxx.xxx.xxx - - [26/Dec/2016:17:33:31 +0900] "GET / HTTP/1.1" 200 (...中略...) "xxx.xxx.xxx.xxx" "0.214"

この末尾に記録された $request_time を、CloudWatch に連携してみます。

※末尾にした理由は、正規表現でマッチさせやすくするためです。 そのため、後述の正規表現を変更すればどの位置でもマッチさせられるので、実際はどの位置でも問題ありません。

ログファイル等、追記型のファイルから情報を取得したい場合には、tail プラグインを利用します。

Plugin:Tail - collectd Wiki

tail プラグインはデフォルトで組み込まれているため、nginx プラグインのようなインストール作業は不要です。

1. collectd の設定ファイル (/etc/collectd.conf) に以下の設定をする

#LoadPlugin tail のコメントアウトを外す

以下を追記する(ログファイルの場所は適宜読み換えてください)

<Plugin "tail"> <File "/var/log/nginx/access.log"> Instance "nginx" <Match> Regex "\" \"([0-9.]+)\"$" DSType "GaugeAverage" Type "response_time" Instance "AvgRespTime" </Match> <Match> Regex "\" \"([0-9.]+)\"$" DSType "GaugeMin" Type "response_time" Instance "MinRespTime" </Match> <Match> Regex "\" \"([0-9.]+)\"$" DSType "GaugeMax" Type "response_time" Instance "MaxRespTime" </Match> </File> </Plugin>

上記では、以下をそれぞれ取得するように設定しています。

1つ目の Match: 計測期間内の平均値(DSType "GaugeAverage")

2つ目の Match: 計測期間内の最小値(DSType "GaugeMin")

3つ目の Match: 計測期間内の最大値(DSType "GaugeMax")

3つの Match はそれぞれ同じ値をヒットさせる正規表現を書いていますが、DSType を指定することでそれぞれ取得する値の性質を分けています。 計測期間というのは Interval という設定で指定でき、デフォルトでは10秒間隔で計測するようになっています。 つまり、10秒のうちの平均値、最小値、最大値を取得しているということになります。

DSType については以下を参考にいろいろ試してみてください。 collectd.conf(5) – collectd – The system statistics collection daemon#plugin_tail

3. 設定後、collectd を再起動

$ sudo service collectd restart

4. blocked_metrics に以下のものが追加されていることを確認する

$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics 〜略〜 tail-nginx-response_time-AvgRespTime tail-nginx-response_time-MinRespTime tail-nginx-response_time-MaxRespTime 〜略〜

5. CloudWatch に送る対象として、上記をホワイトリストに追記する

$ sudo sh -c 'echo "tail-nginx-response_time-.*" >> /opt/collectd-plugins/cloudwatch/config/whitelist.conf'

6. 設定後、collectd を再起動

$ sudo service collectd restart

7. blocked_metrics から追加されたものが消えているのを確認する

$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics

8. CloudWatch 上でグラフ化されていることを確認する

しばらく待つと CloudWatch に以下の通り nginx の response_time のメトリクスが追加されます。

まとめ

collectd の CloudWatch プラグインが出たことでカスタムメトリクスがより簡単に追加できるようになっています。

Fix: How do StatsD and CollectD relate? #dev #programming #computers

How do StatsD and CollectD relate?

How do StatsD and CollectD relate?

Is StatsD and alternative to CollectD

Is StatsD used to aggregate metrics coming from CollectD (and possibly other tools)

something else entirely. If so what?

Answer [by Teftin]: How do StatsD and CollectD relate?

They are different things.

CollectD is statistics collection daemon. It periodically pools various sources…