Fluentdのレコードにホスト名を付与する最良の方法 - Y-Ken Studio
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
データ可視化に便利なkibanaは、elasticsearchのプラグインとして構成すると便利 #Fluentd - Y-Ken Studio
Fluentdなどから収集したメッセージをelasticsearchへ格納してKibanaで可視化するソリューションは素晴らしく、とても人気があります。次の画像のように見栄えが良いことも特徴です。 このダッシュボードアプリであるKibanaはJavaScriptアプリケーションです。そのため静的ファイルを配置すればどこでも動きます。 しかしそれだけのためにApacheやNginxなどのWEBサーバを新たに起ち上げるのは手間ですよね。 実は新たに起ち上げない方法もあるのです。こんな時に役立つTipsを紹介します。 elasticsearchのsiteプラグイン siteプラグインは、ウェブベースのインターフェースを提供するものです。 elasticsearchの挙動へ変更を加えるものではないため、サービス停止(再起動)を行わずにインストール・アップデート・アンインストールができます。 モニタ
Fluentdのお勧めシステム構成パターンについて発表しました - Y-Ken Studio
2014年9月9日開催の『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！にて発表してきました。 今回は「Fluentdのお勧めシステム構成パターン」というタイトルで、ユースケース毎にどのようなシステム構成をすると運用しやすいかのノウハウをお話しさせていただきました。 また、パネルディスカッションではラジオ番組のようなスタイルで、モデレータに @naoya_ito（伊藤直也氏）をお招きして行い、Kibana以前の可視化はどうしていたの？など、ざっくばらんなトークが出来てとても楽しい経験でした。 発表資料 今回は書籍に書かれた内容をざっとおさらいしつつ、システム構成パターンについて解説しました。 発表資料はSlideshareにアップしております。 Fluentdのお勧めシステム構成パターン 書籍 本書はWEB+DB Pressを取り扱う書店のほか、
LXCベースのDockerとホストマシンのディスクI/O性能を比較検証（Bonnie++編） - Y-Ken Studio
dotCloudが開発しているLinuxコンテナ型仮想ソフト「Docker」が巷で話題ですね！ これはLXCにストレージドライバとしてunionfsから派生したaufs（CentOSではLVMのThin Provisioning）を組み合わせた所がキモで、つまりファイルシステムの差分管理が出来る特徴があります。 なんだか仕組みを想像する限りディスクI/Oが遅そうな印象ですが、どの程度のものかベンチマークを取りました。 ストレージドライバ Dockerは元々aufsで作られていたのですが、それはAUFS対応のカーネルを入れる前提です。 これはRedHat系ディストリビューションへの対応を行う上での大きなハードルでした。 そこで同様にCoW(CopyOnWrite)を実現出来るLVMのThin Provisioningが採用されています。 ドライバがaufsなのかLVMを扱うためのdevice
MySQLテーブルへの更新/削除イベントを逐次取得するFluentdプラグイン「fluent-plugin-mysql-replicator」をリリースしました - Y-Ken Studio
任意の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
MySQLでMyISAMからInnoDBに乗り換える際に知らないとハマる、怖い話 - Y-Ken Studio
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が流行る理由がいま分かる、10の実践逆引きユースケース集 - Y-Ken Studio
ログデータを活用してビジネスに役立てようという最近のトレンドは理解できる。 しかし、なぜログ収集ソフトウェアのFluentdがこれほどまで話題になるのか、不思議に感じている方もいるのではないだろうか。単にログデータを収集するならばsyslog-ngやrsyslogで十分ではないかという意見もあるだろう。 それらは既存のログシステムを置き換えるプロダクトであり、Fluentdのそれとは根本的に異なる。Fluentdは、既存のログシステムに手を入れることなく新たにログの収集を行い、ストリームデータ処理を実現するプロダクトなのである。 一般的にログデータはサーバの数だけ分散しており、それを定期実行処理で収集するということだけでも、なかなか骨の折れる仕事である。さらに集めるだけでなく、日々増え続けるログデータを活用できる形に加工してしかるべきデータストアに保管するということに挫折した方もいるのでは
MySQL-5.5/5.6でのレプリケーション利用者に伝えたい「RESET SLAVE」にまつわる怖い話 - Y-Ken Studio
MySQL-5.5よりRESET SLAVE;の挙動が変わり、直後にCHANGE MASTER構文を 発行しないと場合によっては問題が発生するとMySQLのドキュメントに記載されていました。 さらに、RESET SLAVE ALL;というクエリもサポートされたようです。 どういう事なのでしょう？ 調べてみました。 ドキュメントにさらっと何か書いてある In MySQL 5.6 (unlike the case in MySQL 5.1 and earlier), RESET SLAVE does not change any replication connection parameters such as master host, master port, master user, or master password, which are retained in memory. Thi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
