Fluentdでログを集める時にそのサーバのホスト名（hostname）をレコードに追加したい。 そういう時に便利な設定サンプルを紹介します。 ユースケース tailプラグインで収集したApacheのエラーログに、ホスト情報を付与する その他、ございましたら教えてください Filterを用いた手法（オススメ） td-agent2環境（fluentd v0.12以降のバージョン）を利用していれば、Filterプラグインが使えます。 手間の掛かるタグ書き換えは必要ありません。 次の方法が標準付属のプラグインで実現できるため、最もシンプルです。 <source> @type forward </source> <filter debug.*> @type record_transformer <record> host ${hostname} </record> </filter> # @typ

Fluentdでログのちょっとした加工をする際に、タグの付け替えが必要です。 新しいタグを指定するか、先頭文字列の付け替えを行う手法が良く使われます。 しかしそれだけではかゆいところに手が届かず、もどかしい思いをされたことでしょう。 そんな時、タグをドットで分解した要素毎に分解して使えるプレースホルダが大活躍します。 この記事を読めば、これがなぜ今まで無かったのか不思議に感じる程です。 そう思えるほど便利な新機能、それでは早速紹介します。 プレースホルダとは プレースホルダとは、一部のfluentdプラグインの設定値の中で使える変数です。 良く使われるプレースホルダとして次のようなものがあります。 ${tag} __TAG__ {$tag_parts[n]} __TAG_PARTS[n]__ ${hostname} __HOSTNAME__ これはFluentdに届いたログを次のように加工

Fluentdなどから収集したメッセージをelasticsearchへ格納してKibanaで可視化するソリューションは素晴らしく、とても人気があります。次の画像のように見栄えが良いことも特徴です。 このダッシュボードアプリであるKibanaはJavaScriptアプリケーションです。そのため静的ファイルを配置すればどこでも動きます。 しかしそれだけのためにApacheやNginxなどのWEBサーバを新たに起ち上げるのは手間ですよね。 実は新たに起ち上げない方法もあるのです。こんな時に役立つTipsを紹介します。 elasticsearchのsiteプラグイン siteプラグインは、ウェブベースのインターフェースを提供するものです。 elasticsearchの挙動へ変更を加えるものではないため、サービス停止(再起動)を行わずにインストール・アップデート・アンインストールができます。 モニタ

2014年9月9日開催の『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』　出版記念！執筆者が語る大講演会！にて発表してきました。 今回は「Fluentdのお勧めシステム構成パターン」というタイトルで、ユースケース毎にどのようなシステム構成をすると運用しやすいかのノウハウをお話しさせていただきました。 また、パネルディスカッションではラジオ番組のようなスタイルで、モデレータに @naoya_ito（伊藤直也氏）をお招きして行い、Kibana以前の可視化はどうしていたの？など、ざっくばらんなトークが出来てとても楽しい経験でした。 発表資料 今回は書籍に書かれた内容をざっとおさらいしつつ、システム構成パターンについて解説しました。 発表資料はSlideshareにアップしております。 Fluentdのお勧めシステム構成パターン 書籍 本書はWEB+DB Pressを取り扱う書店のほか、

LuceneベースのNoSQL全文検索サーバ、elasticsearchはログ解析の収集先として取り上げられることが多いですが、優れたNoSQL全文検索サーバでもあります。 日本でも2013年末頃から続々とブログ記事や利用事例が増えている注目の技術でもあります。 今回は、その中で全文検索サーバとしての切り口で分かりやすく解説された6つの記事を紹介します。 （追記）Hello! Elasticsearch. — Medium ナレッジワークス株式会社のKunihiko Kidoさんによるとても分かりやすい記事です。 https://medium.com/hello-elasticsearch 2014年4月に入ってから怒濤の勢いでこれらのステキな記事が追加されています。 Elasticsearch Features — 主にシステムを中心とした特徴まとめ Elasticsearch Quic

任意のSQLクエリで取得した結果の差分から、insert/update/deleteイベントを検知するプラグインをリリースしました。イベント検知だけでなく、レコードの内容と共にElasticsearch/Solrへ同期を行う、Outputプラグインも同封しています。 これはあえてバイナリログ(MySQLBinlogAPI)は使わずに、SQLクエリの実行結果の差分を見てinsert/update/deleteイベントを検知します。 そのため、純粋なテーブル同期だけでなく、任意のJOINやVIEWテーブルを元とした差分同期処理が実現できるのが特徴です。 y-ken/fluent-plugin-mysql-replicator https://github.com/y-ken/fluent-plugin-mysql-replicator http://rubygems.org/gems/flue

