2015年4月20日月曜日

Nagiosでデータ転送量を監視する

Andrew Hart Follow All Systems GO! https://www.flickr.com/photos/andrewfhart/8106200690
SNMPエージェントである Net-SNMP をインストールして使えるようにします。
SNMPを使用して、データ転送量をNagiosで監視します。
Net-SNMPの使い方は、若干複雑なのですが、最低限の設定で利用できるように解説しました。
環境は、Amazon Linux AMI 2015.03 (HVM) - ami-cbf90ecbです。


Net-SNMPを準備

net-snmpをインストール
# yum -y install net-snmp net-snmp-utils
# chkconfig snmpd on
snmpdの設定ファイルを編集
# emacs /etc/snmp/snmpd.conf

# Make at least  snmpwalk -v 1 localhost -c public system fast again.
#       name           incl/excl     subtree         mask(optional)
#view    systemview    included   .1.3.6.1.2.1.1
#view    systemview    included   .1.3.6.1.2.1.25.1.1
view    all     included        .1      80

####
# Finally, grant the group read-only access to the systemview view.

#       group          context sec.model sec.level prefix read   write  notif
#access  notConfigGroup ""      any       noauth    exact  systemview none none
access  notConfigGroup ""      any       noauth    exact  all none none
snmpdをリスタート
# service snmpd restart
インタフェース名一覧を表示
# snmpwalk -v 1 -c public localhost ifDescr
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: eth0
eth0のインデックス番号は「2」であることが分かります。eth0に関して調べるときには、この番号を使います。
送受信オクテット累積数を確認してみます。
IF-MIB::ifInOctets.1がlo、IF-MIB::ifInOctets.2がeth0です。
bpsとして見るには、取得した値の差 × 8 ÷ 取得間隔(秒)というように計算します。

受信オクテット累積数
# snmpwalk -v 1 -c public localhost ifInOctets
IF-MIB::ifInOctets.1 = Counter32: 3755493095
IF-MIB::ifInOctets.2 = Counter32: 541310019
送信オクテット累積数
# snmpwalk -v 1 -c public localhost ifOutOctets
IF-MIB::ifOutOctets.1 = Counter32: 3757407963
IF-MIB::ifOutOctets.2 = Counter32: 361982746
Net-SNMPの準備が出来ました。


check_snmpを実行

check_snmpプラグインを使ってみます。
nagios-nrpeとcheck_snmpプラグインがない場合は、インストールしておきます。
# yum -y install nagios-nrpe
# yum -y install nagios-plugins-all
check_snmpプラグインにパラメータを設定して実行。 受信と送信の2つを設定します。IF-MIB::ifHCInOctets.2とIF-MIB::ifHCOutOctets.2です。
警告50MBps、クリティカル100MBpsです。
受信
# /usr/lib64/nagios/plugins/check_snmp community -H 127.0.0.1 -C public -P 2c -o IF-MIB::ifHCInOctets.2 -w 52428800 -c 104857600 --rate --rate-multiplier 8 -u "bps in." 
送信
# /usr/lib64/nagios/plugins/check_snmp community -H 127.0.0.1 -C public -P 2c -o IF-MIB::ifHCOutOctets.2  -w 52428800 -c 104857600 --rate --rate-multiplier 8 -u "bps out." 
初回実行時には情報の記録のため以下の出力になります。
No previous data to calculate rate - assume okay
2回目移行から以下のように情報が表示されます。
SNMP RATE OK - 74733.6 bps in | IF-MIB::ifHCInOctets.2=74733.6
check_snmpプラグインの動作に問題がなかったら、nagios(nrpe)のために一時ファイルのパーミッションを設定しておきましょう。
# chown nrpe:nrpe /var/check_snmp
あとは、Nagiosに組み込んでおけばOKです。


