大層な話じゃないです。

あとfluentdをdissりたいわけでもないです。
使ってみてすごい使いやすかった。すばらしい。
ただちょっとだけ気をつけとかないと、という話。

遭遇した問題

• 前提
  • fluentd-0.10.11(td-agent)
  • アクセスログ(データ不正的な感じ)を複数行まとめて投入してtailで読み込み
  • アクセスログの2行目以降にUTF-8なマルチバイトが含まれる
  • アクセスログをparseしてfileに書き出したい
• 事象
  • 複数行投入したうち、マルチバイトを含む行以降がfileに出力されず
  • ログファイルに元データが出力されず。ログには unexpected error error="\"\\xEF\" from ASCII-8BIT to UTF-8" が出力

どういうこと？

まとめて投入した一連の途中で出力処理がエラーになっていて、以降の処理(=マルチバイトを含む行の次の行以降を出力する処理)が実行されない。

マルチバイトを含む行はエラーとして別の(システム側の)ログファイルにデータをまるっと出力しつつ、次の行以降の出力は継続してほしかった。

んで？

解析データの収集ツールとして使う分にはいいと思います。すごい使いやすいし、解析しやすい。使ってみて感動した。

ただし、現状ではログが消失する可能性があるので、ログ収集という意味合いでは使えないのです。
想定外のログ出力が消失してしまうので、不正アクセスみたいな問題があった時にトレースできなくなっちゃう。

syslogの代替に、って考えてるひとはご注意を(いないかな?)。

とても楽しく、貴重な経験ができていい2日間でした。
金曜20:00に集合して、初日はいきなり23:00頃まで懇親会。
懇親会中にテーマ決め&チーム分けをして、その後はチームごとにひたすら作業。

好きな時に寝て、好きな時に起きるスタイルで翌日18:00までコツコツとがんばりました。

テーマ・チーム決め

テーマは主催さんたちが3つほど用意していましたが、それよりも思いついたやりたいものを優先ということで3チーム中2チームが自由選択でした。
懇親会でワイワイ話してる中でなんとなく気になることが形になってきて、なんとなくその場の流れでテーマごとにチームをつくるという極めてオトナな方法でテーマ・チームが決まりました。

