AWS Summit Tokyo 2016 Developer Conference (2016/06/03)
概要 fluentd でサービスの情報を転送し、Kibana で分析したい これまでの過去データを一度に放り込みたい データの件数が合わない Kibana でエラーが発生する 各種設定を見直すことで対応可能 背景 長い長いミーティングに疲れ、集中力を擦り減らしたアナタは 無意識のうちにブラウザを起動していました。 去年まで勤めていた会社の同僚がシェアした記事が目に止まります。 「fluentd + Elasticsearch + Kibana で今どきのログ分析！」 感化されやすいアナタはおもむろに VM を立ち上げ環境を構築します。 Web サーバから吐き出されたログはオシャレでイイ感じにチャート化され、 満足したアナタは VM を落とし、再び仕事に戻りました。 しばらく経ったある日のこと、ふと気づきます。 「ログだけじゃなくて、ユーザ属性の分析にもコレ使えそう。」 毎度オレオレ管理ペー
From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluentd Meetupのデモでは9億件を7秒程度で検索していたが、BigQueryの真の実力はこれより1〜2ケタ上だからだ。ちょっと手元で少し大きめのテーブルで試してみたら、120億行の正規表現マッチ付き集計が5秒で完了した。論より証拠で、デモビデオ（1分16秒）を作ってみた： From The Speed of Google BigQuery これは速すぎる。何かのインチキである（最初にデモを見た時そう思った）。正規表現をいろいろ変えてみてもスピードは変わらない。つまり、インデックスを事前構築できないクエリに対してこのスピードなのである。 価格も安い。さすがに120億行のクエリは1回で200円もかかって気軽に実行できなさそうであるが、1.2億
Fluentdの監視については、 Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例や、 #fluentdの死活監視を ping message + ping message checker で - tagomorisのメモ置き場がとても参考になります。 これらの情報を大いに参考にさせていただいて構成した環境の監視設定についてまとめます。 当方環境 ・各APPサーバなどからはfluent-agent-liteによってログとping messageが送られてくる ・受信側のFluentdサーバはシングルノード、シングルプロセス ・APPサーバ、Fluentdサーバ、Nagiosサーバはそれぞれ別のサーバ 監視方針 監視はなるべくシンプルにしたいので、こんな感じにしています。 ・TCP/UDPポート監視 ・プロセス監視はしない ・通知はNagiosから プロセス
Regular Expression Test String Custom Time Format (See also ruby document; strptime) Example (Apache) Regular expression: ^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$ Time Format: %d/%b/%Y:%H:%M:%S %z
リリースしてはいたものの手元でちゃんと使っていなかったプラグインふたつ、をいよいよちゃんと使いはじめた。そのついで(？)にちゃんとテストを書いたりREADMEを書いたりしたので、せっかくだからここにも書いておく。 fluent-plugin-notifier Fluentdで流通するメッセージを相手に数値範囲や文字列検査(正規表現)により異常を検出しアラート(を示すメッセージ)を出してやろう、というプラグイン。 tagomoris/fluent-plugin-notifier · GitHub fluent-plugin-notifier | RubyGems.org | your community gem host 使いかたはたぶん例を見ればわかる……んじゃないかなー。こんな。 <match apache.log.**> type notifier <def> pattern apac
こんにちは、fluentd歴2週間です（挨拶） 会社でGitlabとChatWorkを使ってるので連携してみました ゴール Gitlabのリポジトリが更新されたらChatWorkに通知を流す fluentdに至るまでに考えた構成 gitlabのwebhookを受けてChatWorkに通知するアプリを作る 問題点 GitlabとChatWorkが密結合 汎用性がない オレオレアプリ増やしたくない gitlabのwebhookをJenkinsで受けてChatWorkに通知 webappの部分がJenkinsになっただけ 問題点 ChatWorkに通知するだけでジョブ追加するのは大げさ 通知対象のリポジトリ増やす度にジョブコピペつらい fluentdを使ってみることにした fluentdは使ったことなかったけどどんなものかはなんとなく知ってた webhookを受けることは出来るけどChatWor
fluentdを使ってみたいけど、「JSONでシリアライズしなくていいのに・・・生でいいのに・・・」と思ってなかなか使い出せないというケースはままあるのではないでしょうか。 こんなときに困ってしまうからですよね。 rsyncやscpで毎日深夜にやってくる生ログを解析するスパゲッティスクリプトたちを使えなくなってしまう アプリケーションサーバにログをパースさせるための負荷をかけたくない それでも使ってみたい、現存の古臭い解析機構をアクティブにしたまま、徐々にfluentdによる先鋭的なログ解析を始められたらいいなと思っている方、 fluent-agent-lite と td-agent で、fluentd を小さくはじめてみたらいいと思います。 結論を先に言うと、fluent-agent-lite + fluent-plugin-file-alternative + fluent-plugi
fluentdのログ 流行に敏いみなさまは既にfluentdのクラスタを組まれているかと思います 1 が、fluentd自体のログはどうしてますでしょうか？ サーバーに直接入って確認している？せっかくログアグリゲーターを組んでいるのだから、fluentd自体のログもfluentdで管理しませんか。 fluentdでは以下の様な match を定義しておくと、自身のログをメッセージとして流すようになっています。 <match fluent.**> ... </match> 流れてくるメッセージはこんな感じ。 fluent.info: {"message":"force flushing buffered events"} fluent.warn: {"message":"emit transaction failed"} fluent.error: {"message":"forward e
昨年構築してからずっと安定稼働していたfluend(td-agent)が年明けくらいから下記のエラーが出て連日停止してしまって、 ちょっとハマったのでメモしておく。(ハッキリとした原因は掴めてないですが) 利用しているtd-agentのバージョンはtd-agent-1.1.18-0.x86_64。 現象 fluent.logには下記が出ていて、機能が停止している。 2014-01-09T20:28:59+09:00 fluent.error {"error":"#<Fluent::BufferQueueLimitError: queue size exceeds limit>","error_class":"Fluent::BufferQueueLimitError","message":"forward error"} 2014-01-09T20:28:59+09:00 fluent.w
アプリケーションのログファイルをfluentdでS3に転送、S3からRedshiftに読み込んで集計、という流れはもはや鉄板パターンです。 これまではTSV形式で蓄積されているケースが多かったと思うのですが、2014年03月25のリリースでCOPY文がJSONフォーマットに（一応）対応したこともあり、とりあえずJSONで が最新のベストプラクティスになります。 おさらい 〜 fluentdを使ってJSON形式でS3にログを蓄積する 必要なもの fluentd本体 fluent-plugin-tail-ex fluent-plugin-s3 fluent-plugin-s3-alternative s3-alternativeを使うのは、 output_include_time false output_include_tag false 上記の設定を有効にして、純粋なJSON形式のフォーマ
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
〜 大晦日に秒間 1 万ユーザを捌くためにやったこと (ログ収集編) 〜今回は、大晦日のイベント用に EC2 インスタンスを複数台立ち上げておいて、年が明けたタイミングで全て Terminate してしまう予定でした。 ただ、Terminate した際に、そのままログも一緒に消えてしまうと何かあったときに困るので、Nginx のログやアプリケーションのログの収集に Fluentd を使い、とりあえず S3 にぶっ込んでおくことにしました。 Fluend は標準では 1 つの CPU コアしか使ってくれないので、複数の CPU コアをもっているサーバで動かす際は、マルチプロセス化することで CPU を効率的に使えるようになります。 具体的には、ログ集約用のサーバは in_multiprocess プラグインで複数のポートから受信できるようにしつつ、送信側は out_forward プラグイン
fluentdを多段構成にして、mongodbに出力するところでハマったのでメモ。 上の構成のように、各サーバにfluentd + out_forwardを置き、集約するログサーバにfluentd + out_mongoでmongodbに出力している場合に、上段のfluentdでbuffer_chunk_limitを10mより大きい値にしていると、エラーになることがあります。 まず、out_mongoでbuffer_chunk_limitを10m以内にしないといけない理由は、fluentdからMongoDBへ連携する際の注意点 #fluentdを参考にしてください。 ここで多段構成の場合、上流の buffer_chunk_limitが大きいと上流から大きなサイズのデータの塊が流れてくることがあります。それを受けとったfluentdはそれをそのままoutput pluginに流す実装となって
fluentd Document Data Import from PHP Applications PHPからログをfluentdにインポートするには「fluent-logger-php」というライブラリを使用します。 fluent-logger-phpはPHP 5.3以上でないと使用することができないので注意です なにはともあれ、fluentdがインストールされていないとどうにもならないので下記エントリを参考にサクッとfluentdをインストールして下さい CentOSにfluentdを導入 fluentdのconfigファイルを編集し、ログの受取り口を設定します # fluent-logger-php test用に追記 <source> type unix path /var/run/td-agent/td-agent.sock </source> <match fluentd.te
これはFluentd Advent Calendar 14日目の記事です。 私は現在、VOYAGE GROUPの子会社であるadingoで、DMP cosmiの開発をしています。今日はcosmiでのfluentd利用の話をしようと思います。 DMPについて 過去に勉強会でアドテクまわり及びDMPについて話したのでそれを貼っておきます。ざっというと、いい感じにいろんなログを受けいられるようにして、それらをモニタリングしながら整理して使えるようにする、という役割をもったプロダクトです。 Head First Ad Technology and DMP http://www.slideshare.net/suzuken/head-first-ad-technology-and-dmp どこで使っているか ほぼ全てです。構成としては ログ収集サーバ | | out-forward (roundro
目次 1. まえがき 2. pairsとシステム 3. kibana サンプルシステム構築 3.1 サンプルのサーバー構成例 3.2 fluentd 3.3 Elasticsearch 3.4 kibana 4. kibanaを使う 5. エウレカでの実際の活用事例 6. 〜終章〜 1. まえがき 1.1 対象者 気軽にデータ収集をしたいと思っている開発者 基本的なLinuxコマンドの理解がある方 1.2 この記事を読んで分かること fluentd x Elasticsearch x kibana を用いたアクセスログの収集・計測方法 pairsのシステム概要 私の好きなアニメ pairs高速化チーム 1.3 この記事を読んでも分からないこと 本格的な統計解析 恋人の作り方 1.4 自己紹介 はじめまして。サービス事業部の森川と申します。 エウレカには今年のはじめ頃にJoinしました。 エ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