参考資料
Monitoring Routers and Switches
http://nagios.sourceforge.net/docs/3_0/monitoring-routers.html
snmpd 設定方法
http://changineer.info/server/monitoring/monitoring_snmpd.html
net-snmpの設定 - Qiita
http://qiita.com/toshiro3/items/e8f87da88cd383a6421d
CentOSでNet-SNMPインストールと設定 | GOISBLOG
https://genchan.net/server/4393
Nagiosでサーバのトラフィック監視を行う方法 – Jラボ « Jラボ
http://junrei.dip.jp/wordpress/nagios/nagios%E3%81%A7%E3%82%B5%E3%83%BC%E3%83%90%E3%81%AE%E3%83%88%E3%83%A9%E3%83%95%E3%82%A3%E3%83%83%E3%82%AF%E7%9B%A3%E8%A6%96%E3%82%92%E8%A1%8C%E3%81%86%E6%96%B9%E6%B3%95/
Nagiosでトラフィックグラフを作成/監視 check_snmp | ITオフィスサポートとシステム開発|システムガーディアン 東京都中央区八丁堀
http://sys-guard.com/nagios%E3%81%A7%E3%83%88%E3%83%A9%E3%83%95%E3%82%A3%E3%83%83%E3%82%AF%E3%82%B0%E3%83%A9%E3%83%95%E3%82%92%E4%BD%9C%E6%88%90%E7%9B%A3%E8%A6%96-check_snmp/
Nagiosのcheck_snmpプラグインの --rate オプションを試す - blog.nomadscafe.jp
http://blog.nomadscafe.jp/2013/02/nagioscheck-snmp---rate.html

2015年4月16日木曜日

GitHubのパンチカード

GitHubにはパンチカードという機能があって、いつ仕事したのかを可視化できて面白い。
レポジトリの右側のリンクから確認できます。
パンチカードのグラフは、曜日と時間にもとづいてあなたのリポジトリの更新頻度を示しています。
黒丸の大きさはコミットの頻度を示しています。
このグラフにはマージコミットは含まれていません。
上記のような仕様だそうです。
自分がメインで使っているレポジトリのパンチカードを見たら、おもっていたより ”メリハリをつけて仕事をしている” と言ってもいいような絵になっていました。
そこはかとなく。緊急対応もしているように見えますね。

参考資料
About Repository Graphs - User Documentation
https://help.github.com/articles/about-repository-graphs/

2015年4月15日水曜日

Embulkを使ってJSONデータをGoogle BigQueryに投入する

erokism Follow Bulk? paste up in Manchester https://www.flickr.com/photos/10295270@N05/4163403080
Embulkのアウトプット・プラグインであるembulk-output-bigqueryを使って、JSONデータをGoogle BigQueryに投入します。

JSONのサンプルデータを用意。
# emacs /tmp/json_sample.json
{ "first_name":"John", "last_name":"Lennon", "age":20 }
{ "first_name":"Paul", "last_name":"Maccartney", "age":22 }
Google BigQueryのスキーマファイルを用意。
# emacs /tmp/schema.json
[
  {"name":"first_name","mode":"REQUIRED","type":"STRING"},
  {"name":"last_name","mode":"REQUIRED","type":"STRING"},
  {"name":"age","mode":"REQUIRED","type":"INTEGER"}
]
Javaをインストール。
# yum install -y java-1.8.0-openjdk
Embulkをインストール。
# curl --create-dirs -o ~/.embulk/bin/embulk -L "http://dl.embulk.org/embulk-latest.jar"
# chmod +x ~/.embulk/bin/embulk
# echo 'export PATH="$HOME/.embulk/bin:$PATH"' >> ~/.bashrc
# source ~/.bashrc
# embulk --version
embulk 0.6.2
Embulkプラグインをインストール。
# embulk gem install embulk-parser-jsonl
# embulk gem install embulk-output-bigquery
# embulk gem install embulk-formatter-jsonl
Embulkの設定ファイルを用意。
service_account_email、project、path_prefix、datasetにGoogle BigQueryのアカウント情報を記述します。
テーブルは自動生成オプションを有効にして、テーブルの末尾に _%Y%m%d を付けるようにしています。
# emacs config.yml
exec: {}
in:
  type: file
  path_prefix: /tmp/json_
  parser:
    type: jsonl
    root: $.students
    schema:
      - {name: first_name, type: string}
      - {name: last_name, type: string}
      - {name: age, type: long}