今回は @sguaynさん、@do_akiさん、@yut148さんと4人で「Ruby on Rails or Redmineのプロファイラ作ろうか」って話でスタートしました。
命名:チームますだっく、だったんですが、チーム決めの中で@masudaKさんが移籍流出してしまい名前負けに…(ﾉД`)

ちなみに採用されなかったけど、「WordPressをhiphop対応させる」なんてアイデアも出てました。

紆余曲折

懇親会から帰ったらすぐに作業開始。
なんせテーマがフワフワしてるので、まずは各種言語のプロファイラを調査…してたら眠い…ということでうちのチームは1:00頃に早仕舞。
翌日がんばることにします。

翌日になってみたらみたで、さてどうしましょうという感じ。
最終的には「大事なのはデータのvisualizationだ！」ということで、ログをvisualizeするツールをつくることにしました。
もう思いっきり@kazeburoさんインスパイアって感じ。

このログがメンバー持ち込みのリアルログなもんだから、このあといくつかの問題を引き起こすことに…

ようやっとスタート

最終日の朝にテーマが決まるというスロースターターぶりを披露した我々ですが、アーキテクチャをざっくりと決めて9:30頃(うろおぼえ)には手を動かし始めました。
決めたことはざっくりこれだけ。

• アーキテクチャ: fluentd -> mongodb -> node.js -> JavaScript側でグラフ描画
• 担当
  • ログファイル -> fluentd @netmarkjp
  • fluentd -> mongodb @yut148
  • mongodb -> view @do_aki
  • visualize @sugyan

fluentdはTreasureDataのリポジトリからtd-agentをyumでさっくりインストール。fluent-plugin-mongoも入っててラクチン。
mongodbも10genのリポジトリからyumでさっくりインストール。
node.jsはちょっとよくわからなかったけど、nvmからインストール。 構築超簡単。

自分はfluentdもmongodbもnode.jsもちゃんと触ったことなくてどうなるかドキドキだったけど、簡単でえがった。

決まってからはさすがにみんな手が早くて、色々な問題に遭遇しつつだったけども18:00の締め切りまでになんとか形にすることができました。

↓発生してた諸問題(一部)

• fluentdにencodeできない文字列を渡したとき、複数行まとめて入力してfileに出力していると途中で出力が途切れる(未解決)
  • リアルログならではの「想定外のデータ」が引き起こした問題でした
• fluentd -> mongodbデータ連携してるときに、一気にでかいデータを渡すと buffer_chunk_limit を小さく設定しても Exceded maximum insert size of 16,000,000 bytes のエラーになる(@repeatedlyさんが対応してくれてる)
• highcharts.jsで棒グラフに3分分(3〜4桁くらい)のデータを渡すとブラウザが固まる。折れ線グラフなら大丈夫。(未解決)

18:00で作業終了して、発表会。
みなさんちゃんと形にしてて、やっぱ作れる人はいいね〜と思った次第。

解散した後は有志で月島までいってもんじゃしながら打ち上げしてきました。うまかった！ｗ

まとめ

どうにも締まらない文章で大変申し訳ないんですけど簡単にまとめると、とても充実した2日間(1.5日)でした。
普段なら組めないような人とチームを組んで開発できて、対応とか問題解決の速さに驚くことしきり。とても勉強になりました。
また機会があれば参加したい！

運営のみなさん、お疲れさまでした。ありがとうございました。

今年は地震の影響で考えることが多かった。
地震がきて、いろんなことを「リアルに」感じて考えるようになった気がする。

人生観が変わったひと、変わらなかったひとがいたみたいで、人によってさまざまなのは当然。
自分に限って言うと、人生観はかなり変わったと思う。
体を動かしたり、声を出したり、人と交わったり…身体性の高いことを重視するようになったなぁ。

あと、考えることが多くなった。

考えることの一番は原発かなぁ。

声高に賛成も反対も言えてないけれど、原発怖いなと思ってる。

とても手に負えないものなんじゃなかろうか。

原発止めると経済が…って理屈で原発推進してる人もいるみたいだけど、 その理屈は、実は戦時中の

「米兵につかまるくらいなら玉砕もしくは自決すべし」

とかそういう視野狭窄と同じなんじゃなかろうかとも思っている。

でも判断材料がないんだよなぁ。

いままで自分からは遠い話だった原発のこと、 身近に感じて考えるようになってきた。

IT産業で電気をじゃぶじゃぶ使ってる身だからこそ、 いろいろ考えて行動していこう。

とりとめもないけど、何かの折に思い返すきっかけとして残しておこう。

ちなみに作成した図はアプリケーション構成を表す図です。
厳密に記法など決めているわけではないですが、 トラブルシュートなどのときに大まかな構成を把握するのに使います。

できた図 & wishlist

• ネストしたグループのラベルが重ならないようになってほしい
• ネストしたグループのサイズがきっちりになるので、大きい方は少し余裕をもったサイズになってほしい
• ノード間接続のラベルが重ならないようになってほしい
• ノード間接続のラベルのサイズを自動拡張してほしい(…にならないように)
• apache -> mysqlのところとか、disk -> diskのところとか、ノード間接続で直角線コネクタと曲線が選べるといいなぁ
• ノードの縦サイズをテキスト内容にあわせて自動拡張してほしい(特に改行が入っている場合)
• apache -> diskのところは縦一列にならんでくれるとキレイだなぁ
  • apache -> diskのところを子groupにすることで解決できた！(2012.1.5追記。ソース未反映)

誰かなんとかしてくれないかなぁ。
自分で書けって話かなぁ。時間かかりそうだ。。。

ソース

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

diagram {
 
    internet [shape="cloud"];
    firewall[label="firewall\n(shared)"];
    vip_lb[label="VIP",shape="beginpoint"];
    keepalived_lb01[label="keepalived"];
    keepalived_lb02[label="keepalived"];
    keepalived_lb01 -- vip_lb[folded];
    keepalived_lb02 -- vip_lb[folded];
 
    proxy_web01[label="proxy"];
    apache_web01[label="apache+php"];
    disk_web01[label="disk",shape=flowchart.database];
    proxy_web01     -> apache_web01;
    apache_web01    -> disk_web01[folded];
 
    proxy_web02[label="proxy"];
    apache_web02[label="apache+php"];
    disk_web02[label="disk",shape=flowchart.database];
    proxy_web02     -> apache_web02;
    apache_web02    -> disk_web02[folded];
 
    mysql_db01[label="mysql\n(master)",shape=flowchart.database];
    mysql_db02[label="mysql\n(slave)",shape=flowchart.database];
    mysql_db01  -> mysql_db02[folded,label="replication"];
 
    internet    -> firewall -> vip_lb;
    vip_lb      -> proxy_web01,proxy_web02;
    apache_web01,apache_web02 -> mysql_db01[label="insert/update"];
    apache_web01,apache_web02 -> mysql_db02[label="select"];
    disk_web01  -> disk_web02 [folded,label="rsync"];
 
    group lb_group {
        color="#882222";
        textcolor="#660000";
        shape=line;
        style=dashed;
        label="Clusterd Load Balncer";
        group lb01_group{label="lb01";keepalived_lb01;};
        vip_lb;
        group lb02_group{label="lb02";keepalived_lb02;};
        };
    group production_group { 
        color="#882222";
        textcolor="#660000";
        shape=line;
        style=dashed;
        label="production";
        group web01_group{label="web01";proxy_web01;apache_web01;disk_web01};
        group web02_group{label="web02";proxy_web02;apache_web02;disk_web02};
        group db01_group{label="db01";mysql_db01;};
        group db02_group{label="db02";mysql_db02;};
        };
 
    stg-proxy_web01[label="proxy"];
    stg-apache_web01[label="apache"];
    stg-disk_web01[label="disk",shape=flowchart.database];
    stg-apache_web01    -> stg-disk_web01[folded];
 
    stg-mysql_db01[label="mysql",shape=flowchart.database];
    vip_lb  -> stg-proxy_web01;
    stg-proxy_web01 -> stg-apache_web01;
    stg-apache_web01   -> stg-mysql_db01;
 
    group staging_group { 
        color="#882222";
        textcolor="#660000";
        shape=line;
        style=dashed;
        label="staging";
        group stg-web01_group{label="stg-web01";stg-proxy_web01;stg-apache_web01;stg-disk_web01};
        group stg-db01_group{label="stg-db01";stg-mysql_db01;};
        };
 
    }

今日はさらにコアなネタに。

みなさん、シリアル通信することってありますよね？
ネットワーク機器に接続して設定したりとか、とかとか。

そんな時にもscreenが使えちゃうんです。 ちなみに私はMac(MBA Snow Lepard)で使ってます。

screenでシリアル接続する

1. ケーブルをつなぐ。最近はUSBタイプのものですね。ドライバとかは入れておいてください
2. screenでつなぐ

たとえば、USB接続のシリアルが /dev/tty.usbserial に接続できた場合は下記のように接続します。
※Ctrl-aではなくCtrl-zの場合

screen -e ^z^z  /dev/tty.usbserial 115200

xmodem転送する

ネットワーク機器のファームウェアアップデートのために、xmodem転送でデータを送信したいことってありますよね！
そんな時にもscreenでうまいこといけちゃうんです。

step0. lrzszをインストール

準備は簡単。brewでlrzszをインストールしておきましょう。

brew install lrzsz

では使ってみましょう。

step1. 接続する

上にかいてありますね。 ここでは特別なことはありません。

※Ctrl-aではなくCtrl-zの場合

screen -e ^z^z  /dev/tty.usbserial 115200

step2. 転送する

※Ctrl-aではなくCtrl-zの場合(しつこいかな)

Ctrl-z
:exec !! /usr/local/Cellar/lrzsz/0.12.20/bin/lsx -kb /Users/baba/Desktop/firmware.img

※パスとかは適宜読み替えてください！

・・・とまぁこんな感じで、懐かしのxmodem通信もできちゃいます。
xmodem通信とか、パソコン通信時代に◯☆△◇な画像をダウンロードする時にしか使った記憶がないんですが、 知っておいて損はないと思います。
得があるかはわかりませんが気にしたら負け。

ノリと勢いでAdvent Calendarしたくてそのためにblogを移設したんだけど、 実はそんなにネタなかったりして。

と、いうわけで、今回は手持ちのtipsを紹介します。

その1. ログインしたら自動でscreen

.bashrcに自動でscreenが起動するように仕込めば、 今日からあなたもとても自然にscreen使いになれちゃいます。

自動screenデビューしたい？ そんなあなたは↓のコードを .bashrc に書きましょう。

if [ $TERM != "screen" ]; then
    if [ $TERM != "dumb" ]; then
        screen -e ^z^z
    fi
fi

ポイントは次の2つ。

1. 無限ループしないように、 $TERM が screen の時はscreenを起動しない
2. SCPが使えるように、 $TERM が dumb の時はscreenを起動しない

その2. 画面がチラチラするのが嫌！

screenでは、TAB連打で候補を出す時などにaudio bellの代わりにvisual bell(画面がチカチカする)が発動します。 でも、visual bellって画面チカチカするしすんごい見づらいですよね。 そんな私に共感してくれるあなたは ~/.screenrc に↓を書くと幸せになれるかもしれません。

vbell off

その3. 敢えて hardstatus を使わない

~/.screenrc に、頑張って hardstatus 云々って書くと、 画面上に時計やらウィンドウ一覧やらを表示できるんですよね。

これがまたカッコいい。 サイバーな感じで、こうなんというか、ハッカーっぽい！

でも私は、敢えて hardstatus を使わないのがお勧めです。

例えばMySQLで show table status した場合、 横幅広すぎでTerminal上では見づらいので、 手元のエディタにコピペしたくなりますよね。

そんな時も hardstatus を使っていなければ安心。 ターミナルソフト(MacならTerminalやiTerm)のスクロールバーを利用して少しだけ楽をしましょう。

なんとスクロールバックすれば出力がまるまる残っているではありませんか。 この出力をターミナルソフトの機能でコピーしてあげればokです。

データの移行はとても簡単。
ちゃんとパーマリンクも保持できます！

1. [MT] MTの管理画面からExportでデータをファイルで出力
2. [WP] 設定＞パーマリンク設定 をカスタム構造の /%year%/%monthnum%/%postname%.html に設定
3. [WP] プラグインのMovable Type and TypePad Importerをインストール
4. [WP] ツール＞インポート から1.で出力したファイルをアップロード
5. [WP] MySQLに直接ログインしてパーマリンク修正
6. [WP] Analyticsのtop30くらいを見て、不具合がないか確認。見栄えを適当に修正

※パーマリンク修正方法

$ mysql -u <WP_DBUSER> -p <WP_DBNAME> -h <WP_DBHOST>
mysql> UPDATE wp_posts SET post_name = REPLACE(post_name ,'_','-');

サーバ設定

以下はデータ移行には関係ないけど・・・

今回は思うところがありフロントにnginx、バックにapacheをおいて、 apache側でwordpressを動かしてます。 そんなわけでちょっとだけ設定をメモ。

nginx

server {
    listen       80;
    server_name  netmark.jp *.netmark.jp;
 
    access_log  /var/log/nginx/log/netmark.jp.access.log  main;
 
    location / {
        proxy_pass   http://localhost:8002/;
        proxy_set_header        Host            $host;
        proxy_set_header        X-Forwarded-For $remote_addr;
    }
}

apache

UseCanonicalName On
Listen 8002
<VirtualHost *:8002>
        ServerName  netmark.jp:80
</VirtualHost>

これで今んとこうまく動いてます。

去る10月1日に実施された、tuningathon #2に参加してきました。

結果は5位!。前回よりもランクダウン。。 でも入賞できてよかったですよ。

今回はあまりたいしたことはできず、 1位の方のアプローチは「無理」と判断してハナからあきらめちゃってたので、 判断力と決断力がもっとあれば、結果は違ったのになぁと悔しいこと悔しいこと。

自分が実施したことは、入賞された方々とあまり変わらず。。

1. php5.4をCFLAGS="-O2 -march=core2" でソースインストール
2. apacheのログ出力停止と並列数調整
3. mysqlのquery_cache on と innodb_buffer_pool_size 調整
4. cherokeeのサイトに書いてあるOSチューニングを少々

くらい。今回もあからさまにphpのcpu boundだったので、 前回のようにfastcgi化を目論むも、リライト回りがうまく動かせず失敗。 正直なところ、15時くらいにはすでに手詰まり感がでてて、 ちょっと不完全燃焼でした。

あと、今回は測定ツールが自作になっていたので最後まで不安だったな。 上位入賞者の弁を聞いて、@methaneさん相変わらず深いなぁとか、 いろいろとまだまだ修行しなきゃって感じがしてとても楽しくて有意義でした。 つーかKlab強ぇぇ。

開催していただいたゼロスタートさん、技術評論社さん、Amazonさん、Voyage groupさん、 ほんとうにありがとうございました!

毎度思うんだけど、上位に入るためのアプローチと1位になるためのアプローチはあからさまに別で、1位になるためにはちょっとドラスティックなこともしないとならないんだよね。

次回は上位ではなくて、all or nothingで1位を狙ってみたいなと思った次第。

@karakaniさんに2連敗中なので、次こそは勝つ! あと、チャラいキャラの人には負けない! (いじりすぎてゴメンね。楽しかったの)

チーム名は2秒くらい考えてこんなものしか思いつきませんでした。

チーム名を決めなければならないということに気づいたのは、要返信のメールの締切を2日過ぎてからのことでした。相談なしに決めてゴメン。。。

ともあれ結果は2位 3位。1位とは大差！2位とは僅差！すごくすごく楽しかったです。

主催のライブドアさん、ありがとうございました！

さて、今回も結果が出てほっとしました。 今回はチームメイト @matsuu さんがすでに詳細書いてくれているのでそちらを見ていただくと紆余曲折を感じていただけるかと。
→isuconに参加してきた＆チーム「いんふらえんじにあー」の戦略など – それ、Gentooだとどうなる？

自分的なポイントだけ挙げてみます。

• 今回もtuningathonと同じアプローチ(計測→ボトルネック発見→対応)で一定の成果を出せてよかった！自信ついた！
• 仕込みネタのうち、いくつかを当日忘れてたのが痛い まぁでも時間的余裕はなかった
• starmanやらplack初見で、やりたいことは明確なのにうまく実現できず。plackをfcgiで動かせず、タイムアップ悔しい (できたらスコア倍くらいになったかもしれないという期待を込めて)
• アグレッシブにコンテンツ部分に手を入れるアプローチは自分の中になかった(普段の役割分担的にそのアプローチはとらないので頭から外してしまっている)ので、とても刺激的だった
• SELinuxがONでも、運用者がいればちゃんと動くし、パフォーマンスは出るんだよ！ だってボトルネックはSELinuxじゃないもん
• 最短時間で最初の壁を越えられた時は嬉しかった。余裕ぶっこいて悠長に昼飯食ってる場合じゃなかった。でも海鮮丼うまかった

今回のお題で特に印象的だったのは、アプリケーションとインフラの全部を総合的に見られないと、問題発見→解消のサイクルが回せないこと。 よく練られたいいお題だと思います。

測定・一覧機能の作り込みもとても素晴らしく、楽しく遊ばせてもらいましたｗ

command

sudo vim /Library/Python/2.6/site-packages/docutils/languages/__init__.py

※18行目を書き換え

before

18

def get_language(language_code, reporter):

after

18

def get_language(language_code, reporter=None):