fluent-plugin-elasticsearchやKibanaのデフォルトであるlogstash形式では、年月日毎にインデックスを作成されて使われることを想定されています。 これは扱いやすいのですが万能では無く、次のような状況ではパフォーマンス的な観点で、このインデックスの粒度を変更することを検討すると良いケースがあります。 粒度を細かくしたいケース（時間単位） 日毎のインデックス作成では、elasticsearchに割り当てたメモリ量を超えてしまう 粒度を荒くしたいケース（週単位/月単位/年単位） 日毎のインデックス作成では容量が小さく、日常的に検索する範囲が複数のインデックスに渡るとき Kibanaは年月日以外の粒度（時間・日・週・月・年）にも対応していますので、変更することも容易です。これは次の2つの設定変更で適用できます。 ログ収集を行うElasticsearchへ流し込む、

photo by byte MySQLといえば、巷ではInnoDBばかり注目され、MyISAMの地下アイドル化がにわかに語られる今日この頃、皆様いかがお過ごしでしょうか。 まあカジュアルにストレージエンジンを変換するだけで済むなら、簡単なのです。 -- legacy_my_tableをInnoDBストレージエンジンに変換する ALTER TABLE legacy_my_table ENGINE=InnoDB; よし終わった！さあランチタイムだ！ ・・・と片付けてしてしまうと、悲劇が起こるかもしれません。(>o<;) それでは本日、MyISAMからInnoDBへ移行するなら知っておきたい意外な落とし穴とTipsを紹介します。 AUTO INCREMENTの挙動が違う落とし穴 以下に該当するクエリを利用している場合には、注意が必要です。私はハマりました。 INSERT IGNORE INTO

ログデータを活用してビジネスに役立てようという最近のトレンドは理解できる。 しかし、なぜログ収集ソフトウェアのFluentdがこれほどまで話題になるのか、不思議に感じている方もいるのではないだろうか。単にログデータを収集するならばsyslog-ngやrsyslogで十分ではないかという意見もあるだろう。 それらは既存のログシステムを置き換えるプロダクトであり、Fluentdのそれとは根本的に異なる。Fluentdは、既存のログシステムに手を入れることなく新たにログの収集を行い、ストリームデータ処理を実現するプロダクトなのである。 一般的にログデータはサーバの数だけ分散しており、それを定期実行処理で収集するということだけでも、なかなか骨の折れる仕事である。さらに集めるだけでなく、日々増え続けるログデータを活用できる形に加工してしかるべきデータストアに保管するということに挫折した方もいるのでは

FluentdのレコードにあるIPアドレスを元に位置情報を付与するプラグインをリリースしました！ これを使えば、Maxmind社の提供するGeoIPというデータベースを利用してリアルタイムに位置情報を付与できます。 パフォーマンスを重視するため、BufferedOutputをベースに、GeoIPのC拡張を利用した設計としました。 y-ken/fluent-plugin-geoip https://github.com/y-ken/fluent-plugin-geoip http://rubygems.org/gems/fluent-plugin-geoip それでは早速使い方の紹介を行います。 使い方 インストール方法 # fluentdをシステム側に入れている場合 $ gem install fluent-plugin-geoip # td-agentを使っている場合 $ sudo /u

MySQLサーバで希に遭遇するディスク残量障害事例と共に紹介します。 こちらは、以下エントリよりネタをパクりましたインスパイアしました。すみません。 Linuxサーバがディスク容量不足になった！何か消さねば！ってなった時にどう対処するか - 元RX-7乗りの適当な日々 Linuxサーバのディスク容量減少アラートが飛んできた！ってときにどう対処するか - tagomorisのメモ置き場 今回紹介する対処パターン 今回は4つの方法を紹介します。 不要なデータベース/テーブルを削除 スロークエリログ/クエリログを削除 バイナリログを削除 どれのパターンにも属さないレアなシチュエーション 不要なデータベース/テーブルを削除 あまりそういうケースは無いとは思いますが、 DROP DATABASE foo;やDROP TABLE foo;で削除します。 スロークエリログ/クエリログを削除 du -sc

イベントログ収集ツールFluentdに、mrubyからも構造化ログデータを送りたい。 その情熱に勢いを任せて、"mruby-fluent-logger" を作りましたので公開します。 これを使えば、C/C++アプリに組み込んだmruby等からFluentdを容易に扱えますね。 そんな"mruby-fluent-logger"はこれらの用途に最適です。 アプリケーションログ・デバッグログを送る 組み込み機器のセンサー情報などを送る 夢が広がりますね！ mruby-fluent-loggerとは mrubyから呼び出せるロガークラスで、Fluentdへ構造化データを送れます。 GitHubリポジトリにてソースを公開しております。 https://github.com/y-ken/fluent-logger-mruby mrubyからの呼び出し方法 アルファリリースとも言うべき段階のため、必要最