out:
  type: bigquery
  service_account_email: your_id@developer.gserviceaccount.com
  project: your-project-000
  p12_keyfile_path: /path/to/p12_keyfile.p12
  dataset: my_dataset
  path_prefix: /var/tmp/sample
  source_format: NEWLINE_DELIMITED_JSON
  file_ext: .json.gz
  delete_from_local_when_job_end: 1
  auto_create_table: 1
  schema_path: /tmp/schema.json
  table: students_%Y%m%d
  formatter:
    type: jsonl
  encoders:
    - {type: gzip}
Embulkインプットのプレヴューを実行。
# embulk preview config.yml
2015-04-15 15:29:36.316 +0900: Embulk v0.6.2
2015-04-15 15:29:37.649 +0900 [INFO] (preview): Listing local files at directory '/tmp' filtering filename by prefix 'json_'
2015-04-15 15:29:37.654 +0900 [INFO] (preview): Loading files [/tmp/json_sample.json]
+-------------------+------------------+----------+
| first_name:string | last_name:string | age:long |
+-------------------+------------------+----------+
|              John |           Lennon |       20 |
|              Paul |       Maccartney |       22 |
+-------------------+------------------+----------+
Embulkを実行。
# embulk run config.yml
2015-04-15 06:35:03.544 +0000: Embulk v0.6.2
2015-04-15 06:35:05.422 +0000 [INFO] (transaction): Listing local files at directory '/tmp' filtering filename by prefix 'json_'
2015-04-15 06:35:05.426 +0000 [INFO] (transaction): Loading files [/tmp/json_sample.json]
2015-04-15 06:35:06.752 +0000 [INFO] (transaction): {done:  0 / 1, running: 0}
2015-04-15 06:35:07.027 +0000 [INFO] (task-0000): Writing file [/var/tmp/sample.000.00.json.gz]
2015-04-15 06:35:07.044 +0000 [INFO] (task-0000): Job preparing... project:your-project-000 dataset:my_dataset table:students_20150415
2015-04-15 06:35:07.049 +0000 [INFO] (task-0000): table:[students_20150415] will be create if not exists
2015-04-15 06:35:07.054 +0000 [INFO] (task-0000): Upload start [/var/tmp/sample.000.00.json.gz]
2015-04-15 06:35:11.120 +0000 [INFO] (task-0000): Upload completed [/var/tmp/sample.000.00.json.gz]
2015-04-15 06:35:11.125 +0000 [INFO] (task-0000): Job executed. job id:[job_kRqcNXo8EXrCneT9h3cCUpR67lQ] file:[/var/tmp/sample.000.00.json.gz]
2015-04-15 06:35:11.487 +0000 [INFO] (task-0000): Checking job status... job id:[job_kRqcNXo8EXrCneT9h3cCUpR67lQ] elapsed_time:362ms status:[PENDING]
2015-04-15 06:35:21.766 +0000 [INFO] (task-0000): Checking job status... job id:[job_kRqcNXo8EXrCneT9h3cCUpR67lQ] elapsed_time:10641ms status:[PENDING]
2015-04-15 06:35:32.112 +0000 [INFO] (task-0000): Checking job status... job id:[job_kRqcNXo8EXrCneT9h3cCUpR67lQ] elapsed_time:20987ms status:[RUNNING]
2015-04-15 06:35:42.351 +0000 [INFO] (task-0000): Job statistics [{"inputFileBytes":"83","inputFiles":"1","outputBytes":"48","outputRows":"2"}]
2015-04-15 06:35:42.352 +0000 [INFO] (task-0000): Job completed successfully. job id:[job_kRqcNXo8EXrCneT9h3cCUpR67lQ] elapsed_time:31227ms status:[SUCCESS]
2015-04-15 06:35:42.352 +0000 [INFO] (task-0000): Delete local file [/var/tmp/sample.000.00.json.gz]
2015-04-15 06:35:42.352 +0000 [INFO] (transaction): {done:  1 / 1, running: 0}
2015-04-15 06:35:42.367 +0000 [INFO] (main): Committed.
2015-04-15 06:35:42.367 +0000 [INFO] (main): Next config diff: {"in":{"last_path":"/tmp/json_sample.json"},"out":{}}
Embulkの処理が完了しました。
確認してみましょう。


