Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

検証を思いついた経緯 appサーバ側のforward設定で複数の<server>タグを管理したくない td-agentのconfigに影響されず、AWSメンテナンスやインスタンス障害の対応を行いたい アプリケーションが乗るappサーバと違い、td-agentクラスタは純粋に負荷を見極めやすいため、AutoScalingに適している fluentdのコミュニティで「TCPロードバランシングはユーザ側で試して欲しい」という状況で更新が止まっていた https://groups.google.com/forum/#!topic/fluentd/3ZuG_1dPovE td-agentクラスタ環境準備 1.環境構成 今回、VPC,SecutityGroup,AMIの作成方法は割愛。 以下の環境を準備する。 2.appインスタンスのtd-agent設定 <source> type forward <
これはなにか RDSのSlowLogをSlackに通知したかった。 AWSのAPIで download-db-log-file-portion があったが通知するには使い勝手が悪かったので MySQLのテーブルにSlowLogを保存して、それをFluentdからSELECT & Clear をすることにした。 この記事はMysqlの設定なので、他のDBの場合はよしなに変更してください。 使ったもの fluent-plugin-slack : https://github.com/sowawa/fluent-plugin-slack fluent-plugin-rds-slowlog : https://github.com/kenjiskywalker/fluent-plugin-rds-slowlog RDSの設定 Parameter Group slow_query_log : 1 l
注意:この記事の最新版があります 新しいバージョンのElasticsearch,Kibanaを試したい方は、こちらの記事を参照してください。 (2014/8時点の最新版で作る)Vagrantだけあればいい、5分でできるElasticsearch,Fluentd,Kibanaのお試し環境構築 背景 以前Kibanaについて書いた記事がいくつかありますが、Elasticsearchが1.0になったり、KibanaがいつのまにかElasticsearchの一部になっていたりと、ここ半年ぐらいでも、いろいろと変化がありました。 環境構築についても書いたことがありますが、その際はVMを3台使用するような構成だったので、ちょっと試してみるには重たい内容でした。 この記事では最新のElasticsearch環境を構築し、ApacheのアクセスログをFluentd(td-agent)経由でElastics
おしらせ Fluentdは入っていませんが、こちらの記事だと新しめのEs,Kibana環境が作れます。 入門記事:Elasticsearch1.4.0とKibana4.0.0の環境構築 Fluentd込みの環境も欲しいというかたがいれば、最新版にアップデートしつつ作るかもしれないので、コメントなどでお気軽にお声がけください。 まえがき 以前に書いた「Vagrantだけあればいい、5分でできるElasticsearch,Fluentd,Kibanaのお試し環境構築」がたまにストックされていてうれしいのですが、半年前の記事なので、2014/8/29時点のバージョンを使用してVagrantfileを書き換えました。 この記事で紹介するVagrantfileでは以下のバージョンを使用しています。 Ubuntu: 14.04(ubuntu/trusty32) Elasticsearch: 1.3.2
前書き @sawanoboly さんによるOhai版記事のSpecinfra Host Inventory版的なやつです。 踏襲したタイトル付けたらメッチャ長いタイトルになったw 何気なく軽量で実行方式(ローカルとかSSH越しとか)が選べて取り回しの良いインベントリ収集ライブラリは何かに使えるんじゃないかなーと思いつつ、ItamaeはChef Server的な存在が居ないし、こういう感じでインベントリを集めてみるのはどうでしょうかというコンセプトモデル的な何かです。 構成 Azureの無料枠が余っていたのでAzure上でやってみましたが、 慣れてないので複数のVMを纏めて扱うのが厳しそうだったので、 普通に大きめのVMをWEBコンソールから立てて、その中にDockerで複数の環境を構築しました。 詳細 構成方法 Chef test-kitchen + kitchen-docker_cli
Dockerイメージは2つあります。ひとつはNginx側に動くセンサーfluentd-agent( https://github.com/liubin/fluentd-agent )です。もひとっつはローグを集約するElasticSearchとデータ可視化するKibanaのかたまりes-dashboard( https://github.com/liubin/es-dashboard )です。 なおDockerHubにて公式イメージも用意されているので、下記のコマンドはそのまま実行できます(はずです)。 環境: CentOS 7 Fluentd 0.10.61 JDK 1.7.0 ElasticSearch 1.5.0 Kibana 4.0.2 1.Dashboardの起動 es-dashboardは1つのコンテナに動けます。また、コンテナが使えるリソースが制限されている場合、Elasti
What is fluentd? ログ収集をプログラマブルに実施し、状況に応じた柔軟な対応が実現できるソフトウェア ログの管理を「インプット」「バッファ」「アウトプット」という3つの層に分けて管理 fluentdは内部で各ログデータに対して「タグ」を付与し、管理 fluentdではログの内容(レコード)がJSON形式になっている そのため、アプリケーション側でのパースが容易であるというメリットがある Why Fluentd? : ログ管理への要求 ログの多様化・肥大化への対応 ログ情報を基にした分析の必要性 fluentdの設定方法 インストール方法 様々なインストール方法がある RPMパッケージからFluentdをインストールする (Redhat Linux) DEBパッケージからFluentdをインストールする (Debian / Ubuntu Linux) DMGパッケージからFlu
このエントリーはドワンゴアドベントカレンダー17日目のエントリーです。 ストリーム処理エンジンのNorikraについて、最近聞くことが増えてきました。 使ってみたい方は結構いるのではないでしょうか。 とは言え、「ストリーム処理を試してみたい、環境構築してやってみよう」と思っても、JRuby入れてNorikra入れて、fluentd入れてNorikraとのin/outの連携して、集計結果を格納する為にElasticsearch構築して、Kibanaから見れるようにして、認証機構や改廃の機構も入れて...あ、ストリームソースも用意しなきゃ...となって、そこそこ手間が掛かります。 一揃いの環境構築するのは面倒、という方向け(自分向け)に、手軽にコマンド一発で立ち上げられる環境を作りました。 Norikraそのものについては、こちらの記事が素晴らしかったです。 http://hase.hateb
Treasure Agentをさらに使いやすく ご存知の方も多いかと思いますが、トレジャーデータ社では、out_tdプラグインを使うことで、Fluentdから簡単にデータを流し込めるようになっています。これはHeroku上でも動くようになっており、heroku-td-agentとして公開されています。 ただこれ、意外と面倒くさいです。具体的には Treasure Dataのアカウントを持っていることが前提。 そしてAPIキーをメモ。 GitHubのHerokuアプリをクローンしてきて bundle install... あああああああああああああああああああ、やってられるかボケえぇぇぇ!!!! これではいかん。せっかくHerokuという、ソフトウェアのデプロイを抹殺してくれたプラットフォームにいるんだ。その恩恵を100%受けてやろうじゃないか。 #出ましたTreasure Agent He
と書くとNoneパーサ(まったくパースせず、一行そのまま"message"というキーにぶち込むパーサです)が走ります。 これらの実装に関しては/lib/fluent/parser.rbを読むと幸せになれるかもしれません。 ちなみにデフォルトでは以下のパーサが入っています: format apache_error: Apacheエラーログパーサ format apache2: Apache2アクセスログパーサ。apacheってのもあるが違いがわからず… format syslog: いわゆるsyslogをよしなにパース。 format json: インプットをそのままJSONとみなしてパース。 format tsv: いわゆるtsv。keysを指定することでJSONに変換。 format ltsv: みんな大好きltsv。 format csv: みんな大嫌いcsv。やはりkeysを指定。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 近年、自分の中で集計/可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計/可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ?」「Graphiteってなんじゃ?」「InfluxDBってなんじゃ?」 など、このツール達は一体何なんだろう…?というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか? というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く