OS構築後、期待された内容で構築されているかどうかをカジュアルにテストするOpsToolsとして、chefのテストケースをつくった話


ChefでOSの設定に誤りがないかを確認するテストレシピを書きました。

https://github.com/kenjiskywalker/cookbooks-test

ソース読んだら誰でもわかります。
わかるっていうか、こうやって書けばいいのかって。

@fujiwaraさんと相談してつくりました。
@fujiwara++ シンプルでわかりやすいのすごい良いですよね。


取り敢えずインスピレーションとして、みなさんの刺激になればいいなと思って
雑な状態ですが、アップロードしました。

ChefはRubyでできてるのでRSpecや、Cucumber-chefを利用するのが良さそうですが、
Cucumber-chefAWSありきで、少なくともうちは当てはまらなかった。
RubyのテストならRSpecだろうとも思ったのですが、recipeをささっとできた方が良くない?
という感じで、上記レシピのようにカジュアルにテストをしております。

テストといっても、上記レシピでテストをしているのは
期待されたOS情報(YAMLファイル)の各種設定と、
実サーバを比較しているだけのお手軽レシピです。

プロセスの確認などについては、Zabbix先生がいるので
OSの基本的な内容だけchefで監理するかたちです。


今後運用していくにあたって、どんどんテスト対象は増えていくと思いますが、
基本的Rubyでカジュアルに書けるので、chef素晴らしいって感じです。

最近OpsToolsでもテストが必要だって話は良く聞くんですが、
いざどうやっているのかっていう具体的な話はあまり聞かないので
みなさんどうやって運用しているのか教えてほしいです。

( '-')'-')

PostfixでSMTP Relayで外に出るIPを固定する設定

ブログだけじゃなくて
Qiitaに書いてブログにQiitaのURL載せるの意識高い感じする。

PostfixでSMTP Relayで外に出るIPを固定する設定

ブログ拝見しました。とかメール頂いて
ああ、そうか。来世がもしあったら
ボクは庭師になりたいのかもしれない。とか思った。

朝礼とか勉強会とかの内容を社外に公開することで

会社って業績よりも何に気付いて、何をしているのかが大切なんじゃないのかなー
っていうのは「人の成長は、未熟な過去に打ち勝つこと」でも書いたんですけど
その話の延長線的な話を。

今働いてる会社は、個性が強いからそういうのが好きで入ってきている人がほとんどだろうけど、
日頃朝礼をやっていて、どこの会社も朝礼のひとつやふたつはやっていると思うんですけど、
その朝礼で「良い話」みたいなの話しているところって結構多いと思うんですよ。

で、実際その「良い話」って本当に良い話が多くて、これグループ内だけで終わらせるの
すごいもったいないなーって。

例えば毎日朝礼の内容を社外に毎日アウトプットすることで、その「良い話」を読んだある人が
この人と一緒に仕事がしたい!!!って思うかもしれないし、そういう日頃の社員の「良い話」みたいなの
ベンチャーキャピタルみたいな人がチェックしてて、ここの会社の社員は日頃から良い気付きをしている。
今後発展する可能性がある。とかわかるかどうかは定かではないですが、見えない部分を見る何かしらの指標にはなるのかなって。

結局会社って、たくさんのひとたちがたくさんのひとたちと一緒になにかをつくったりしているだけであって、
その今そこにいる人たちが日頃どんなことに注目して、どんなことに気付いて、どんな判断をして
生活をしているのかっていうのは、会社に入って半年してやっとわかるぐらいで

例えばある人が期待して入社したけど意識高い人は数えるばかりで、
その他大勢はどうしようもない人たちで、その数えるばかりの人だけで
この会社は持ってるんだなとかっていうのも、中に入って
ある程度の月日が経ってようやく見えてくるものではないかと。

よくあるのが、大きな会社に入ったんだけど、イノベーション起こした人はみんなもう辞めてて
何も生み出さないような人たちがゴロゴロしている、後は滅びるのを待つだけの会社とか。

売り上げはあるんだけど、どうも思考が宗教がかってて危ないな。とか。

あんまり大きな会社じゃないけどみんな楽しそうに毎日すごしているな。とか。

ここの社員は全員こんなに意識高いのか。ちょっと遊びに行ってみたいな。とか。