JSONデータがGoogle BigQueryに投入されました。

続いて大量データを投入してみます。
環境は、EC2のc4.large(Amazon Linux AMI 2015.03 (HVM), SSD Volume Type)です。
1億行のJSONを用意しました。ファイルサイズは5.7GBです。
実行結果は以下のようになりました。
2015-04-15 07:33:04.426 +0000: Embulk v0.6.2
2015-04-15 07:33:06.352 +0000 [INFO] (transaction): Listing local files at directory '/tmp' filtering filename by prefix 'json_'
2015-04-15 07:33:06.357 +0000 [INFO] (transaction): Loading files [/tmp/json_sample.json]
2015-04-15 07:33:07.632 +0000 [INFO] (transaction): {done:  0 / 1, running: 0}
2015-04-15 07:33:08.036 +0000 [INFO] (task-0000): Writing file [/var/tmp/sample.000.00.json.gz]
2015-04-15 07:57:19.158 +0000 [INFO] (task-0000): Job preparing... project:your-project-000 dataset:my_dataset table:students_20150415
2015-04-15 07:57:19.164 +0000 [INFO] (task-0000): table:[students_20150415] will be create if not exists
2015-04-15 07:57:19.171 +0000 [INFO] (task-0000): Upload start [/var/tmp/sample.000.00.json.gz]
2015-04-15 08:00:38.361 +0000 [INFO] (task-0000): Upload completed [/var/tmp/sample.000.00.json.gz]
2015-04-15 08:00:38.366 +0000 [INFO] (task-0000): Job executed. job id:[job_LoZky6tlYHA0hKEnT279_Ytni5c] file:[/var/tmp/sample.000.00.json.gz]
2015-04-15 08:00:38.620 +0000 [INFO] (task-0000): Checking job status... job id:[job_LoZky6tlYHA0hKEnT279_Ytni5c] elapsed_time:254ms status:[PENDING]
中略
2015-04-15 08:07:07.867 +0000 [INFO] (task-0000): Job completed successfully. job id:[job_LoZky6tlYHA0hKEnT279_Ytni5c] elapsed_time:389501ms status:[SUCCESS]
2015-04-15 08:07:07.867 +0000 [INFO] (task-0000): Delete local file [/var/tmp/sample.000.00.json.gz]
2015-04-15 08:07:07.894 +0000 [INFO] (transaction): {done:  1 / 1, running: 0}
2015-04-15 08:07:07.911 +0000 [INFO] (main): Committed.
2015-04-15 08:07:07.911 +0000 [INFO] (main): Next config diff: {"in":{"last_path":"/tmp/json_sample.json"},"out":{}}

real 34m7.619s
user 24m33.712s
sys 0m38.524s
バッファ用のファイル作成に時間がかかっています。開始から完了まで34分でした。

まとめ
Embulkを使ってJSONデータをGoogle BigQueryに投入するまでの流れを追ってみました。
コマンドひとつでデータを投入できるのが良いです。
Google BigQueryはストリームでのインポートも可能ですが、ストリーム処理にかかる料金が必要だったり、APIが不安定で、データの投入失敗・重複などデメリットがあります。より正確なデータの投入を目指すのならば、Embulkは選択肢のひとつになると思います。
https://cloud.google.com/bigquery/quota-policy
実際に運用するときには、Quota Policyの制限に注意しましょう。

