Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
この記事は「エムスリー Advent Calendar 2016」の 10日目の記事です 今年の5月に無償版が提供されている Google Data Studio ですが、使った人たちのコメントを見ているとドキュメントを読まなくても、いきなり使えるというメリットがあったものの、SQLを書けないというデメリットがあって、 他の無料ツールの Re:dash (無料だとサーバーが必要)の方がデータ分析的に使えるかなと思っていました。 しかし、最近この記事を読んでいて、逆に SQLクエリを書かなくて良い ということが (ディレクターに丸投げできるという意味で) 最大の魅力ということに気づきました。ということで、 Google Data Studio を使うことで、ディレクターがよく見たい指標ランキングTOPに挙がるであろうユーザーのアクセスログを可視化したので、ログ収集部分からまるっと解説します。
Treasure Agentをさらに使いやすく ご存知の方も多いかと思いますが、トレジャーデータ社では、out_tdプラグインを使うことで、Fluentdから簡単にデータを流し込めるようになっています。これはHeroku上でも動くようになっており、heroku-td-agentとして公開されています。 ただこれ、意外と面倒くさいです。具体的には Treasure Dataのアカウントを持っていることが前提。 そしてAPIキーをメモ。 GitHubのHerokuアプリをクローンしてきて bundle install... あああああああああああああああああああ、やってられるかボケえぇぇぇ!!!! これではいかん。せっかくHerokuという、ソフトウェアのデプロイを抹殺してくれたプラットフォームにいるんだ。その恩恵を100%受けてやろうじゃないか。 出ましたTreasure Agent Her
Googleがオープンソースとして公開したKubernetesは、コンテナ型仮想化ソフトウェアのDockerを管理するツールです。開発プロジェクトにはDocker、RedHat、IBM、VMware、マイクロソフトなど多数の企業が参加を表明しています。 Kubernetesは、複数のDockerコンテナにまとめてアプリケーションをデプロイし、設定を行い、稼働状況を監視、管理し、サービスへのトラフィックをルーティングするなど、クラスタとしてDockerを運用するための多くの機能を備えています。 このKubernetesで使われる標準のログ収集ツールとして、オープンソースのfluentdが採用されたことが明らかになりました。下記はそれを伝えるGoogle佐藤氏のツイート。 fluentdがKubernetesの標準ログコレクタに採用されたぜ!!! https://t.co/V8VDM4IE7e
I am pleased to announce that Treasure Data just open sourced a lightweight Fluentd forwarder written in Go. Creatively christened as Fluentd Forwarder, it was designed and written with the following goals in mind. A simple forwarder for simple use cases: Fluentd is very versatile and extendable, but sometimes you need something simple. Fluentd Forwarder is meant to be an alternative for such case
目的 Kibana で Heroku アプリのログを可視化したい。ただし、レスポンスタイムとかは New Relic でも見れるので、ここではアプリが出力したらログを可視化する方法を紹介する。 また、今回、アプリからの出力を可能な限りに簡単にするために、アプリからは Heroku の STDOUT に出力するだけで、ログを Kibana サーバに送信できるようにしてみた。 具体的にはこう。(Ruby の場合) 出力の形式は、Treasure Data addon の方法 を真似ている。 puts "@[tag.name] #{{'uid'=>123}.to_json}" これで、tag.name が fluentd の tag 名に、それに続く JSON 文字列が送信するデータとして処理される。 環境 Amazon EC2 上に Kibana サーバを構築 OS は Ubuntu 13.1
Scenario You have an application written in Rails and want to collect data into MongoDB, HDFS, Elasticsearch, et. al. for analytics/search. Logging directly into MongoDB/HDFS/Elasticsearch is not highly recommended since synchronous logging is slow/potentially hazardous for the backend. You can build asynchronous logging into your application, but Fluentd can sit between your application and backe
こんにちは。夏休みに長野に行って居酒屋で馬刺しをたらふく食べていたら 地元のおっさん人生の大先輩の絡み酒に付き合わされた祖山です。 4月に入社して以降、サーバサイドのWeb開発やスクラムの導入、サイト内検索の改善など様々な業務に 取り組んでいますが、最近の大きな案件としては、アクセスログ解析基盤の整備がありました。 nginxのアクセスログを分析しやすい環境を作るため、ElasticsearchとBigQueryにログを蓄積し始めたのですが、 その際に一番のキモとなるのは、みんな大好きfluentdです。 今回は、我々ハウテレビジョンがどのようにアクセスログを収集、保存しているのかについて、fluentdの設定を中心にご紹介します。 アクセスログ収集の目的 現在の我々のサービス環境を考慮すると、アクセスログの収集には下記2つの目的が存在します。 アクセス情報をもとにユーザーの行動を解析 閲
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog saegusa2017-04-16Yoshihiro was a network engineer at LINE, responsible for all levels of LINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to apply LINE's technology and business goals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回
「ログを集めて保存する」と言うのは簡単だけど,ログ収集の構成にはいくつか方法があり,勉強会などでちょくちょく聞かれるので,いくつかのパターンについて書く. 「俺はもうバリバリログ収集やってるぜ!」という人は多分すでに知っていることが書かれているので,タブを閉じて良い. ここではログコレクタにFluentdを想定しているが,他のログ収集プロダクトにも適用出来るはず. ただ,Fluentdはタグベースのルーティングを持ち,単体でもキューのように動作させることが可能で,既存のものより複雑な問題を解決しようとしているので,少し工夫が必要かもしれない. Fluentdそのものについては公式ドキュメントや,Fluentdとはどのようなソフトウェアなのかを参考に. クライアントから直接保存する いきなりFluentdを使わないパターン.JavaScript SDKを提供している解析サービスやモバイル端末
https://github.com/fluent/fluentd-ui 開発者としてはあれが足りてない、こうなってると良さそう、などなど理想が次から次へと明確に見えてくるのでなかなか満足できないものですが、今のところ概ね好意的な評価を頂けているようでよかったです。 @kzk_mover, @repeatedly, @kiyototamuraの御三方には大変お世話になりました。社としてのあれは社としてあれされるだろうということでそれ以外のあれを書いときます。 制約について 珍しいものとして以下の2つがある。 RDBMSは禁止(別デーモンのpostgresqlとかは論外。sqliteもwindowsで少し怪しい) coffeescriptは禁止(ユーザーがnode.jsを持ってない可能性は充分ある) RDBMSがないことでバージョンアップとマイグレーションについて悩まなくて済んだ、などのいい
July 9, 2014 TL;DR Monitor the state of the Fluentd by Sensu. SensuでFluentdの状態を監視する 利用するソフトウェア(Using Software) fluentd Sensu check-fluentd-monitor-agent.rb 監視設定(Monitoring Settings) Sensu’s Configuration Example Sensuの設定例 check_fluentd_monitor_agent.json { "checks": { "check_fluentd_monitor_agent_retry": { "command": "/etc/sensu/plugins/check-fluentd-monitor-agent.rb -w 5 -c 10 -m 'retry_count'",
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億
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く