そういうものに対して、日頃から朝礼の「良い話」の内容とか
社員がどういうことをしているのかっていうのを、もう少しオープンにすることで
色々外の人でも見えてくるものがあるんじゃないかなーって思う。

もちろんすっぽんぽんになることが全て是ではないだろうけど、
少なくとも何かのきっかけにはなる可能性はあると思う。

ということを思ったメモ。

わたしが今いる会社の朝礼は外に出したいですね。

branchを並行運用しなければいけない場合の共存方法。cherry-pickの選択

chefを使っていると、案件毎とかサーバ毎で微妙に設定が違うところがあると思うのですが
これは git で設定ファイルを管理して branch で案件とかサーバとかを切り分けるという運用方法をとっていまして
そうするとひとつ困ることがあって


main -----+
|
branch a +------ アカウントの追加 ---------- ミドルウェアの微調整-- ---------------------------->
|
branch b +-------------------- DBサーバの仕様変更 --- MySQLの設定変更 --- !!イノベーション!! --->
|
branch c +--- 案件Cの仕様設定 --------------------------------------------------------------->

日々運用していると、イノベーションが起こって、これってこの案件ブランチにかぎらず
全体的に反映したいなーという時が最近よくあるのです。

その解決方法としてなにか良い方法ないかなー。ってマニュアル読んでいたら
cherry-pickを使って、その
イノベーションが起きたコミットだけブランチ毎に持っていくるという使い方があって、
これでブランチ毎に反映させるのがいいのかなーと思ったりしています。

え、そんなダサい方法じゃなくてもこれやればいいじゃん?
みたいなハウツーあったら教えて頂ければと思います!

Perl歴半年の3人が #isucon2 に参加してディフェンディングチャンピオンを倒そうと思った話

#isucon2 参加者・関連エントリまとめ

運営の方々、@kazeburoさん、@tagomorisさん
お疲れ様でした!とても楽しく参加させて頂きました!

優勝が前回覇者のチームfujiwaraということで、やれやれですね。

@fujiwaraさんと席を並べて半年経ったのかな。

インフラチームとして2人で仕事をするようになり、
同じサーバを見て、同じメトリクスを確認し
同じアラートを受け取り、同じ課題を見てきていました。

暁美ほむらがよく軍隊なら一個中隊規模の軍事力があるという話がありますが、
@fujiwaraさんは一国の軍隊ぐらいのパワーを持っているんじゃないかって思います。

サービスエンジニアが書いたコードをチェックし、アドバイスを行い、
スイッチやLANケーブルの配線を行い、ネットワーク構成を考え、
アプライアンスのロードバランサを設定し
ボトルネックを瞬時に判断し、誰よりも早くアラートに対応する。

簡単に言えば、Webサービスに必要なものはなんでもできるんです。
しかも全て、迅速かつ丁寧に。

事実として、みなさんがヤバいなって思ってる数倍ヤバいんです。

で、どうしてそんなスーパーな神になれるのかなーって考えると

 - 誰よりも責任感を持って仕事をする
 - 誰よりもその事象に対して正確に理解しようとする

この2点が大切なのではないかなーと、そばにいて思います。

え、もうこのアラートウザいんで止めちゃってよくないですか?
え、単純にこれが解決すればいいんじゃないんですか?

みたいに思考停止すると、それ以上の技術の発展はなくなって
いかにして課題に誠実に技術力で向き合うかってところが
技術力の向上に繋がるのではないかと思います。

私は結構雑なので、興味あるものには必要以上やるのに
興味ないと全然手を動かさなかったりするのがあって、
本当にそういうところは見習わないといけないなーと、今書いてて反省しております。

@fujiwaraさんみたいになりたい人がいたら、
多分@fujiwaraさん本人にどうしたら良いですか?って聞いたら
丁寧に教えてもらえると思うので、聞いてみてください。

カヤックでは毎週金曜日に勉強会やってて、
その後毎週馬車道で美味しいクラフトビール飲みに行ってるので
遊びに来て頂いてもオッケーだと思います!


これだけヨイショしておけば席がなくなってることは避けられるかな。。。



ということで、ここからは#isucon2でやったことの言い訳を書きたいと思います。