2015年4月10日金曜日

Redisマスターはexpiresしたデータをスレーブに送信しない


参考資料
http://fnordig.de/redis-faq/
http://grokbase.com/t/gg/redis-db/1254g6eebv/sync-not-copying-all-keys
INFO keyspace shows a different number of keys on the slave than on the master
First: check that master and slave are in sync.
Do this by checking INFO replication of both master and slave and compare master_repl_offset and slave_repl_offset.
Next: Do you have a lot of expires?
On initial sync the slave will drop all already expired keys, while they may still be in the master instance (but are gone as soon as you try to fetch them).
(by: Moe, also sync not copying all keys)

マスターとスレーブでかなりキーの違いがあるな?と思ったら仕様でした。
期限切れのデータをスレーブに送信していないためです。
また、直接スレーブにexpiresをつけたデータを入れると、削除されずに残り続けるので注意。

2015年4月9日木曜日

大量データを持つRedisのレプリケーションを作るときにやったこと

Simon Berry THE PILOT | REPLICATION PLANNING https://www.flickr.com/photos/bezznet/5377561358
10GB超のデータを持つRedisのレプリケーションを作ろうとしたとき、通常の方法ではレプリケーションが構築できませんでした。
[2905] 03 Apr 11:19:11.050 # Client id=5243450 addr=10.10.10.10:58580 fd=10 name= age=68 idle=68 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=16362 oll=9770 omem=252745360 events=rw cmd=psync scheduled to be closed ASAP for overcoming of output buffer limits.
[2905] 03 Apr 11:19:11.150 # Connection with slave 10.10.10.10:6379 lost.
上記のようにRedisマスターのログにコネクションロストが出力されて。レプリケーションを再構築しようと何度もリトライがかかるようになり、レプリケーションが完了しない状態に陥りました。

この状況を回避するためにやったことは以下のようになります。
すべて、Redisマスターでの設定になります。

1)レプリケーションタイムアウトを伸ばしておく。
$ redis-cli CONFIG GET repl-timeout
1) "repl-timeout"
2) "60"
$ redis-cli CONFIG SET repl-timeout "1800" 
2)ディスクレスレプリケーションを有効にする。
$ redis-cli CONFIG GET repl-diskless-sync
1) "repl-diskless-sync"
2) "no"
$ redis-cli CONFIG SET repl-diskless-sync "yes" 
3)同期遅延の設定を0にする。
$ redis-cli CONFIG GET repl-diskless-sync-delay
1) "repl-diskless-sync-delay"
2) "5"
$ redis-cli CONFIG SET repl-diskless-sync-delay "0" 
4)client-output-buffer-limit slaveの値を無効化する。
$ redis-cli CONFIG GET client-output-buffer-limit
1) "client-output-buffer-limit"
2) "normal 0 0 0 slave 268435456 67108864 60 pubsub 33554432 8388608 60"
$ redis-cli CONFIG SET client-output-buffer-limit "slave 0 0 0"

これらの設定をした後に、スレーブサーバでRedisを起動します。
レプリケーション構築の成功時のログは以下のようになります。

Redisマスター側のスレーブ構築成功のログ
[8590] 03 Apr 15:17:38.563 * Streamed RDB transfer with slave 10.10.10.10:6379 succeeded (socket). Waiting for REPLCONF ACK from slave to enable streaming
[8590] 03 Apr 15:18:51.758 * Synchronization with slave 10.10.10.10:6379 succeeded
Redisスレーブ側のスレーブ構築成功のログ
[3341] 03 Apr 15:11:30.839 * Full resync from master: f32b9311221a763966777e18e84c93d7389f4119:1
[3341] 03 Apr 15:11:31.469 * MASTER <-> SLAVE sync: receiving streamed RDB from master
[3341] 03 Apr 15:17:38.331 * MASTER <-> SLAVE sync: Flushing old data
[3341] 03 Apr 15:17:38.331 * MASTER <-> SLAVE sync: Loading DB in memory
[3341] 03 Apr 15:18:51.142 * MASTER <-> SLAVE sync: Finished with success

