2014年 5月 の投稿一覧

渋谷センター街の入り口にあるお店の油そばを食べました。

VPSの上で複数のLXCを作ってRubyやnode.jsのアプリケーションサーバを動かしたり、DBサーバを動かしたりしているのですが、
稀に「このコンテナでどのくらいCPUが利用されているのだろう？」*1と調べることがあって、その時には

1. 該当のLXCのinitプロセスを見つける
2. そこにぶら下がっているプロセスを確認
3. それらのプロセスがどのくらいCPUを使っているか知る

といったことをやっていたので、その辺りをさっくりできるツールを作ってみました。nodeで作ってます。初npm登録。

lxc-cpu-usage

$ npm install -g lxc-cpu-usage でLXCが稼働しているホストにインストール。

その上でコンテナ名を引数で渡してやるとそのコンテナで動いているプロセスを列挙してCPU利用率を取得してくれます。

例えば、manage001というコンテナが稼働しているのであれば

$ lxc-cpu-usage -n manage001 -v
lxc-cpu-usage - Target LXC:manage001, Target PID:9844
------------------
PID     %CPU
10002    0.01
21669    0.03
(snip)
23340    0.06
23349    0.00
------------------
Processes: 16, CPU usage: 0.16

といった具合で指定したコンテナ内で稼働しているプロセスの一覧とその合計を得ることができます。

誰得感ありますが、コンテナの稼働率見ると、動いているアプリケーションの働いている感を感じられて幸せになれます。

参照

• Github hideack/lxc-cpu-usage

Hubotでcronでスクリプトを定期的に実行させる様に定期的に動かして例えばサービスのパラメータ等を通知させるのはどうするとよいのか調べたのでその際のメモ。

node-cronというnpmパッケージがあるので、これを利用するとcronと同じ書式でスケジューリングすることができます。

以下、REMPチームで利用しているHubotを毎時0分に利用状況を通知させる様にした際の例(を少し変えたもの)です。

cronJob = require('cron').CronJob
module.exports = (robot) ->
new cronJob('0 * * * *', () ->
http = robot.http('http://remp001/****').get()
http (err, res, body) ->
if(!err)
json = JSON.parse body
robot.send {room:'remp'}, "再生回数: #{json.today_play_count}"
robot.send {room:'remp'}, "検索回数: #{json.today_search_count}"
).start()

流れとしてはソースコードそのままですが

1. node-cronで毎時0分に稼働させるジョブを作成
2. REMP に用意しているサービスステータス取得のAPIへGETリクエスト
3. JSONが返ってくるのでparseする
4. Hubotに指定したチャットルームにそのパラメータを喋らせる

これだけ。

こうするとで定期的にHubotを動かしてチャットルームにREMPの利用状況を1時間毎に通知できる様になりました。いままで、こういった通知をちょっとしたスクリプトを書いてcronに登録して通知させたりしていたのですが徐々にHubotに寄せて行こうと思います。

併せて読みたい

• HubotをLingr上で使ってみた http://hideack.hatenablog.com/entry/2014/04/27/151510

hideack/remp_hubot · GitHub

焼鯖定食。

CastoやSTORYBOARDSでnode.js周りのアプリケーションのデプロイをする際にnpm installされる際、稀にnpm自体が重くなっていたりすることもあるので、ローカルにnpmのキャッシュサーバ的なものを立てられないかと調べていたらお手軽にできるものを見つけたので試してみた。

これを立ちあげた上で、

$ npm install --registry http://(npm_lazyを立ちあげたアドレス指定)

とnpmコマンドを実行する際にregistryを指定することで、npm_lazy を経由してnpmコマンドを実行することができます。

npm_lazy自体は、npmを丸ごとキャッシュする訳ではなく、必要とされたライブラリ毎にキャッシュを行うのでキャッシュ期限内のものが手元にあればそれを返し、無ければnpm本体を参照して新たに特定ディレクトリ下にファイルキャッシュを生成するといったプロキシ的な動き方をしてくれるので、特別にキャッシュ用にDBを用意したりする必要もなく気軽に利用できます。

今回、CastoやSTORYBOARDS の場合、VPS配下のLinuxコンテナでそれぞれアプリケーションが動いているので別コンテナにいるmanageサーバと呼んでいるコンテナで npm_lazy を動かしています。

この様な構成で動かすときは npm_lazy の設定を少し変更する必要があるので、設定を修正してそこを参照して稼働させます。

まずは設定用のファイルを出力。

$ npm_lazy --init > ~/npm_lazy.config.js

出力したconfigファイル中の

  // external url to npm_lazy, no trailing /
externalUrl: 'http://10.0.***.***:10080',

  // bind port and host
port: 10080,
host: '10.0.***.***',

辺りを適宜環境に併せて修正した上で npm_lazy を立ちあげます。立ち上げる際に --config を指定して上で修正した設定ファイルを読み込み。

$ npm_lazy --config ~/npm_lazy.config.js

立ちあげた上で、*1

$ npm install --registry http://10.0.***.***:10080/

とすることで、CastoやSTORYBOARDSのアプリケーションコンテナからも手元で立ちあげた npm_lazy を参照できる様になります。

コストパフォーマンス最高の寿司。

4月はあまり本が読めなかった。
インプットが減っているということは、アウトプットもその分減っているということだと思うので、移動時間などに読んでいかなければ。

読書脳 ぼくの深読み300冊の記録
立花隆
読了日：04月19日

ケトル VOL.16
山本兼一
読了日：04月19日

Backbone.jsアプリケーション開発ガイド
Addy Osmani
読了日：04月19日