まず、社内にはディフェンディングチャンピオンのメンバー2人(@songmuさん、@fujiwaraさん)がいて
社内IRCで一緒のチームで出たい人いますかーという応募があったのですが、
@fujiwaraさんと同じチームになってもあんまり面白く無いかなーと思って、
同じ中途でC++erのレモンさんと、新卒でリードエンジニアやってるPythonistaのマコピーと出ました。

結果的にディフェンディングチャンピオン@typesterさんが入るという
他社のみなさまには申し訳がないぐらいの本気チームができてしまいました。

本当は変態天才マッドエンジニアのtaroさんっていう人がいて、レモンさん
3人で出ようかなって考えたんですけど、多分斜め上すぎるメンバーでダメだな
ということでマコピーを加えた3人で参加しました。

全員Perl歴半年以内で、かつ私に至ってはプログラムをまともに書いたのが
ここ半年なので、なかなかどうしてなメンバーでしたけど、試みは面白かったのかなーと思います。

やったことを過剰書きに

= けんじすかいうぉーかー=
  環境整備

  o ssh
     - ポートを22に戻す
     - Rootログインの許可
     - Rootを鍵認証でログインできるように設定

  o .bashrc
     - hostnameが覚えづらかったので
       PROMPTの表示を「proxy」、「app01」、「app02」、「db01」と表示するように変更
     - alias
       aa = ap01にログイン
       ab = ap02にログイン
       db = db01にログイン

  o iptables off

  o SELinux off

  o MySQL
     - slowquery の出力設定
     - noindex の設定
     - 取り敢えず innodb_buffer_pool_size = 12G <= 安易な設定変更、ダメ、ゼッタイ 
= レモンさん、マコピー =

DB周りを確認。軽いDBだと判明。これもう全部Redisに書き換えたらいいんじゃね?
全員賛成。レモンさんが書きなおす

= けんじすかいうぉーかー =

取り敢えず全台にRedis入れる。

Apacheがただ裏のAPサーバに渡してるだけだってわかったけど
取り敢えず

Apache -> nginx

に変更。ベンチ走らせても特に変化なし。
静的ファイルだけnginxで返すようにしたら多少スコア上がるも
根本的なボトルネック解決にはならず。
取り敢えずレスポンスタイムを取得できるようにログファイルを修正。

側だけだと特にやることなくなったので、nginxの前に
Varnishを置いて、そこから直接アプリに向けたら

Varnish <=> Redis

で最強じゃない?という案が思いついたので、Varnishを設置する。
取り敢えず一切細かい設定入れないでベンチマークを走らせ

ブラフのスコアを叩きだす。爆笑してたら@tagomorisさんがやってきて
それちゃんと動いてないよね。という正確なツッコミを頂く。

もしかしたら動かす機会があるかもと、動かした際にローカルポートが枯渇しそうだったので
net.ipv4.tcp_tw_recycle = 1 と net.ipv4.tcp_fin_timeout = 10 を設定。
50000ぐらいTIME_WAITがあったのが130前後まで減ったので、設定次第では使えるようになった。
TTLを1sにしてうまいこと回避できないかと思ってやってみたが、どうもコケてしまった。
この辺もちゃんと全体を見てないので後回しにした。


レモンさんが書き終えるまで時間があるのでnginx-lua-redisとかで
コンテンツもオンメモリで返せないかなーとか思いながらVarnishのドキュメントを読む。
Varnishも2系と3系で偉い設定が変わるので、付け焼刃には厳しい状態だった。

マコピーと

nginxのログを見て、ボトルネック箇所を特定する。
テンプレートの生成に時間を食っているのも確認。


最終的に、最悪でも静的ファイルのJSとCSSとJPGぐらいはVarnishで返せるようになった。

しかし、MySQLをFull Redisに書き換える前にタイムアップした。

失敗したところ
  • 必死すぎてみんながみんなのアラートを共有できなかった
  • 役割分担が上手くできず、レモンさんがずっとコードを書いている状態だった。
  • 来週末報告会やるよってさんざん話してて、fujiwara組とIRCのログ照らしあわせようって決めていたのに

 実際は大声で大爆笑しながら口頭でやりとりしててまともにログが残ってなかった。

よかったところ
  • 楽しくできた