以下の資料を参考にしました。

Replication – Redis
http://redis.io/topics/replication

Top Redis Headaches for Devops – Replication Buffer
https://redislabs.com/blog/top-redis-headaches-for-devops-replication-buffer#.VR4z2JOUc4Q

Top Redis Headaches for Devops – Replication Timeouts
https://redislabs.com/blog/top-redis-headaches-for-devops-replication-timeouts#.VR4z2pOUc4Q

2015年4月8日水曜日

HATopでHAProxyを監視・インタラクティブに操作

Quentin Meulepas MacBook Colors https://www.flickr.com/photos/kwintin/3473840881
http://feurix.org/projects/hatop/
HATopはHAProxyのクライアントソフトのひとつです。
HAProxyの統計情報を表示したり、ウェイトのパラメータなどをインタラクティブに操作できるようにします。
Python 2.4以上。HAProxy 1.4以上で動作します。



以下、セットアップ方法です。

HAProxyの設定に"stats socket"を追加しておきます。
# vim /etc/haproxy/haproxy.cfg 
    stats socket /var/lib/haproxy/stats user root group wheel level admin

# service haproxy reload
HATopのソースを取得してインストール。
# wget http://hatop.googlecode.com/files/hatop-0.7.7.tar.gz
# tar zxvf hatop-0.7.7.tar.gz
# cd hatop-0.7.7
# install -m 755 bin/hatop /usr/bin
# hatop -h
Usage: hatop -s SOCKET [OPTIONS]...

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit

  Mandatory:
    -s SOCKET, --unix-socket=SOCKET
                        path to the haproxy unix socket

  Optional:
    -i INTERVAL, --update-interval=INTERVAL
                        update interval in seconds (1-30, default: 3)
    -m MODE, --mode=MODE
                        start in specific mode (1-5, default: 1)
    -n, --read-only     disable the cli and query for stats only

  Filters:
    Note: All filter options may be given multiple times.

    -f FILTER, --filter=FILTER
                        stat filter in format "  "
    -p PROXY, --proxy=PROXY
                        proxy filter in format ""
HATopを起動。アップデート間隔を1秒としています。
# hatop -s /var/lib/haproxy/stats -i 1
キー 操作は以下のようになります。
h ヘルプを表示
TAB 表示モード切り替え
F4 Weightリセット
F5 Weight -10
F6 Weight -1
F7 Weight +1
F8 Weight +10
F9 有効化
F10 無効化
HATopを使って、簡単にHAProxyを操作できるようになりました。

HAProxyを監視するNagiosプラグイン

Clay Junell macbook air https://www.flickr.com/photos/slopjop/3342521518

http://exchange.nagios.org/directory/Plugins/Network-Connections,-Stats-and-Bandwidth/HAProxy-check/details
HAProxyを監視するNagiosプラグインです。
HAProxy配下のサーバのアップダウンや、セッション数にしきい値を設けてアラート出来ます。


以下、セットアップ方法です。

HAProxyのステータスを取得できるようにしておきます。
# vim /etc/haproxy/haproxy.cfg

#---------------------------------------------------------------------
# stats
#---------------------------------------------------------------------
listen stats 127.0.0.1:1919
    mode http
    stats uri /haproxy-status

