graphite にメトリクスをポストする fluent-plugin を書きました 先に github で公開されていた fluent-plugin-graphite がありましたが、イチから書いて gem release いたしました https://github.com/studio3104/fluent-plugin-graphite http://rubygems.org/gems/fluent-plugin-graphite なぜイチから書いたのか 以下のような箇所に懸念があり、修正だと結局まるっと書き直すのと変わらないと思いイチから書いてしまいました 先行プラグインは、 Fluent::BufferedOutput を継承し、内部でサンプリングやカウントなどの計算をしていたが、そういうのは他のプラグインに任せて、来た値をそのまま投げてあげればいいのではないかと思った レコード
複数台のサーバーやクラウド環境を組み合わせてのサービス運用においては、ログの収集方法に工夫が必要となる。こういった場合に有用なのが、さまざまなログの収集手段を提供するfluentdだ。今回はfluentdのアーキテクチャやそのインストール/設定方法、基礎的な設定例などを紹介する。 さまざまな方法でログを収集できるfluentd 今回紹介するfluentdは、Treasure Dataが開発するログ収集管理ツールだ（図1）。オープンソースで公開されており、Linuxや各種UNIXで動作する。 図1 fluentdのWebサイト ログ収集のためのソフトウェアとしてはsyslogdやsyslog-ngなどが有名だが、fluentdがこれらと異なる点としては、以下が挙げられる。 さまざまなソースからのイベントをさまざまな媒体に出力できる fluentdの大きな特徴としては、ログの収集方法やログの記
みなさんJMXは使っていますか？Javaアプリケーションのメモリ使用量を始めとした統計情報を取得したりできる、運用には欠かせないモニタリング・管理の仕組みですが、統計情報を蓄積する方法に悩んでいる方も多いのではないでしょうか。 今回はアプリケーションから取得できる様々な統計情報をfluentd経由で蓄積し、分析やトラブルシュートに活用する方法を紹介します。 JMX用のfluentdプラグイン JMXの統計情報をfluentdで収集するfluent-plugin-jolokiaというプラグインを使います。 fluent-plugin-jmxではなくfluent-plugin-jolokia？と思われるかもしれません。 JolokiaはJMXをJSONベースのREST APIとして提供するためのエージェントです。fluentdのプラグインはRubyで書かれていますが、Rubyから直接JMXのプ
jstatの結果を入力とするfluent-plugin-jstatを作りました。 GitHub - wyukawa/fluent-plugin-jstat fluent-plugin-jstat | RubyGems.org | your community gem host JavaアプリケーションのモニタリングというとJMXが思い浮かぶと思いますが、 JMXはアプリ起動時に-Dcom.sun.management.jmxremoteとか指定しないといけないし、 JMXほど大げさじゃなくてもっとカジュアルにモニタリングしたい時もあると思います。 そんなときにはjstatが使えます。 jstatを使ったモニタリングは下記に詳しいです。ここではjstatの結果をderived経由でGrowthforecastに送っています。 derivedがプラグインアーキテクチャになってGrowthFor
普段はサーバのメトリクス可視化のためにcloudforecastを使っていますが、某案件用に数秒単位で数十台のサーバのメトリクスを表示したいので、記事タイトルのような構成を作ってみた。 dstatでとった各種値の他に、nginxとmemcachedの情報も合わせて表示させています。 セットアップ もろもろのセットアップのメモ 監視サーバ まず、監視サーバにElasticsearchとkibanaをいれる。環境はCentOS6 $ sudo yum install java-1.7.0-openjdk $ sudo rpm -Uvh https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.x.x.noarch.rpm Elasticsearchは特に設定なく起動 $ sudo service
Developers Summit 2014 での発表（スライド）後、Chef のログを Fluentd に投げてる部分についてツイートをいただいたので、すこしまとめておきます。 GREEさんが昨日発表した，ChefのハンドラからFluentdに投げてMongoDBでデプロイか何かの情報収集してるの，どこかに記事とかあるのかな？ユースケース的には便利なのだけども #fluentd— Mr. Fiber (@repeatedly) 2014, 2月 14 Report (Exception) Handler Chef の Report(Exception) Handler という仕組みを使って、ログを投げています。 Report Handler: Chef の実行が成功した場合に実行されるハンドラ Exception Handler: Chef の実行が失敗した場合に実行されるハンドラ 詳し
リリースは永遠にされません！ 日本では色々なところでv11の噂がまことしやかに囁かれていますが， 俺がメインメンテナである限りv11がリリースされることはないので，諦めてv0.10.xを使ってください！ 以下まじめな話になります． v11が生まれた背景と現状 v11が生まれたのは1年以上前です．背景には，v10と呼ばれる今のバージョンがプロトタイプを兼ねたリリースであり， 「利用者のフィードバックを取り込んで，ダメな所をガッツリ書き換えて互換性を壊してメジャーバージョンアップや！」という流れがありました． しかし，v10は十分に柔軟でかつパフォーマンスも発揮しており，コミッタ陣はそれほどモチベーションがあったわけではありません． また，プラグインによって解決出来た問題も多く，v11が生まれた時ほどユーザから「v11が欲しい！」という要望は聞かれなくなりました． 当たり前ですが，ユーザからの
あるいは http://yugui.jp/articles/879 へのreply。 システム監視をfluentdに統合してしまうべきか否か システム監視は分けておいた方がいいと思う。分けるべき、とまでは言わないけれど。 それらの仕組みには相応の必要な機能セットがあり、それらは長い歴史の中で比較的決まった機能セットに収斂してきており、その収集・モニタリング・可視化・アラート通知など決まりきったパターンを様々な項目について停止なく行う必要がある。 Fluentdの各種プラグインを用いることで同じような機能は実現できる。そのプラグインのうち数割は自分が書いものだったりする。とはいえ各ホストのシステム監視までそこで行うことを想定して書いたかというと、もうちょっと高いレイヤでの監視・集計、つまりサービス単位などを目的としたものが多い。サーバ単位で行おうとしたときに設定が雑多なものになるのはおそらく
最近はlog collectionというと fluentd が話題らしいというので、少し触り始めている。 多少は分かってきたように思うので理解したことと、理解できていないところをまとめてみようと思う。 fluentdとは何か オフィシャルサイトには"tool to collect events and log"と書いてある。 要するに、サーバー群から継続的に情報を吸い上げるための仕組みを提供するdaemonである。 この「情報をかき集める」という枠組みは今時のサーバーサイドでは頻出パターンだ。 データベースサーバ、アプリケーションサーバー、フロントエンドキャッシュサーバー, ...と役割分担をするのが普通だし、 アプリケーションサーバーだって負荷分散のために複数インスタンスを持つのが当たり前だ。 そしてこれらサーバー群をきちんと管理するためには様々な情報をかき集めてきて一カ所に保存したり集
1. Board Meeting Treasure Agent Presentation Monitoring Service August 15th, 2013 - 3:30PM PDT Presented by Hironobu Yoshikawa – CEO Kazuki Ohta – CTO Rich Ghiossi – VP, Marketing Keith Goldstein – VP, Sales Kengo Hirouchi – Director, Japan Ankush Rustagi – Director, Marketing Founder & CTO 太田 一樹 @kzk_mover <k@treasure-data.com> www.treasuredata.com Copyright 2013 2. 会社概要 チーム概要 2011年12月創業、米国カリフォルニ
Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転
Blog Projects Jason Wilder's Blog Software developer and architect interested in scalability, performance and distributed systems. Fluentd vs Logstash Nov 19, 2013 · 6 minute read · Comments logging realtime fluentd logstash architecture Fluentd and Logstash are two open-source projects that focus on the problem of centralized logging. Both projects address the collection and transport aspect of c
最近、Fluentd + ElasticSearch + Kibana 3 の構成でお試し運用を始めました。 すると下記のような事をやりたくなったが Apache アクセスログをURL毎に集計したい DB スロークエリログをクエリ毎に集計したい 単純に文字列のフィールドで pie/bar チャートなどを利用すると、期待を打ち砕かれる（打ち砕かれた） ふむふむ、遅いクエリーには select, where, from が多いのか.... orz 見事に単語毎に集計されてしまった。 どうもトークナイズを止めるには ElasticSearch の multi field を利用するのが良さそう。（Solr で言うと copy field？） fluentd + ElasticSearch + Kibana + logstash フォーマットを下記の構成で利用する場合 fluentd のタグは m
お久しぶりです、髙橋＠SSTDです。 私は最近、SSTD（Sios Support for Treasure Data）としてTreasureDataさんと一緒にお仕事をさせて頂くことが非常に多く、勉強になることばかりです。 そういったこともあり、こちらのDevOps向けFluentd勉強会 at IPROSにも参加させて頂きました。 勉強会は三部構成で行われました。 特別講演 （トレジャーデータ 中川）導入編 （IPROS 竹内）実践編 （IPROS 外山） 1. 特別講演特別講演では、トレジャーデータの中川さんが、fluentdが生まれた理由から概要、更には各種プラグインについてまで、幅広くかつ少し深く話されました。 fluentdはなぜ生まれたか？データをいかに集めるかに関する決定的なソフトが無かった。 fluentd以前は、日毎のログ転送などを行っていたが、スループットの問題などが
Masahiro Nakagawa from Treasure Data gave a presentation on Fluentd, an open source log collector. Fluentd allows for reliable and structured logging, forwarding, and processing of data through its pluggable architecture. It can collect logs from various sources and output to different destinations using plugins. Common uses of Fluentd include log aggregation, monitoring, and analysis on large-sca
インフラ・システム運用を担当している平野です。 今回は「なんだかいつもと違う」をシステム監視で検知したいと思います。 通常のシステム監視では、監視項目に対して閾値を設け、 その閾値を外れたら異常値として検知する仕組みを導入します。 が、単純な閾値では片付けたくない監視項目もあります。 例えば、アクセス数なんかは平常時においても日中帯・夜間帯で伸び率が違い、 低い閾値設定すれば大量にアラートがあがりますし、高い閾値設定にすれば ちょっとした負荷ではアラート検知できません。 これらを解決するには、時間帯別に監視閾値を変更するなど、運用方法で考慮をいれると思いますが、 今回は「fluent-plugin-anomalydetect（異常値検出プラグイン）」を利用して 「なんだかいつもと違う」を検知したいと思います。 ◇監視内容 監視対象は当社のとあるサービスのApacheのアクセス数（PV）とし
fluentd の出力プラグイン、fluent-plugin-zabbix をリリースしました。 Github fujiwara/fluent-plugin-zabbix https://github.com/fujiwara/fluent-plugin-zabbix fluent-plugin-zabbix | RubyGems.org https://rubygems.org/gems/fluent-plugin-zabbix] 監視とメトリクス収集に Zabbix を使っているので、fluentd で収集した値を zabbix に送って扱いたかったのです。 挙動としては zabbix_sender でホスト側から送信するのと同様です。主に datacounter や flowcounter で集計した値を送るのを想定していますが、送信頻度に気をつければなんでも送れると思います。 作成
プラグイン¶ プラグインはFluentdの機能を拡張します。 ユーザーはFluentdに添付された標準プラグインを使ったり、独自のプラグインを作成することができます。追加プラグインを作成する方法の詳細については プラグイン作成 を参照してください。 Fluentdが適切に機能するためには、ユーザーは設定ファイルを使用して、少なくとも1つのインプットプラグインと1つのアウトプットプラグインを有効にしなければなりません。設定ファイルの詳細については 設定ファイル を参照してください。 Input plugin イベントの入力元を定義します。 インプットプラグインは通常スレッドと待機ソケットを作成します。それは定期的にデータソースからデータを取得するように実装することができます。注意： ユーザーが代替実装によってインプットプラグインを作成した場合には、この限りではありません。 Output pl
Fluentdの知られていない6つのこと 本当に知られていないかはわからないです。 公式にはあまり説明されていなかったり調べてもなかなか見つからないことが多いと個人的に思ったものを集めました。 機能や言葉の細かい説明は省いているのである程度使っている人が対象です。 out_copyはshallow copy Fluentdで最初に使うであろうビルドインされているout_copyプラグインですが、実はデフォルトではメッセージをdeep copyしないため意図しない結果になることがあります。 <match test> type copy <store> type record_modifier tag test.aa foo bar </store> <store> type retag tag test.bb </store> </match> <match test.{aa,bb}> ty
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く