MySQLをRedisで丸めるっていうのは方法的には面白い発想であったので、完走させたかった。
完走させても、@typesterさんが実際にボトルネックの部分をMySQLからRedisに変更しているので、
チームfujiwaraに勝てるスコアではもちろんなかったと思う。

ボトルネックを改善するよりかは、再実装でタイムアップしてしまったので
ちょっと悔しい。ちょっとではなく無茶苦茶悔しい。

Varninshは業務で使ってないけど、ESIとか利用すればそこそこ面白いスコアが出たのではないかと思った。


という感じで日頃の業務+Varnishな感じでしたが、
完走することができず悔しかったです。

懇親会はレモンさんがシャイだったので、あまり多くの方とお話しできなかったのが残念でした。
あと、優勝おめでとうボードはレモンさんが会社に持って行ってくれたので、どこかに飾りましょう。

そして、社内のエンジニアでインフラチームに入りたい若者は上司にかけあってみると良いかもしれませんね。

ということでみなさまおつかれさまでした!
最高に楽しい週末でした!

週明けにわたしの席が残っていることを祈っていてくださいね!

( ◔_◔)

chefのログ出力を制限する方法 / 劇的ビフォーアフター ver.0.10.6+ (verbose_logging)

chefのログが出すぎだなー、実際これ影響あるのかないのか
出力結果見るのにターミナルでスクロールバックしないといけないし
これだけの出力されたログの中で、影響があるのかないのか、ひとつひとつ
grep警部してたら取りこぼし多そうだなー

やだなやだなー、こわいなこわいなー

と思ってたんですが


Chef 0.10.6 Released

「optionally disable the verbose logging」という表記があるじゃないですか!!


リンク先を覗くと

The "processing" INFO message for every resource on a normal run looks nice but is probably too verbose. 
The messages are great if you're running chef-client in your terminal and want to know whats happening, 
but will fill up logfiles with unnecessary cruft. Also, using knife ssh will cause an explosion of ASCII proportions.

おお、そうなんだよ!!Processingはバーボスなんだよ!!
本当にほしいログってのはサーバに影響を及ぼしだログだけで
他のログはそんなに必要じゃないんだよおおおお!!!

わかるぜブラザー!!よっしゃ!
取り敢えずはコミット内容を見てみよう!!!

https://github.com/mdkent/chef/commit/c96ca45f1bc0cdb45925890f161847d680ae2fd7

( ◔౪◔) ?

ちょっと意味がわからない。。って思ってたらなんと

Chef Configuration Settings

ドキュメントに載ってました。

verbose_logging set to true or nil

verbose_logging set to false
In Chef 0.10.6+, setting verbose_logging to false

これか!! verbose_logging set to falseッッ!!


ど、どこに書いたらええんや!!!
どこなんやああああああああああああああああああああ!!!

と、血眼になって探したのですが
上記マニュアルの上の方に書いてありますね。

 chef-solo なら /etc/chef/solo.rb  
 chef-client なら /etc/chef/client.rb

ということで、うちは chef-solo を利用しているので
早速 /etc/chef/solo.rb に 「verbose_logging false」を記入して実行してみましょう

before



after

beforeの内容 (一部消しております)

