AWS Summit Tokyo 2016 Developer Conference (2016/06/03)

まずはFluentdコミュニティの皆さん、おめでとうございます!!! Googleを中心に開発されているオープンソースのDockerジョブスケジューラKubernetes (k8s)、それにGoogle Cloud Platformのログ収集サービスGoogle Cloud LoggingのGoogle Compute Engine用ログコレクタとして、Fluentdが標準採用されました。もうひとつおまけに、fluent-plugin-bigqueryをフィーチャしたソリューションページも、あと1か月くらいでcloud.google.comにて公開される見込みです(これは私がいま仕上げ中)。 順番から行くと、まずはCloud Loggingチームで以前からFluentdの採用が検討されていて、正式採用を決定、それに影響される形でk8sチームもFluentdを採用した流れです。私も微力ながら
nanapiでは社内のチャットツールに、Slackを導入しています。Slackの便利なところはintegration周りで、要するに他のツールとの連携が非常にし易いんですね。そういった、Chatを中心にした業務効率化を最近ではChatOpsと呼んだりします。 http://nanapi.co.jp/blog/2014/07/24/nanapi_chatops/ ChatOpsの重要な点はコンテキストを共有できる点ですよね。「○○ってエラーログが出てるよ」みたいな情報を直接誰かに伝えるのではなく、ログが出ているという状態をChatを経由して同じものを見ることで、説明が非常にラクになります。 ほかにもデプロイをHubot経由で指示したり、ステータス取得をしたりなど様々な使い方がありますがやはり重要なのは同じ画面を皆が見ているということですね。そういった点がChatOpsの大きなメリットとしてあ
「ログを集めて保存する」と言うのは簡単だけど,ログ収集の構成にはいくつか方法があり,勉強会などでちょくちょく聞かれるので,いくつかのパターンについて書く. 「俺はもうバリバリログ収集やってるぜ!」という人は多分すでに知っていることが書かれているので,タブを閉じて良い. ここではログコレクタにFluentdを想定しているが,他のログ収集プロダクトにも適用出来るはず. ただ,Fluentdはタグベースのルーティングを持ち,単体でもキューのように動作させることが可能で,既存のものより複雑な問題を解決しようとしているので,少し工夫が必要かもしれない. Fluentdそのものについては公式ドキュメントや,Fluentdとはどのようなソフトウェアなのかを参考に. クライアントから直接保存する いきなりFluentdを使わないパターン.JavaScript SDKを提供している解析サービスやモバイル端末
Treasure Dataのサービスはクラウド上でどう構築されているのか(後編)~July Tech Festa 2013 Treasure Dataといえば、日本人がシリコンバレーで創業したベンチャーとして知られている企業。そのシニアソフトウェアエンジニア中川真宏氏が、7月14日に行われたJuly Tech Festa 2013の基調講演で、同社がクラウド上で構築したサービスについてそのアーキテクチャを中心に解説を行っています。 この記事は「Treasure Dataのサービスはクラウド上でどう構築されているのか(前編)~Japan Tech Festa 2013」の続きです。 データを解析する「Plazma」の仕組み データを解析するところでは「Plazma」と呼ぶ、Hadoopのエコシステムとカラムストアなどを組み合わせたものを用いています。
はじめに エンジニアの@ryooo321です。 よろしくお願いします。 今回は弊社で運用中の全アプリで利用している行動分析プラットフォームについてご紹介したいと思います。 2012年の6月に作ってから、約9ヶ月ほど運用しています。 特徴 ・手がかからないデータストア ・さまざまな問い合わせ対応で利用できる柔軟なクエリ ・機敏なMap/Reduceによる集計 ・集計結果をCSVやグラフで可視化 目的 ・ユーザーの問い合わせに効率的に対応し、アプリの企画・開発に集中するため ・ユーザーの行動を抽象化・可視化することでPDCAの質を向上させるため 行動ログのフロー 1. ユーザーからRuby on Rails製のソーシャルゲームにリクエスト 2. Railsからローカルのfluentdにログ出力(fluent-logger-ruby) 3. ローカルのfluentd
Fluentdは、Ruby製のログコレクタだ。コードは公開されている。 様々なログを構造化して一元管理することができ、収集と解析へのハードルを大きく下げてくれる。 インストールもプラグイン開発も簡単。日本語の資料も多い。 その資料も様々あるが、プラグインを見るならこれが最良だと思う。必要な情報がよくまとまっており、必読といえる。 Big Data入門に見せかけたFluentd入門 from Keisuke Takahashi データの確実な転送を実現するバッファ機能については、池田大輔さんのブログが詳しい。さて、Fluentdはデータを収集してくれるが、保存はしてくれない。 永続化にはデータベースが必要だ。 そこで、Riak。 Basho社がスポンサードするErlang製分散型KVS。これもOSSだが、契約によって商用サービスが受けられる。 これがまたエッジ立ちまくってて
Fluentdを触るようになって、いろんなログをfluentdに 渡すように試行錯誤している最中。 td-agent.conf、fluent.confを用意するときに任意のjson形式にするために 正規表現を用いてformatを書く必要があるんですが、formatの作り方というかデバック方法について どういう手順に作ると良いのか情報がネット上に見当たらず試行錯誤中。 もっと良い方法を教えてもらいたいので、今やっている方法を晒してみる。 そもそもの疑問、どうやってformatを作るのか たとえばfluentd関連の情報を調べてると、 #fluentd で maillog を読み込んで MongoDB に投入 - 酒日記 はてな支店 format /^(?<date>[^ ]+) (?<host>[^ ]+) (?<process>[^:]+): (?<message>((?<key>[^ :
こんにちは。@jedipunkz です。 {% img /pix/kibana3.png %} 前回の記事で Kibana + elasticsearch + fluentd を試しましたが、ツイッターで @nora96o さんに “Kibana3 使うと、幸せになれますよ!” と教えてもらいました。早 速試してみましたので、メモしておきます。 前回の記事。 http://jedipunkz.github.io/blog/2013/09/07/kibana-plus-elasticsearch-plus-fluentd/ 前半の手順は前回と同様ですが、念のため書いておきます。 前提の環境 OS : Ubuntu 12.04 Precise (同じ方法で 13.04 Raring でも出来ました) 必要なパッケージのインストール 下記のパッケージを事前にインストールします。 手順を省くために
ゴクロの大平です。 私にとって一番大事で替えの効かないミュージシャンはさだまさしさんですが、私にとってクラウドコンピューティングのサービスの中で一番大事で替えが効かないサービスはS3です。 多種多様なAPIを用いて柔軟にファイルの操作が出来る事や、”99.999999999%”と謳われている高い耐障害性、S3にあるデータをElastic MapReduceやRedshiftなどを用いて手軽にデータ解析を行える基盤が提供されていることなど、あまりに便利すぎてS3の代替となるサービスを探しだすのが難しい状態です。 もちろん多くのAWSユーザーが同じようにS3の便利さを享受していると思いますし、インターネット上でも多くのブログ等でその魅力が語られています。その中で本記事は既に存在する記事と似たような内容を書いてしまうかもしれませんが、弊社なりのS3の使い方についてご紹介したいと思います。 なお
シリコンバレーの日本人ベンチャーとして注目度の高いトレジャーデータのCTOである太田一樹氏とのインタビューが実現した。CEO芳川裕誠氏の家のベランダと熱海の温泉で始まった会社の起業物語やサービスのポイントなどを聞いた1時間のインタビューをほぼ加工なしで掲載する。 Hadoopのポテンシャルを感じ始めたときに声をかけてもらった TECH.ASCII.jp 大谷(以下、TECH 大谷):太田さんというと、Hadoopの人というイメージがありますが、そもそものバックグラウンドを教えてください。 トレジャーデータ 太田氏(以下、TD 太田):はい。もともと私のバックグラウンドはHPC(High Performance Computing)のエリアで、19歳くらいからあまり学校にも行かず(笑)、プリファードインフラストラクチャという会社のCTOをやらせていただきました。あと、米オレゴンの国立研究所で
The document discusses the Fluentd logging system. It includes an explanation of how Fluentd buffers and queues log data before outputting it. The emit method is used to add log data to a chunk, and if the chunk limit is reached a new chunk is created and added to the queue. Once data is in the queue it can be output by the configured plugin.
少し前にログの話を書いた http://d.hatena.ne.jp/naoya/20130219/1361262854 ときに、Treasure Data については後日にもう少し詳細に書くと言ったので書くとしよう。 近頃 Treasure Data (以下、時折 TD) という名前をちらほら聞いたことがある人は多いのではないかと思います。「ビッグデータのクラウドサービスである」とか「日本人が創業したシリコンバレーのベンチャー」、あるいは Yahoo! 創業者の Jerry Yang が投資したとか、Fluentd と何か関係があるといった文脈などなど。 けど、具体的に Treasure Data がどういうサービスで、どういう機能を持っていて、どんな場面で利用されるものなのかはまだあまり良く知られていないかもしれない・・・ようにも見える。今日はその辺から少し紹介していこうかなと思う。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く