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
2014年9月9日開催の『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！にて発表してきました。 今回は「Fluentdのお勧めシステム構成パターン」というタイトルで、ユースケース毎にどのようなシステム構成をすると運用しやすいかのノウハウをお話しさせていただきました。 また、パネルディスカッションではラジオ番組のようなスタイルで、モデレータに @naoya_ito（伊藤直也氏）をお招きして行い、Kibana以前の可視化はどうしていたの？など、ざっくばらんなトークが出来てとても楽しい経験でした。 発表資料 今回は書籍に書かれた内容をざっとおさらいしつつ、システム構成パターンについて解説しました。 発表資料はSlideshareにアップしております。 Fluentdのお勧めシステム構成パターン 書籍 本書はWEB+DB Pressを取り扱う書店のほか、
JVMで動くelasticsearchを安定運用させるにはリソース監視も欠かせません。 今回は手軽なリソース監視が出来るMuninを用いて、インストール方法から作られるグラフサンプルの紹介まで行います。 利用プラグイン elasticsearch 1.x系で動くプラグインは現状これ1つのみです。Perlで書かれているため外部依存無しで動きます。 y-ken/munin-plugin-elasticsearch A useful Munin plugin for monitoring elasticsearch 1.x nodes in Perl. https://github.com/y-ken/munin-plugin-elasticsearch 次のプラグインが同封されています。 elasticsearch_cache - フィールドとフィルタのキャッシュ状況 elasticsearc
2014年8月8日、ログ収集や可視化を始めたいエンジニア必携の書籍が技術評論社より刊行されます。 本邦初公開となる、全編書き下ろしの特集で構成された本書を読むことで、ログ解析の有用性からログ収集、保存、可視化手法を習得できます。 私はこの第2特集「ログ収集ミドルウェアFluentd徹底攻略」の執筆を担当しました。 サーバ/インフラエンジニア養成読本 ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus) それでは、それぞれの特集について簡単に紹介したいと思います。 サーバ/インフラエンジニア養成読本 ログ収集〜可視化編 特集1 ログ解析からはじめるサービス改善 (鈴木 健太) 第1特集では、ログを蓄積して解析する意義とは何か、コーヒーショップのECサイトを例に、データ分析のケーススタディと共に解説されています。 第1章 はじめに 第2章 サー
elasticsearchは全文検索サーバとしても知名度を獲得しており、次のような記事も人気を集めています。 elasticsearchを全文検索サーバとして活用するなら読んでおきたい、6つのブログ記事をピックアップ - Y-Ken Studio http://y-ken.hatenablog.com/entry/essential-japanese-blogs-for-elasticsearch-study MySQLでは実現の難しかったLuceneならではの次のような特徴を兼ね備えたelasticsearchはとても魅力ですよね。 ファセット検索 (Facet) http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-facets.html 柔軟な日本語処理 (kuromoji) http
LuceneベースのNoSQL全文検索サーバ、elasticsearchはログ解析の収集先として取り上げられることが多いですが、優れたNoSQL全文検索サーバでもあります。 日本でも2013年末頃から続々とブログ記事や利用事例が増えている注目の技術でもあります。 今回は、その中で全文検索サーバとしての切り口で分かりやすく解説された6つの記事を紹介します。 （追記）Hello! Elasticsearch. — Medium ナレッジワークス株式会社のKunihiko Kidoさんによるとても分かりやすい記事です。 https://medium.com/hello-elasticsearch 2014年4月に入ってから怒濤の勢いでこれらのステキな記事が追加されています。 Elasticsearch Features — 主にシステムを中心とした特徴まとめ Elasticsearch Quic
FluentdのtailプラグインでElasticsearchのログを収集する方法を紹介します。 収集対象ログ /etc/elasticsearch/logging.ymlにて設定された動作でログを次のファイルに出力します。 /var/log/elasticsearch/elasticsearch.log /var/log/elasticsearch/elasticsearch_index_search_slowlog.log /var/log/elasticsearch/elasticsearch_index_indexing_slowlog.log slowlogに関しては/etc/elasticsearch/elasticsearch.ymlにて設定した閾値時間を超えて処理したクエリを記録できますが、デフォルトでは設定が行われていません。後々のパフォーマンス観察を容易にするためにも設
Elasticsearch 1.0.0 released ということで、早速アップデートしてみました！ elasticsearchを0.90.3から1.0.0へrpmで更新しました。 /etc/elasticsearch/elasticsearch.ymlの差分もあるので、オリジナルに加えていた変更点の反映・プラグインの更新も済ませたらesを再起動。数分応答返さず焦ったが無事完了！— Y.Kentaro (@yoshi_ken) February 13, 2014 本日は、このアップグレードを行った記録を紹介します。 # アップデート前 $ rpm -q elasticsearch elasticsearch-0.90.3-1.noarch # アップデート後 $ rpm -q elasticsearch elasticsearch-1.0.0-1.noarch 追記 公式のアップデート手
photo by minnepixel 突然ですが皆さん、アプリログをFluentdで収集する際に個人情報となるデータの扱い、どうしていますか？ こういったログデータは個人情報保護や内部統制の観点から、データマスキングをしてから分析した方が好ましいです。 しかしながら、サーバにアクセス出来る人が限られるといった理由で問題の先送りをしているケースがあるかもしれません。 最近流行のログの見える化により、データマスキングされないまま多くの人がそういった情報にアクセス出来るようになっているのなら、余計にマズいですよね。 そこでデータマスキングを実現するfluent-plugin-anonymizerの出番です。 このプラグインを経由することで、文字列のハッシュ化と、IPv4/IPv6アドレスの丸め処理が出来ます。 リアルタイム分析用のElasticsearch+Kibanaといった検索ダッシュボー
fluent-mixin-rewrite-tag-nameというFluentd向けMixinプラグインを公開しました。 このMixinプラグインは、<source>や<match **>の中で使えるtagオプションを追加します。 タグ書き換え周りのプラグイン実装の省力化ができますね！ https://github.com/y-ken/fluent-mixin-rewrite-tag-name http://rubygems.org/gems/fluent-mixin-rewrite-tag-name これは、次のようなプラグインで使えるタグ書き換えに用いられている機能を、その他のプラグインに転用できるよう切り出しました。 fluent-plugin-forest fluent-plugin-record-reformer fluent-plugin-rewrite-tag-filter 提
fluent-plugin-elasticsearchやKibanaのデフォルトであるlogstash形式では、年月日毎にインデックスを作成されて使われることを想定されています。 これは扱いやすいのですが万能では無く、次のような状況ではパフォーマンス的な観点で、このインデックスの粒度を変更することを検討すると良いケースがあります。 粒度を細かくしたいケース（時間単位） 日毎のインデックス作成では、elasticsearchに割り当てたメモリ量を超えてしまう 粒度を荒くしたいケース（週単位/月単位/年単位） 日毎のインデックス作成では容量が小さく、日常的に検索する範囲が複数のインデックスに渡るとき Kibanaは年月日以外の粒度（時間・日・週・月・年）にも対応していますので、変更することも容易です。これは次の2つの設定変更で適用できます。 ログ収集を行うElasticsearchへ流し込む、
Fluentdでログのちょっとした加工をする際に、タグの付け替えが必要です。 新しいタグを指定するか、先頭文字列の付け替えを行う手法が良く使われます。 しかしそれだけではかゆいところに手が届かず、もどかしい思いをされたことでしょう。 そんな時、タグをドットで分解した要素毎に分解して使えるプレースホルダが大活躍します。 この記事を読めば、これがなぜ今まで無かったのか不思議に感じる程です。 そう思えるほど便利な新機能、それでは早速紹介します。 プレースホルダとは プレースホルダとは、一部のfluentdプラグインの設定値の中で使える変数です。 良く使われるプレースホルダとして次のようなものがあります。 ${tag} __TAG__ {$tag_parts[n]} __TAG_PARTS[n]__ ${hostname} __HOSTNAME__ これはFluentdに届いたログを次のように加工
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は、既存のログシステムに手を入れることなく新たにログの収集を行い、ストリームデータ処理を実現するプロダクトなのである。 一般的にログデータはサーバの数だけ分散しており、それを定期実行処理で収集するということだけでも、なかなか骨の折れる仕事である。さらに集めるだけでなく、日々増え続けるログデータを活用できる形に加工してしかるべきデータストアに保管するということに挫折した方もいるのでは
2013年11月12日にリクルートテクノロジーズで開催された「第2回 ElasticSearch勉強会」に参加＆発表しましたので、レポートします。 発表テーマ 「ElasticSearch+Kibanaでログデータの検索と視覚化を実現するテクニックと運用ノウハウ」というテーマで発表しました。 ElasticSearch+Kibanaでログデータの検索と視覚化を実現するテクニックと運用ノウハウ from Kentaro Yoshida まだ検証段階ではありますが、ElasticSearchとKibanaの組み合わせはかなり気に入っています。 なお、発表で言及した0.90.6の不具合が修正された elasticsearch-0.90.7 が既にリリースされておりますので、これからElasticSearchを使われる方は0.90.7をお使いください。 聴講メモ ElasticSearchの書籍
mroongaで()~+><-*などの記号を含んだ文字列を検索しようとすると、以下のエラーが起きます。 ERROR 1064 (42000): failed to parse fulltext search keyword 本日はその対処法を紹介します。 エスケープ方法 特別な意味を持つ記号を検索する場合 ()~+><-*などの記号を検索する場合は、ダブルクォートで囲いましょう。 以下、「<meta>」という検索を行う際のエスケープ方法です -- 動かない SELECT COUNT(*) FROM test_table WHERE MATCH(body) AGAINST('*D+ <meta>' IN BOOLEAN MODE); ERROR 1064 (42000): failed to parse fulltext search keyword: <*D+ <meta>>: <Synt
mroongaのプラグインインストール・アンインストールを手動で行いたい方向けのメモ。 MySQLが起ち上がっていない状態で、プラグインをインストールした時にも必要ですね。 更新履歴 2014年1月8日：mroonga-3.07の新機能であるmroonga_escapeのトピックを追加 インストール時に実行しているクエリ DELETE IGNORE FROM mysql.plugin WHERE name = 'mroonga'; INSTALL PLUGIN mroonga SONAME 'ha_mroonga.so'; CREATE FUNCTION last_insert_grn_id RETURNS INTEGER SONAME 'ha_mroonga.so'; CREATE FUNCTION mroonga_snippet RETURNS STRING SONAME 'ha_mr
サーバ負荷メトリクス分析ツール「Munin」は、導入・運用保守コストが圧倒的に低いのが特徴です。 しかし、たった数十台の監視を行うだけで、5分おきの更新もままならない程のCPU・I/O負荷となります。 設定の手間の掛かるCactiやGangliaへの乗り換えも面倒で仕方ありません。 この記事は、そんな悩みを抱えるインフラエンジニアへ贈るTipsです。 環境 CentOS-6.3 Munin-1.4.7 課題 以下のような課題を抱えているなら、この記事が役立つはずです。 更新負荷が高く、5分では終わらない状態となった グラフ動的生成化するとcgiが必要＆表示が重たいため、軽快にグラフ表示を行いたい 速度低下を覚悟で グラフ動的生成化 を行ったが、今度はhtml更新中のグラフ欠落に悩まされている 動作分析 Muninは5分おきに何をしているのか、解説します。 STEP1〜2は低負荷ですが、ST
fluent-plugin-geoip v0.0.4をリリースしました。 今回は主にGeoLiteCityデータベース参照パスの不備の修正とREADMEの加筆を行いました。 https://github.com/y-ken/fluent-plugin-geoip http://rubygems.org/gems/fluent-plugin-geoip 修正内容の説明に続けて、後半では次のお役立ちTipsの紹介も行います。 インストール時のTips Fluentd + ElasticSearch + Kibana v3 を使う際のTips 変更内容概要 v0.0.3とv0.0.4の修正差分より紹介します。 [不具合] GeoLiteCityデータベース参照パスの不備を修正 [改善] 過剰なログ出力の削除 [改善] Travis-CIを用いた自動テストへの対応 Tips紹介 ここで、ハマりやす
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