[root@eto-server chef]#
[root@eto-server chef]# chef-solo -c config/solo.rb -j config/self.json
[2012-10-31T18:16:58+09:00] INFO: *** Chef 10.16.0 ***
[2012-10-31T18:16:58+09:00] INFO: Setting the run_list to ["zabbix", "nginx"] from JSON
[2012-10-31T18:16:58+09:00] INFO: Run List is [recipe[zabbix], recipe[nginx]]
[2012-10-31T18:16:58+09:00] INFO: Run List expands to [ne, ushi, tora]
[2012-10-31T18:16:58+09:00] INFO: Starting Chef Run for eto-server
[2012-10-31T18:16:58+09:00] INFO: Running start handlers
[2012-10-31T18:16:58+09:00] INFO: Start handlers complete.
[2012-10-31T18:16:59+09:00] INFO: Processing tem
[2012-10-31T18:16:59+09:00] INFO: Processing tem
[2012-10-31T18:16:59+09:00] INFO: Processing tem
[2012-10-31T18:16:59+09:00] INFO: Processing fil
[2012-10-31T18:16:59+09:00] INFO: Processing fil
[2012-10-31T18:16:59+09:00] INFO: Processing pac
[2012-10-31T18:16:59+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing gro
[2012-10-31T18:17:04+09:00] INFO: Processing gro
[2012-10-31T18:17:04+09:00] INFO: Processing gro
[2012-10-31T18:17:04+09:00] INFO: Processing gro
[2012-10-31T18:17:04+09:00] INFO: Processing use
[2012-10-31T18:17:04+09:00] INFO: Processing dir
[2012-10-31T18:17:04+09:00] INFO: Processing fil
[2012-10-31T18:17:04+09:00] INFO: Processing use
[2012-10-31T18:17:04+09:00] INFO: Processing dir
[2012-10-31T18:17:04+09:00] INFO: Processing fil
[2012-10-31T18:17:04+09:00] INFO: Processing use
[2012-10-31T18:17:04+09:00] INFO: Processing use
[2012-10-31T18:17:04+09:00] INFO: Processing dir
[2012-10-31T18:17:04+09:00] INFO: Processing fil
[2012-10-31T18:17:04+09:00] INFO: Processing use
[2012-10-31T18:17:04+09:00] INFO: Processing dir
[2012-10-31T18:17:04+09:00] INFO: Processing fil
[2012-10-31T18:17:04+09:00] INFO: Processing use
[2012-10-31T18:17:04+09:00] INFO: Processing dir
[2012-10-31T18:17:04+09:00] INFO: Processing fil
[2012-10-31T18:17:04+09:00] INFO: Processing gro
[2012-10-31T18:17:04+09:00] INFO: Processing pac
[2012-10-31T18:17:04+09:00] INFO: Processing tem
[2012-10-31T18:17:04+09:00] INFO: Processing tem
[2012-10-31T18:17:04+09:00] INFO: Processing tem
[2012-10-31T18:17:04+09:00] INFO: Processing fil
[2012-10-31T18:17:04+09:00] INFO: Processing ser
[2012-10-31T18:17:04+09:00] INFO: Processing ser
[2012-10-31T18:17:04+09:00] INFO: Processing ser
[2012-10-31T18:17:05+09:00] INFO: Processing ser
[2012-10-31T18:17:05+09:00] INFO: Processing ser
[2012-10-31T18:17:05+09:00] INFO: service[nginx]
[2012-10-31T18:17:05+09:00] INFO: Processing ser
[2012-10-31T18:17:06+09:00] INFO: service[nginx]
[2012-10-31T18:17:06+09:00] INFO: Processing ser
[2012-10-31T18:17:06+09:00] INFO: Processing ser
[2012-10-31T18:17:06+09:00] INFO: Processing ser
[2012-10-31T18:17:06+09:00] INFO: Processing ser
[2012-10-31T18:17:07+09:00] INFO: Processing ser
[2012-10-31T18:17:07+09:00] INFO: Processing ser
[2012-10-31T18:17:07+09:00] INFO: Processing ser
[2012-10-31T18:17:07+09:00] INFO: Processing ser
[2012-10-31T18:17:07+09:00] INFO: Processing ser
[2012-10-31T18:17:08+09:00] INFO: service[nginx]
[2012-10-31T18:17:08+09:00] INFO: Processing ser
[2012-10-31T18:17:08+09:00] INFO: service[nginx]
[2012-10-31T18:17:08+09:00] INFO: Processing exe
[2012-10-31T18:17:08+09:00] INFO: Processing tem
[2012-10-31T18:17:08+09:00] INFO: Processing coo
[2012-10-31T18:17:08+09:00] INFO: Processing lin
[2012-10-31T18:17:08+09:00] INFO: Processing tem
[2012-10-31T18:17:08+09:00] INFO: Processing pac
[2012-10-31T18:17:08+09:00] INFO: Processing tem
[2012-10-31T18:17:08+09:00] INFO: Processing ser
[2012-10-31T18:17:08+09:00] INFO: Processing ser
[2012-10-31T18:17:09+09:00] INFO: Processing pac
[2012-10-31T18:17:09+09:00] INFO: Processing ser
[2012-10-31T18:17:09+09:00] INFO: Processing ser
[2012-10-31T18:17:09+09:00] INFO: Processing tem
[2012-10-31T18:17:09+09:00] INFO: Processing tem
[2012-10-31T18:17:09+09:00] INFO: Processing dir
[2012-10-31T18:17:09+09:00] INFO: Processing tem
[2012-10-31T18:17:09+09:00] INFO: Processing coo
[2012-10-31T18:17:09+09:00] INFO: Processing coo
[2012-10-31T18:17:09+09:00] INFO: Processing coo
[2012-10-31T18:17:09+09:00] INFO: Processing tem
[2012-10-31T18:17:09+09:00] INFO: Processing tem
[2012-10-31T18:17:09+09:00] INFO: Processing tem
[2012-10-31T18:17:09+09:00] INFO: Processing pac
[2012-10-31T18:17:09+09:00] INFO: Processing bas
[2012-10-31T18:17:09+09:00] INFO: Processing fil
[2012-10-31T18:17:09+09:00] INFO: Processing pac
[2012-10-31T18:17:09+09:00] INFO: Processing pac
[2012-10-31T18:17:09+09:00] INFO: Processing tem
[2012-10-31T18:17:09+09:00] INFO: Processing ser
[2012-10-31T18:17:09+09:00] INFO: Processing ser
[2012-10-31T18:17:09+09:00] INFO: Chef Run complete in 10.76644 seconds
[2012-10-31T18:17:09+09:00] INFO: Running report handlers
[2012-10-31T18:17:09+09:00] INFO: Report handlers complete
[root@eto-server chef]#

afterの内容

[root@musashi chef]# chef-solo -c config/solo.rb -j config/self.json
[2012-10-31T18:13:56+09:00] INFO: *** Chef 10.16.0 ***
[2012-10-31T18:13:57+09:00] INFO: Setting the run_list to ["zabiix", "nginx"] from JSON
[2012-10-31T18:13:57+09:00] INFO: Run List is [recipe[zabbix], recipe[nginx]]
[2012-10-31T18:13:57+09:00] INFO: Run List expands to [zabbix, nginx]
[2012-10-31T18:13:57+09:00] INFO: Starting Chef Run for eto-server
[2012-10-31T18:13:57+09:00] INFO: Running start handlers
[2012-10-31T18:13:57+09:00] INFO: Start handlers complete.
[2012-10-31T18:14:04+09:00] INFO: service[nginx] disabled
[2012-10-31T18:14:04+09:00] INFO: service[nginx] stopped
[2012-10-31T18:14:06+09:00] INFO: service[nginx] enabled
[2012-10-31T18:14:07+09:00] INFO: service[nginx] started
[2012-10-31T18:14:08+09:00] INFO: Chef Run complete in 10.505194 seconds
[2012-10-31T18:14:08+09:00] INFO: Running report handlers
[2012-10-31T18:14:08+09:00] INFO: Report handlers complete
[root@musashi chef]#


影響があったものだけが出力されるようになる。

It's very simple!!

ということで、他のアップデート内容は確認していませんが
このログ出力制限のためだけでも chef を 0.10.6 にアップデートしても良いなと思いました。

Why-runも使えるし、0.10.6、なかなか良いですね。

fluentdドキュメント日本語版 (Overview)

このエントリは「ウィークリーFluentdユースケースエントリリレー」への参加記事です。

隣の席のfujiwaraさんを横目で見つつ、使いたい使いたいと思いながらも
fluentdをちゃんと使ったことがないので、ユースケースは書けません。

なので、「fluentdドキュメント日本語版とか有志で作っていいですか!?」というoranieさん、
最近めっきり姿を見なくなってしまったoranieさんの願いを叶える為というか、
これから使ってみたいなという人に向けて、fluetndは使い勝手は素晴らしいのですが、
いかんせん英語ドキュメントしかないのがなー、というエントリーな方向けに、
日本語版を書いてみました。書いてみましたといっても
Overviewのページだけですが!!!

Gist:http://fluentd.org/doc/overview.html の日本語翻訳 (Overview)

次に誰かが乗っかってくれることを切に祈っております;;

仕様を全て理解しているわけでもなく、英語が読めるわけでもなく
グーグル翻訳と中学生までの英語力を駆使したつたないものなので
Treasure Data社のみなさま様、fluentd使いのみなさま、英語マスターのみなさま、日本語マスターのみなさま
ご指摘などなどお待ちしております!!!