Pascal〜Puree + ngx_lua + Fluentd + BigQueryでつくるメルカリのログ分析基盤〜 | メルカリエンジニアリング
エンジニアではなくプログラマと呼ばれたい@cubicdaiyaです。今回はメルカリのログ分析基盤のお話です。 メルカリにおけるログデータ分析 メルカリでは初期の頃からログデータの分析をサービスの成長にとって重要なタスクとして位置づけ、そのための基盤作りに取り組んできました。ログの種類はいくつかありますが、中でも代表的なのがアプリケーションサーバで出力されるアクセスログやアプリケーション固有のログです。これらのログはサイズが大きいので効率良くログデータを転送するための工夫が必要になります。そこで活躍するのがFluentdです。 大雑把に説明するとアプリケーションサーバで出力されたログはFluentdから最終的にBigQueryやTreasure Dataといったクラウドサービスに転送されます。(上記の図は非常に簡単に済ませていますが、実際にはログの中継やフィルタリングをするためのFluent
TCP serverをSSL/TLS化するのに nginx の stream_ssl_module/stream_proxy_module が便利 - たごもりすメモ
最近 Fluentd の通信プロトコルまわりをアップデートするためにあれこれいじっている*1んだけど、これはおおむね fluent-plugin-secure-forward がサポートしていた内容を Fluentd 組込みの forward plugin でもサポートしますよ、というものになる。 んで問題なのが secure-forward は SSL/TLS での接続のみしかサポートしてなかったんだけど forward では生の TCP で通信する*2ので、本当に secure-forward と forward それぞれの実装間で互換性が保たれているのか、直接的には確認する手段がない、ということになってしまう。 TCP server の SSL/TLS 化 一方世の中には SSL/TLS ターミネータという機能があって、たとえばロードバランサなんかがこの機能を持っている。何をやるかと
高速ファイル/メッセージ転送 K2HFTFUSE の紹介
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、Technical Yahoo の中谷です。 今回は、Yahoo! JAPANからオープンソースとして公開した高速ファイル/メッセージ転送システムの K2HFTFUSE の紹介をします。 K2HFTFUSEは、確実で高速なファイル/メッセージ転送を低コストで実現するために開発されたシステムです。 K2HFTFUSE（K2Hash File Transaction by FUSE-based file system）とは、FUSE（Filesystem in Userspace）によるユーザースペースでのマウント機能を利用したファイル/メッセージ転送システムです。 K2HFTFUSEは、仮想ファイルシステムを提供し、マウ
ITエンジニアの幸せな未来とは？ - さくらインターネット創業日記
Something went wrong, but don’t fret — let’s give it another shot.
Wikipedia の作り方 / How to make Wikipedia - *iroi*
こんにちは。アプリケーションエンジニアの id:mechairoi です。 この記事は はてなエンジニアアドベントカレンダー2014 の10日目です。 昨日は id:hatz48 さんの Mackerel と fluentd でサービスの状態を可視化する - Hatena Developer Blog でした。 今日は Wikipedia の作り方について紹介します。 完成イメージ 必要なもの スチロール半球 450m/m【ディスプレイ用品・デコレーション】 出版社/メーカー: ドガメディア: この商品を含むブログを見る ２つ必要。 モンブラン 発泡スチロールカッターA型 出版社/メーカー: 清水製作所メディア: Tools & Hardware クリック: 2回この商品を含むブログを見る スチロールを切るのに使います。 プリンタ、 白の塗料、 セロテープ、 やわらかい鉛筆、 はさみ、のり
モバイルアプリのログ収集ライブラリ「Puree」をリリースしました - クックパッド開発者ブログ
モバイルファースト室の @rejasupotaro です。 クックパッドでは、サービスをリリースしてログを収集して分析して改善してまたリリースして、というサイクルを素早く回すことでより良いものを作るということをウェブではやってきました。 クックパッドのサービス開発のフレームワークをモバイルアプリでも適用したいのですが、モバイルアプリにはウェブアプリと違ったロギングの難しさがあります。 今回はモバイルアプリのロギングの問題点とPureeというログ収集ライブラリについて話します。 モバイルアプリのロギングの難しさ ウェブアプリでは、基本的にはサーバー側でログを収集することができますが、モバイルアプリの場合は画面の制御はアプリ側で行われ、APIを介してデータを受け取るため、クライアント側でログを収集して送信する必要があります。 アプリのログを収集するのに、画面遷移をしたりタップするたびにサーバー
pixivで行っているバグフィックスデーについて紹介します - pixiv inside [archive]
こんにちは、ISUCONのために2ヶ月ほどgoをみっちり書いてた@edvakfです。練習した甲斐あって2位になることができました。 バグフィックスデーについて pixivではPHPのアプリケーションのエラーはすべてfluentd経由でMongoDBに入れていて、管理画面からスタックトレースなどを見られるようにしています。 デプロイ直後などに見たことのないエラーが出ていないかをここで確認したりします。もちろん自分の入れたバグやクリティカルなものであればすぐに直します。 たまにこのチェックをすり抜けて、クリティカルではないけれども１日数個ぐらい出てるようなものが溜まってしまうことがあります。 pixivでは１ヶ月に１回程度、こういう類のバグを潰す日として「バグフィックスデー」というのを実施しています。 流れ 参加者は普段pixivのサーバーサイドを書いているエンジニア6〜8名程度で、その日ター
![pixivで行っているバグフィックスデーについて紹介します - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/e88164758f97cbf5f9058ae6425fab2668580069/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fe%2Fedvakf%2F20141027%2F20141027113237.png)
多言語対応User-Agentパーサライブラリ Woothee 1.0.0リリース: OS versionの出力をサポート - たごもりすメモ
地道にバージョンアップを繰り返しているUser-Agentパーサライブラリの woothee ですが、このたび 1.0.0 をリリースしましたのでお知らせいたします。 http://woothee.github.io/ 今回は前からやろうやろうと思ってたOSバージョンのparseをサポートしました。特にスマートフォン(iOS/Android)のバージョンが気になる人が多いようで、手元でもあったらいいなというケースが多くなってきたため、えいやと入れました。 ただし今回はあまり時間がなかったので、とりあえず自分で使いそうな以下の言語のみリリースしています。 Java Perl Ruby Javascript (npm) PHP (10/28追記 対応されました) 以下の言語についてはまだ対応していません。誰かPull Requestを送るといいと思います。 Python Golang 現状こん
ログ集計／時系列DB／可視化ツールの調査結果 - Qiita
近年、自分の中で集計／可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計／可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ？」「Graphiteってなんじゃ？」「InfluxDBってなんじゃ？」 など、このツール達は一体何なんだろう…？というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか？ というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の３つに分けられそうです。 ログ収集/集計 時系列DB（＋API）の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu
Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita
「BigQueryは120億行を5秒でフルスキャン可能」は本当か？ 先日、kaheiさんがGoogle BigQuery（Googleクラウドの大規模クエリサービス）について、こんなエントリを書いていた。 とにかくパフォーマンスがすごい。（Fluentd Meetupでの）プレゼン中のデモで、ディスクに収められた5億件のデータをSQLでフルスキャンするのに3秒しかかからない。9億件のデータを正規表現を含んだSQLでスキャンしても、7秒で終わる（これ、記憶がちょっとあいまい。もう少しかかったかも）。これには驚いた。佐藤さんがGoogleに入社して一番驚いた技術が、一般公開される前のBigQueryだったと言っていたが、その気持ちはわかる。 From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluent
Logging Technique for HTML5 Single Page Application with Fluentd
@Fluentd Meetup 2014/05/13
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.inouetakuya.info/entry/2014/12/08/214435