ログ環境とDevOps ~一休.comでの事例~
Norikra Meetup #2 参加レポート - 無印吉澤
イベントページ: Norikra meetup #2 : ATND 僕自身はNorikra使ったことないのですが、周囲には使っている人がいて評判も良いので、他の人のユースケースも聞いてみたい、あわよくば自分とこの業務にもねじ込みたい、と思い参加してきました。期待通り、ユースケースを色々聞けて面白かったです。 今回聞いたNorikraのユースケースには、大体以下のような共通点がありそうに感じました。 ステータスコードごとの件数を集計するために使っているところが多い Norikraでの集計結果は、Fluentdを介して、他のツール（MackerelやらZabbixやら）に渡す Norikraが落ちたら落ちたで諦めるという割り切りで使う（冗長化はcold standby程度） 同じデータをデータベースにも流し込み、Norikraはあくまで速報値やアラート用に使う メモリを大量に積んだマシンを用意
fluent-plugin-file-alternativeで出力したログをin_tailで読み込む - Qiita
Fluentdでは出力側が詰まると、バッファがたまっていき、ある程度するとバッファが詰まり、今度はそこにForwardしているバッファが詰まり、数珠つなぎにバッファが詰まっていく。大量にたまらないときは出力側が流れ出したら、復帰してくれてとても便利だ。memoryバッファにしておくと、プロセスを再起動しないといけないときに消えちゃうので、fileバッファにするのがいまのところ王道設定である。 しかし、出力先で障害が発生し長引くと、バッファが詰まっていって回復するまでにバッファがあふれてログを取りこぼしてしまったり、いざ回復しても、今度はFluentdからバースト的にログが流れてきてまた詰まってしまったりする。また、出力先が何かの障害でログが失われてしまったとき、復旧する手段がなくて困る。 そこで、Fluentdからいろんな時に出力するときに、一旦ファイルにログを書き出して数週間ためておいて
『サーバ／インフラエンジニア養成読本 ログ収集～可視化編』出版記念！執筆者が語る大講演会！ レポート［セッション編］ | gihyo.jp
『サーバ／インフラエンジニア養成読本 ログ収集～可視化編』出版記念！執筆者が語る大講演会！ レポート［セッション編］ 9月9日、シナジーカフェ GMO Yoursにて『サーバ／インフラエンジニア養成読本 ログ収集～可視化編』出版記念！執筆者が語る大講演会！が開催されました。主催はトレジャーデータ株式会社と株式会社インテリジェンス「dots.」です。本稿では、このイベントの模様をレポートします。 司会進行はトレジャーデータの池内さんです。 池内さんが今回のイベントの経緯を話した後、本書『サーバ／インフラエンジニア養成読本 ログ収集～可視化編』を執筆した4人の著者から、一人あたり持ち時間15分間の発表がありました。 鈴木健太氏『サービス改善はログデータ解析から』 鈴木健太氏は本書の特集タイトルと同じ「サービス改善はログデータ解析から」というタイトルで発表しました。 鈴木さんはVOYAGE GR
最新インフラエンジニア技術勉強会に行ってきました #dli_infra | こえむの編集後記
昨夜、ドリコムさんで行われた「最新インフラエンジニア技術勉強会 〜Fluentd, Elasticsearch,Chefの実践実例〜」に足を運んできました。 タイトルにもありますように、Chef, モニタリング, Fluentd, そして elasticsearch が使われている現場の情報を伺える機会となりました。 それでは、いつものようにノートをアップしておきます。 概要 2014-05-23 ドリコム 本社 (目黒アルコタワー) 19:30-20:00 ひらしー ドリコムのInfrastructure as Code 20:00-20:30 mickey Winning the metrics battle 20:30-21:00 外山 寛 Fluentd プラグイン開発講座 21:00-21:30 yoshi_ken MySQLと組み合わせて始める全文検索エンジン「elastics
InfluxDBとGrafanaとfluentdで、twitterデータのリアルタイム集計・可視化 - Qiita
require 'influxdb' => true influxdb = InfluxDB::Client.new :username => 'root', :password => 'root' => #<InfluxDB::Client:0x007fb424481ec8 @async=false, @hosts=["localhost"], @initial_delay=0.01, @max_delay=30, @open_timeout=5, @password="root", @port=8086, @read_timeout=300, @time_precision="s", @use_ssl=false, @username="root"> influxdb.create_database('qiitademo') => #<Net::HTTPCreated 201 Crea
fluentdとDataDogでアクセスログをグラフ化 - so what
DatadogはMuninとGrowthForecastを合わせたようなモニタリングサービスで、主に『エージェントをインストールしてサーバ情報をグラフ化』と『APIでmetricを送信してグラフ化』をしてくれます。*1 fluentdと相性が良さそうなので、アクセスログをDataDogに投げたりするためのプラグイン（とパッチ）を書きました。 fluent-plugin-datadog Pull Request 修正版gem ※2/22 17:19注) fluent-plugin-ddをリリースしました fluent-plugin-unit-time-filter 参考: http://so-wh.at/entry/2014/02/08/fluent-plugin-unit-time-filter ※2/09 20:45注) 0.1.0をリリースしました ※2/17 14:26注) flue
Fluentdが流行る理由がいま分かる、10の実践逆引きユースケース集 - Y-Ken Studio
ログデータを活用してビジネスに役立てようという最近のトレンドは理解できる。 しかし、なぜログ収集ソフトウェアのFluentdがこれほどまで話題になるのか、不思議に感じている方もいるのではないだろうか。単にログデータを収集するならばsyslog-ngやrsyslogで十分ではないかという意見もあるだろう。 それらは既存のログシステムを置き換えるプロダクトであり、Fluentdのそれとは根本的に異なる。Fluentdは、既存のログシステムに手を入れることなく新たにログの収集を行い、ストリームデータ処理を実現するプロダクトなのである。 一般的にログデータはサーバの数だけ分散しており、それを定期実行処理で収集するということだけでも、なかなか骨の折れる仕事である。さらに集めるだけでなく、日々増え続けるログデータを活用できる形に加工してしかるべきデータストアに保管するということに挫折した方もいるのでは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
excale.net
excale.net