Railsでのサーバサイドログ収集に悩むあなたに送る - 分析・デバッグ用が捗るrack-action_loggerというgemを作った話RubyRailsrackBigQuery こんにちは！株式会社LITALICOでエンジニアをしております石田です。 『LITALICO Engineers Advent Calendar 2016』 19日目の記事となります。 前回は、ナウでイケてる格安の分析基盤&BIツールをGoogle sheetsを中心に構築した話を書きました。 その際に、サーバ側の、「ユーザ行動ログ」に関しては次回の記事でとなっていたので、この記事で紹介させていただきます。 スマフォアプリ・ゲームを開発する際にユーザの行動ログを取得するために、Rails用のgemであるrack-action_loggerを作りました。 まだまだ完成したばかりなのですが、一部サービスの本番に投入
こんにちは、Web アプリケーションエンジニアの id:KGA です。 去る、8月31日(水) にはてな東京オフィスのイベントスペース SHIBAFU において Hatena Engineer Seminar #6 〜インフラ編〜 @ Tokyo を開催いたしました。約1年ぶりの開催となりましたが、平日夜の開催にもかかわらず多数の方にご来場いただき、昨今の、インフラ技術や Web オペレーションエンジニアの働き方への注目度の高まりを肌で感じることができました。ご来場いただいたみなさま、誠にありがとうございました。 冒頭では新 CTO id:motemen よりご挨拶させていただきました 今回は、前回から少し間を置いての開催となってしまいましたが、今後はもう少し頻度を上げて定期的に Engineer Seminar を開催していく予定です。次回のテーマも固まりつつあるので、詳細が決まり次第お
27. 27 host:::1<Tab>ident:MTkyLjE2OC41Ni4xMDE0MDkxMTk2ODQ<Ta b>user:1<Tab>time:[08/Apr/2015:10:00:00 +0900]<Tab>Request:GET /sample HTTP/1.1<Tab>status: 200<Tab>size:5039<Tab>referer:foo.com<Tab>agent:Mozilla/5.0 (iPhone; CPU iPhone OS 8_0 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12A365 Safari/600.1.4<Tab>attr:Mjg0ZmUyMzk0Yzg0ZGIzZTIzYTI3N2ExY zhm One Line 28. 28 h
We are thrilled to announce the general availability of the Cloudera AI Inference service, powered by NVIDIA NIM microservices, part of the NVIDIA AI Enterprise platform, to accelerate generative AI deployments for enterprises. This service supports a range of optimized AI models, enabling seamless and scalable AI inference. Background The generative AI landscape is evolving […] Read blog post
github.com Gorとはlog replayを自動化するためのツールです。go製。 log replayとは、log(httpのトラフィック)をreplay(再生)することで、よりリアルなデータ(プロダクションのトラフィック)をうまいこと使い、より効果時なテスト・確認をしようという考えからなるものです。ざっくりと。 たとえば、プロダクションのトラフィックをステージング環境に転送することでステージング環境にデプロイした実装のテストをしたり、転送するトラフィックの割合を制限しつつ負荷テストをしたり、あるいはtcpdumpのようにトラフィックをファイルに書き出し、tcpreplayのようにそれを再生したりと。 テストがないコードで、テストの回数が制限されているようなiscon5予選のときに使えたのではとgorが気になってたので試してみたメモです。（gorの作者の方がfluetndのアーキ
![Gorを試してみたmemo - [WIP] karahiyoの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/f5723f081a67248f5240b24631ea84d68fa1e2c4/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fk%2Fkarahiyo%2F20151128%2F20151128174658.png)
こんにちは。インフラストラクチャー部 セキュリティグループの星 (@kani_b) です。 主に "セキュリティ" や "AWS" といったタグのつきそうなこと全般を担当しています。 Fluentd などのデータコレクタ、Kibana やその他 SaaS による可視化、Kafka, Kinesis, Spark などのストリーム処理といった様々な分野で「ログの処理」がホットですが、アプリケーションのログ (行動ログなど) に関する話題が多くを占めています。 そうしたログの他に重要なのが OS や各種ミドルウェアのシステムログです。これらはトラブルシューティングであったり、セキュリティ上の問題を見つけたり、といったことに使われますが、最低限 syslog でどこかに集約しているだけ、といった例をよく見かけます。 これらのログをきちんと検索可能にし、分析することで、今まで気づかなかったような問
unicornはconfで timeout 20 とかやっとくと、20秒以上かかったらそのworkerが殺される。それはいい。問題はその殺され方にあって、タイムアウトしたunicorn workerはmasterにKILLシグナルで強制的に殺される。KILLで殺されてしまうと、worker側でtrapして安全に終了処理をすることができない。 一番困るのは、Railsのloggerは（production環境のデフォルトだと）リクエストが終了するまでバッファリングしているので、リクエストの途中でKILLされてしまうとloggerがflushされない。つまり、unicornのタイムアウト時には、リクエストのログは一切production.logには出力されない。異常時のログが出ないとか、まじで困ると思うんだけど、みんなどうしてんだろ。 これに対処するためにはunicornのコードに手を入れるの
通常は my.cnf に以下の設定をして restart すればいいのですが、稼働中のサービスの場合、再起動したくないこともあります。 slow_query_log=1 long_query_time=3 そういうときは、set global すれば動的に有効にできます。 mysql> set global slow_query_log=1; mysql> set global long_query_time=3; が、なぜか long_query_time の値が反映されません。デフォルトの 10秒のままです。 mysql> show variables like 'slow_query%'; +---------------------+-------------------------------------------+ | Variable_name | Value | +---
mitchellh/panicwrap Go言語でpanicが発生したらどうしようもない．普通はちゃんとテストをしてそもそもpanicが発生しないようにする（もしくはトップレベルでrecoverする）．しかし，クロスコンパイルして様々な環境に配布することを，もしくはユーザが作者が思ってもいない使いかたをすることを考慮すると，すべてを作者の想像力の範疇のテストでカバーし，panicをゼロにできるとは限らない． panicが発生した場合，ユーザからすると何が起こったか分からない（Go言語を使ったことがあるユーザなら「あの表示」を見て，panicが起こったことがわかるかもしれない）．適切なエラーメッセージを表示できると良い．開発者からすると，そのpanicの詳しい発生状況を基に修正を行い，新たなテストケースを追加して二度とそのバグが発生しないようにしておきたい． mitchellh/panicw
さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた 先のエントリ「論理削除はなぜ「筋が悪い」か」で書いたとおり、データベースに対して行われた操作を記録し、必要に応じて参照したり取り消したりしたいという要求は至極妥当なものですが、多くのRDBは、そのために簡単に使える仕組みを提供していません。 daifukuは、RDBに対して加えられた変更をトランザクション単位でRDB内にJSONとして記録するためのストアドやトリガを生成するコマンドです。 % daifuku dbname tbl1 tbl2 > setup.sql のように実行すると、指定されたテーブル（ここではtbl1とtbl2）にセットすべきトリガや、更新ログを記録するためのテーブル「daifuku_log」を生成するCREATE TABLEステートメントなど、必要なSQL文をset
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