# service haproxy reload
# curl '127.0.0.1:1919/haproxy-status?stats;csv'
ソースを取得。
# wget https://raw.githubusercontent.com/benprew/nagios-checks/master/check_haproxy.rb --no-check-certificate
動作確認。
# ruby check_haproxy.rb -u http://127.0.0.1:1919/haproxy-status -w 80 -c 90

    -u, --url URL                    Statistics URL to check (eg. http://demo.1wt.eu/)
    -p, --proxies [PROXIES]          Only check these proxies (eg. proxy1,proxy2,proxylive)
    -U, --user [USER]                Basic auth user to login as
    -P, --password [PASSWORD]        Basic auth password
    -w, --warning [WARNING]          Pct of active sessions (eg 85, 90)
    -c, --critical [CRITICAL]        Pct of active sessions (eg 90, 95)
    -h, --help                       Display this screen

正常時
$ ruby check_haproxy.rb -u http://127.0.0.1:1919/haproxy-status -w 80 -c 90
HAPROXY OK: 4 proxies found
mysql: UP active mysql1
mysql: UP active mysql2
redis: UP active redis1
redis: UP active redis2
異常時
$ ruby check_haproxy.rb -u http://127.0.0.1:1919/haproxy-status -w 80 -c 90
HAPROXY WARN: mysql: DOWN active mysql2
mysql: UP active mysql1
mysql: DOWN active mysql2
redis: UP active redis1
redis: UP active redis2

あとは、このスクリプトをnagiosに設定しておけばOKです。

New RelicでHAProxyを監視する

Sean Freese Day 115: "Server room bokeh" https://www.flickr.com/photos/seanfreese/6965700818
https://rpm.newrelic.com/accounts/778367/plugins/directory/142
New RelicのHAProxyプラグインです。
Traffic、Sessions、Connection Queue、Denied Requests、Downtime、Errorsといったメトリクスを収集してグラフ化します。

以下、セットアップ方法です。

HAProxyのステータスを取得できるようにしておきます。
# vim /etc/haproxy/haproxy.cfg

#---------------------------------------------------------------------
# stats
#---------------------------------------------------------------------
listen stats 127.0.0.1:1919
    mode http
    stats uri /haproxy-status

# service haproxy reload
# curl '127.0.0.1:1919/haproxy-status?stats;csv'
必須ライブラリをインストール。
# yum -y --enablerepo=epel install gcc libyaml-devel python-setuptools python-pip python-devel
ソースをgit cloneで取得してインストール。
# git clone https://github.com/MeetMe/newrelic-plugin-agent.git
# cd newrelic-plugin-agent
# python setup.py install
# cat /usr/bin/newrelic-plugin-agent
設定ファイルのホスト名を編集。
# vim /etc/newrelic/newrelic_plugin_agent.cfg
  haproxy:
    name: [ホスト名を入力]
    scheme: http
    host: localhost
    port: 1919
  #  verify_ssl_cert: true
    path: /haproxy-status?stats;csv
エージェントをスタート。
# newrelic-plugin-agent -c /etc/newrelic/newrelic_plugin_agent.cfg
ログを確認。
# cat /var/log/newrelic/newrelic_plugin_agent.log
INFO       2015-03-27 14:39:19,485 6590   MainProcess     MainThread newrelic_plugin_agent.agent                   __init__                  L55    : Agent v1.3.0 initialized, Linux-2.6.32-504.3.3.namibuild.el6.x86_64-x86_64-with-glibc2.2.5 (CentOS 6.6 Final) CPython v2.6.6
INFO       2015-03-27 14:39:19,497 6602   MainProcess     MainThread newrelic_plugin_agent.agent                   start_plugin_polling      L263   : Enabling plugin: haproxy
INFO       2015-03-27 14:39:19,519 6602   MainProcess     MainThread newrelic_plugin_agent.plugins.base            finish                    L140   : HAProxy poll successful, completed in 0.02 seconds
INFO       2015-03-27 14:39:19,519 6602   MainProcess     MainThread newrelic_plugin_agent.agent                   send_components           L220   : Sending 15 metrics to NewRelic
INFO       2015-03-27 14:39:20,200 6602   MainProcess     MainThread newrelic_plugin_agent.agent                   process                   L133   : Stats processed in 0.70 seconds, next wake in 59 seconds

New Relicにログインして、プラグインページから確認してみてください。
うまくメトリクスが収集できているでしょうか?