fluentdとシステム設計の小ネタ - たごもりすメモ
あるいは http://yugui.jp/articles/879 へのreply。 システム監視をfluentdに統合してしまうべきか否か システム監視は分けておいた方がいいと思う。分けるべき、とまでは言わないけれど。 それらの仕組みには相応の必要な機能セットがあり、それらは長い歴史の中で比較的決まった機能セットに収斂してきており、その収集・モニタリング・可視化・アラート通知など決まりきったパターンを様々な項目について停止なく行う必要がある。 Fluentdの各種プラグインを用いることで同じような機能は実現できる。そのプラグインのうち数割は自分が書いものだったりする。とはいえ各ホストのシステム監視までそこで行うことを想定して書いたかというと、もうちょっと高いレイヤでの監視・集計、つまりサービス単位などを目的としたものが多い。サーバ単位で行おうとしたときに設定が雑多なものになるのはおそらく
DISられないUIを作るために最低限守るべき5つの鉄則 - たごもりすメモ
ぼくらが迂闊にUIを作ると、そこにはユーザの正直な目線があり、非常に様々な、そして真っ当な反応がある。 曰く「わからん」「まさかそこをクリックするとは」「不思議な動作」「独自宇宙」「モリスUI」。 反応がもらえるのは非常に良いことだが、何度も何度も繰り返しているとつらくなってくるので、できれば避けたい。分かっている(いた)ことは最初から対応しておきたいものだ。*1 ということで、ここではブラウザで操作する管理画面等のWebUIを作るとき、真っ先に心得ておくべき5つの鉄則を紹介したい。これを守っていてもDISられなくなるというわけではないが、これを守らないと間違いなくDISられるので注意しよう。 なおこの記事ではオリジナリティというものについては考慮しない。オリジナリティとか犬に食わせろ。 クリックできる場所はcursor:pointerを指定しろ これを忘れるとこの世のものとは思えないくら
自家製 td-agent のrpmをつくる - たごもりすメモ
自社サービスの運営のために fluentd を使っているとrpmでインストールできる td-agent が大変便利だ。 便利だが、自社内で使うんだから、もう最初から自社用の設定とかその設定に必要なプラグインとか入っててほしい。そんで yum install td-agent をサーバ上で実行したら設定とかいじらないでいいようにしたい。みんなラクをしたいでしょ！？ もちろん td-agent のリポジトリをforkしてあれこれ手を入れればできるが、そうするとその後のメンテナンスが面倒だ。リポジトリ自体のアップデートはTreasure Dataの人に頑張っていただいて、我々は spec をいじる程度に収めておきたい。みんなラクをしたいよねー。 した いろいろと td-agent のビルドスクリプトに手を入れる必要はあったが、もうその修正は当たっているのでみなさんは以下の手順を実行するだけでよろ
FluentdでバッファつきOutputPluginを使うときのデフォルト値 - たごもりすメモ
なんか自分で docs.fluentd.org へのpatchを書いてて混乱してきたのでまとめる。コードを読んでも関係する設定値がいくつものモジュールに分散しており、完全に把握することが困難である。具体的には、この組合せを記憶だけで答えられる fluentd コミッタはおそらく一人もいない。 概要 対象は BufferedOutput および TimeSlicedOutput を継承している output plugin の全て*1。out_forward, out_exec や out_exec_filter も含まれる。 基本的にはいくつかの設定により flush をするタイミングを制御するパラメータ一式、およびflush対象となるデータのチャンクを溜めておく量の上限を決めることとなる。fluentd をうっかり試したときに「アイエエエ、fluent-cat してみたんだけど、設定したと
GrowthForecastの値をNagiosから監視できるようにすると #fluentd がより活用できる - たごもりすメモ
Fluentd からGrowthForecastへデータを投入するためのプラグイン fluent-plugin-growthforecast を作って使っている。 fluent-plugin-flowcounter および fluent-plugin-growthforecast released! #fluentd - tagomorisのメモ置き場 で、このGrowthForecastには最近、データをJSONで出力する機能がついた。 GrowthForecastに1分更新グラフ作成とサマリーなどのJSONフォーマットでの出力機能追加 - blog.nomadscafe.jp つまりFluentdからストリーム状に入力したデータを可視化しつつ、更に時系列データとしての(変則の)ストレージとしても使えるようになった、ということだ。つまりつまり、最近の3数値平均をとってそれを相手になんかチ
Fluentd out_forward における最適化パラメータいくつかの話 - たごもりすメモ
Fluentdのデータをネットワーク経由で転送するための組み込みプラグイン out_forward には最適化のための設定がいろいろあるが、内部構造への理解がないとなかなか意味がわからなかったりするものも多い。ので、あんまりいじってる人はいないんじゃないかという気がする。 最近複数の転送先へのロードバランスを out_roundrobin ベースの方法から out_forward の機能を使った方法に切り替えてみたので、ついでにそのあたりについて書いてみる。 (おまけ) out_roundrobin と out_forward(のロードバランス)の違い out_roundrobin は event stream の emit つまりFluentd内部における最小の配送処理単位ごとに配送先プラグイン(のインスタンス)を切り替える。可能な限り細かい単位で配送先をバラけさせたいときはこちらを使う
UPDATE: fluent-plugin-config-expander and fluent-plugin-forest - たごもりすメモ
先日 fluent-plugin-forest を書いたあとpatchをもらって __HOSTNAME__ というプレースホルダをサポートしたりしてた。 で、こないだ config-expander を書いたときに「ホスト名を置換できるプレースホルダを組込みで入れようかな？ まあ out_forest あるしいいか……」と思ってスルーしてた、が、forestはoutput pluginにしか使えなくて残念だなーということをこのblogエントリを見て思ったのでした。 fluentdで自ホスト名を自動でタグにするの巻 - アルパカDiary ということで、config_expander でも __HOSTNAME__ というプレースホルダを展開できるようにしてみた。 ついでにtwitter上で見掛けた「__hoge__ より ${bar} なプレースホルダの方がいい」という意見を取り入れまして
fluent-plugin-numeric-monitor v0.1.0 and fluent-plugin-numeric-counter v0.1.0 released! - たごもりすメモ
Fluentdメッセージ中の数値の統計・集計をとるためのプラグインをふたつリリースしたのでその話。numeric-monitorは前に 0.0.x 系のバージョンでいちおう出してたけど、自分の手元でもちゃんと使い始めたので v0.1.0 として改めてリリースした。 fluent-plugin-numeric-counter fluent-plugin-numeric-counter | RubyGems.org | your community gem host tagomoris/fluent-plugin-numeric-counter · GitHub このプラグインは数値の上下範囲にマッチするメッセージをカウントする。数値版の datacounter みたいなものだと思えばよい。出力も datacounter の出力内容とまったく同じ。 Fluentd Casualのときの @fu
fluent-plugin-forest released! - たごもりすメモ
現状のfluentdでは、タグを動的に扱う方法がいまいち無い。具体的に言うと設定項目にタグに応じて変化するような指定をしたい場合、タグごとに分けて書くしかない。例えば out_file で出力先ファイル名をタグに応じてつけたい場合、タグの数だけ match 節を書く必要がある。 <match hoge> type file path /var/log/hoge.log </match> <match pos> type pos path /var/log/pos.log </match> # 以下いっぱいこれには極めて簡単にわかる範囲で、ふたつの大きな問題がある。 多数のタグを扱う場合、設定ファイル全体のボリュームが肥大化して管理コストが増大する(品質が低下する) 新しく扱うタグが増える場合、設定ファイルの更新と適用が必要となり、管理コストが増大する 既に手元でこの問題に悩まされていて、H
#fluentd fluent-plugin-file-alternative released! - たごもりすメモ
fluentd 標準のファイル出力プラグイン out_file はメッセージをJSONにシリアライズして出力するというもので、これはこれでまあいいんだけど、JSONだと逆に扱いづらいケースなんかもUNIXの文化ではあれこれある。また完全にJSONというわけでもなく、行頭にタブ区切りで日時とタグが入ってたりもするため、いきなり JSON parser にかけるわけにもいかなかったりして面倒だだだ。 ということで、出力フォーマットをさまざまにいじれるようにしたプラグイン out_file_alternative を作り fluent-plugin-file-alternative としてリリースしました。 fluent-plugin-file-alternative | RubyGems.org | your community gem host tagomoris/fluent-plugin
#fluentd 用ログ収集専用のエージェント fluent-agent-lite 書いた - たごもりすメモ
みんな大好きfluentdはたいへん便利ですが、ログの収集＆集約だけをしたい、というときにちょっとオーバースペック気味のところがあります。特に in_tail はログの読み込みと同時に parse をする仕組みになっており、まあログが書かれた場所ならparseのルールもわかってるでしょ、というところは合理的なものでもあるのですが、loadavgが高いサーバでそういうことをするのは正直にいってなかなか厳しいです。 そういうわけで以前に scribeline というエージェントツールを作ったのでこれを fluentd 以降後も使い続けていたのですが、ログをいったん集約するところの fluentd がCPU使用率的にいっぱいいっぱいになって厳しいものがありました。「scribe(Thrift)じゃなくてMessagePackにすれば倍くらいさばけるよ」ということを某開発者が言っていたような気もす
Fluentdとはどのようなソフトウェアなのか - たごもりすメモ
Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転
Perlでコマンドラインオプションの解析に Getopt::Long を使う時、絶対に忘れてはいけない引数 - たごもりすメモ
Perlでコマンドラインオプションをparseしようと思うと組込みモジュールとしては Getopt::Std と Getopt::Long がある。が、long style option *1 つまり --option-name のようなオプションを解釈してくれるのは Getopt::Long だけだ。なので普通はこちらを使おう。 ただし 絶対にデフォルト、つまり以下のようにして使ってはいけない。 use Getopt::Long; my (@primary, @secondary, $silent); GetOptions( "server-primary|p=s" => \@primary, "server-secondary|s=s" => \@secondary, "silent|S" => \$silent ); これダメ！ 絶対ダメ！ 死ぬ！ 最初に結論を書く 必ず以下のように
本番環境でのperl/ruby/nodeのセットアップ - たごもりすメモ
本番環境にperlとかrubyとかnodeを入れるんだけど、もちろん system perl じゃやってられないので指定したバージョンのものを一般ユーザの管理下に突っ込みたい。 で、そういうのをこれまで perlbrew とか rvm とか rbenv とか nvm とか nodebrew とかでやってたんだけど、さすがに色々疑問が湧いてきた。バッチで単発実行するために eval "$(rbenv init -)" とかさすがにおかしくね？ みたいな。 ということで tokuhirom method 的にインストール用の簡単コマンドを使って実行、あとはパスを通せばいいじゃん、ということにしようかと思う。 参考: サーバーのセットアップは perlbrew とかじゃなくてよくね? という時のライフハック - blog.64p.org これ、今朝までは Perl::Build をどうにかしてC
東京Ruby会議10にいってきた＆しゃべってきた - たごもりすメモ
千葉Ruby会議10という噂でもちきりの東京Ruby会議10にいってきた。面白かった！ 遠かったけど。 東京Ruby会議10 #tkrk10 - Regional RubyKaigi 会期：2013/01/13(日)〜14(祝・月) スタッフのみなさん、特に2日目の雪はたいへんだったと思いますが、おつかれさまでした。ありがとうございました。イベント主催側の判断として「中止して帰らせる」というのはつらかっただろうなと思いますが、おかげでその後の混乱が抑えられたんだと思います。 で、内容的には、いろんなrubyistと話ができて面白かったなー、というか。見知ってるけどほとんど話したことない、みたいな人が多い世界なので、何人もの人とあれこれ話ができたのはたいへんよかった。 セッションは内容がだいぶコミュニティ運営とかエンジニアとしての成長とは、みたいな話が多くて、個人的にはあんまりそういうのは興
GrowthForecastのJSON APIおよびクライアントライブラリについて - たごもりすメモ
雪にかこまれた温泉宿からこんちには。 クライアントライブラリを書いてからblogエントリにしようと思ったらこんな素敵エントリを書かれてしまった、くやしい……！ GrowthForecastでAPI使って複合グラフ作ったり、グラフの色を変えたりしてみた - mikedaの日記 みんな大好き GrowthForecast ですが、じつに簡単にグラフを作れてしまえるので調子に乗って作りまくった挙句、複合グラフを作る手作業で死んだり色を揃える作業で死んだりそもそも無いといけないグラフが本当にあるのか確認するのが面倒でうっちゃってたりするようなことがあります。必ずあるはずです。ですよねー。あるある。 ということでグラフの存在を確認したりグラフ設定を変更したりそもそも無ければ作ったり、という作業をコードからやりたかったので、ひとそろい作った。とりあえず GrowthForecast に JSON AP
#fluentd meetup 3 にいってきた＆しゃべってきた - たごもりすメモ
Fluentd meetup #3 #fluentd on Zusaar 開催されたので参加してきた。また td-agent に fluent-plugin-webhdfs がバンドルされるようになった後ということで、それについて話さないかと言われていたのでそういう話をひとつしてきた。 今回の会場はIIJさんの会議室。広くていいなあ。ありがとうございました！ で、話の内容とか参加者の反応を見ていると、もうだいぶ普通に使われるツールになったのかなーという気がする。もうあまり面白ネタとか驚きが無い。LT枠も4枠は結局埋まらなかったみたいだし。 何か面白なプラグインを書いてネタに走る人とかそろそろ出てこないかなーｗ あとIIJの人の話す内容を聞いてて、書こうかと思いつつ放置しているプラグインとか改良を放置しているプラグインとかが脳内によみがえってきてまいった。すいませんすいません。pullreq
#isucon2 をやったあとの反省など - たごもりすメモ
#isucon2をやりましたの話 - tagomorisのメモ置き場 これの続き。主に反省というか振り返りというかについて書きますよ。(誰かが次回っぽい何かをもしかしてやるかもしれないときのために！) 参加層について 今年はいろんな言語が使われたので大変よかったですね！ 実際、告知をすればいいというものではなくて、各コミュニティの適切な層に届けるというのはなかなか難しい。告知から参加申し込み受付まではそう期間を空けられないし、参加者総数はそうそう増やせないし*1。 それでも参加層が広がるのは良いことだと思う。イベントとして好評なまま回数を重ねることが大事なんじゃないかな。誰がやるにしろ。 問題設定について 今回は(最終的に)トランザクションが問題になるものにしよう、そのために並列度はガツンと上げよう、というのは最初に決めていた。 が、実際には実装のめんどくささを意識してなかった。今にして思
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
