CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
去年のJANOGで別の方が発表された内容とダダ被りではあるものの，折角なのでメモ程度に書いておく． 概要 データセンタネットワークやバックボーンネットワークの運用をやっていると，インターネットに出入りするトラフィックの内訳 (どのISP向けのトラフィックが多いのか，どの回線にトラフィックが乗っているか，等) を見たいことがよくある NetFlowをNorikraで解析し，その結果をGrowthForecastに流し込むと，トラフィックの内訳をそこそこ手軽に見ることができる 定常的なモニタリング用途以外に，突発的なトラブルシューティングにも使えていろいろ便利 背景 自前でAS (Autonomous System) を運用している事業者では，トラフィックのコントロールの観点から，「どのAS向けのトラフィックがどのくらいあるのか」「このASとはどの回線を使って通信しているか」といった情報を知り
リアルタイム集計・可視化環境(Norikra+Kibana4+Elasticsearch+Fluentd+Nginx)をfig一発で気楽に立ち上げる。ElasticsearchDockerNorikraKibanafig このエントリーはドワンゴアドベントカレンダー17日目のエントリーです。 ストリーム処理エンジンのNorikraについて、最近聞くことが増えてきました。 使ってみたい方は結構いるのではないでしょうか。 とは言え、「ストリーム処理を試してみたい、環境構築してやってみよう」と思っても、JRuby入れてNorikra入れて、fluentd入れてNorikraとのin/outの連携して、集計結果を格納する為にElasticsearch構築して、Kibanaから見れるようにして、認証機構や改廃の機構も入れて...あ、ストリームソースも用意しなきゃ...となって、そこそこ手間が掛かりま
はじめに 世間的には「fluentdで集計 ≒ Norikra!!!!!」という流れで、それに対して一石を投じる気のかけらも私には無いわけですが、Norikraを用いるまでもない軽微な処理を実行する場合fluentdのプラグイン単体で処理を完結したいケースもあり、そしてNorikraが若干重厚に映るケースもあります（JRuby!! Esper!!!） ということで、集計が行えるようなfluentd pluginについてまとめてみます。チョイスは僕の独断と偏見です。 ユースケース fluentdの基本的なユースケースは、inputとして入力をしたデータをoutput先にrelayする、というものです。そして集計処理は、多くの場合output先のシステム内、もしくはシステムに蓄積されたデータを用いて別のシステムを用いて行う事が多いと思います。 (ex. HDFSに保存したログデータをHiveを
どーも、れもんです。みなさんNorikra使ってますか? えっ使ってない? まぁストリーム集計処理っていうのがなかなか使いどころ難しいですものねー。よっぽど速報値が必要な場面じゃないと出番がないし、ぼくもインストールしたけどほぼ使ってないという今日この頃です。 ということで! 今回はNorikraを使うとっかかりとして、最近リリースしたサービスのユニークユーザ数をリアルタイムに出したいなぁというお題をNorikraでやってみることにしました。 もともとそのサービスではネイティブアプリにGoogle Analytics SDKが入っててそれを使えば直近5分のリアルタイムユニークユーザ数は見えているのですが、サーバ側でもそれを計測したいということで、そこをNorikraでやってみることにしました。 理由は、よく出来たアプリだと幾つか画面を遷移していても通信しなくてよいように作られていて、クライ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
