A lightweight, ultra-fast tool for building observability pipelines
最近は協力プレイやPvPなどの「リアルタイムサーバー」を書くときは Go が主流になっているのですが、 Tornado を使ったシステムも健在です。 (以前の記事) 数人〜十数人程度の「部屋」を、1つの Tornado プロセスに複数もたせ、さらに一台のサーバーにその Tornado プロセスを複数置くことでCPUのマルチコアを活用する構成になっているのですが、最近各プロセスがログファイルを書く部分でブロックして応答性能が悪化するケースがあったので対策しました。 この記事ではその対策で行ったチューニングや、行わなかったチューニングについても紹介します。 ※なお、この記事は Tornado を題材にしていますが、似たような仕組みになっている node.js などの他の言語のフレームワークでも同じ事が言えるはずです。 前提知識 Tornado は epoll や select などのIO多重化
Python's built-in logging and other similar systems output a stream of factoids: they're interesting, but you can't really tell what's going on. Why is your application slow? What caused this code path to be chosen? Why did this error happen? Standard logging can't answer these questions. But with a better model you could understand what and why things happened in your application. You could pinpo
モバイルファースト室の @rejasupotaro です。 クックパッドでは、サービスをリリースしてログを収集して分析して改善してまたリリースして、というサイクルを素早く回すことでより良いものを作るということをウェブではやってきました。 クックパッドのサービス開発のフレームワークをモバイルアプリでも適用したいのですが、モバイルアプリにはウェブアプリと違ったロギングの難しさがあります。 今回はモバイルアプリのロギングの問題点とPureeというログ収集ライブラリについて話します。 モバイルアプリのロギングの難しさ ウェブアプリでは、基本的にはサーバー側でログを収集することができますが、モバイルアプリの場合は画面の制御はアプリ側で行われ、APIを介してデータを受け取るため、クライアント側でログを収集して送信する必要があります。 アプリのログを収集するのに、画面遷移をしたりタップするたびにサーバー
http://engineering.pinterest.com/post/84276775924/introducing-pinterest-secor 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 Pinterestが課金フローのログ収集に使っているSectorをオープンソースで提供しました。KafkaからAmazon S3などの長期保存用のストレージにログを送る仕組み (構成図) ですが、Amazon S3を利用した場合も、その結果整合性（アップロードされたデータがすぐ可視できる状態にならないケース & ファイルが一旦消えたようになり後ほど復活するケースが起こりうる。）に影響うけずに、データ消失がなく、スケール可能で、日付でデータのパーティションを区切ることもできるとのこと。 その信頼性を担保
Graylog v6.1: New Features Designed to Cut Complexity and Boost Efficiency Graylog v6.1 simplifies both security and IT operations, offering smarter ways to manage data and gain critical insights. With enhanced tools to reduce alert fatigue, cut storage costs, and streamline investigations, this release empowers teams to work more efficiently without sacrificing performance. Focus on high-risk thr
さきほど帰国。parse.comのメモに引き続き、re:InventでのLogglyのセッションについてもまとめておく。 【追記 2013/11/20 9:20】スライドがupされていたので貼っておきます。 要約すると、 お客さんから大量に送られてくるログをリアルタイムに捌くためのシステム 最初の設計ではSolrCloudを利用していた 第二世代ではElasticsearchを利用。システム全体としてElasticな環境に。 基本環境はKafka + Stormな構成 セッションの情報は以下のとおり。 ARC303 - Unmeltable Infrastructure at Scale: Using Apache Kafka, Twitter Storm, and Elastic Search on AWS This is a technical architect's case stu
前回の「疑問メモ: logbackで同一レベルの複数ログを異なる出力先に出したい」の解決編、「同一レベルのログを用途に応じて出し分ける」話の続きです。 師匠から参考になる情報をいただき、無事実現できました。ありがとうございます。 JaninoEventEvaluator を活用すればよいのですね。 JaninoEventEvaluator を使うには Janino libraryが追加で必要なので、準備します。 http://docs.codehaus.org/display/JANINO/Download から、最新版（本日時点では2.6.1）をダウンロードする zipを解凍して、出てきた janino.jar と commons-compiler.jar をビルドパスに通す 設定ファイル（logback.xml）を次のようにします。 <?xml version="1.0" encodi
（追記） この記事の解決編はこちら。http://d.hatena.ne.jp/torazuka/20120619/logback logback（http://logback.qos.ch/）でやりたいことができなくて困っているので、ちょっと整理します。 logbackは、Javaのロギングライブラリです。次のログレベルがあります。 TRACE DEBUG INFO WARN ERROR 今回やりたいのは、単に、「同一のログレベルだが、意味や用途の異なる複数のログを、それぞれ別の出力先に出す」というもの。 具体的にいうと、出力先は、ファイルとコンソールの2種類です。 作っているのはCUIのプログラムなので、ユーザがコンソールを目にします。ユーザにとって意味のある情報は、ログレベルINFOにまとめてあります。これらは、コンソールに出したいです。 一方、開発のためのDEBUGレベルのログや、
APIだけ別のログに出力する、なんて事も可能なのです〜 ログ出力をする時、◯◯◯な場合のみ、特定のログに出力したい時ってありませんか？ 例えばフリーワード検索した時のログを保存し、それをサイトマップxmlに登録する時等。 では早速フリーワード検索専用のロガーを用意し、フリーワード検索用のログを出力してみましょう！ ロガーを用意する 設定ファイルでロガーを指定する ロガーを用意する まずはロガーを作成します。 import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class MyLogger { private static Logger LOGGER = LoggerFactory.getLogger(MyLogger.class); public static void info(String test) { LO
SLF4J & Logback JavaのLoggerといえばlog4jで十分なのでlog4jを使ってる場合も多いと思います。 ログの出力性能は最終的にはディスクの速度で決まり、ログ出力の要件は案件が変わってもそれほど変化することもないのでlog4jの定義ファイルもコピペして再利用すればいいですし、新たなLoggerを使うのは手間でしかありません。 今回紹介するSLF4J & Logbackは既存のソースコードに手を入れること無く、しかも他のLoggingライブラリのログ出力も統合できます。 SLF4J SLF4Jはロギング実装を持たず、出力先毎のライブラリを入れ替えることで色々なLoggingライブラリに対応しているFacadeです。 SLF4Jには標準でplaceholderを使えるAPIもあるのでlog4jなどでよく書いてたlog出力前に不要な文字列結合を避けるためのif文は必要なく
スキーマレスなログデータの収集と集計のためのデザインパターン at http://www.zusaar.com/event/876003
2. 自己紹介 名前 • 荒木 靖宏（AWSのSAです） 中央線 • 吉祥寺と武蔵境に７年弱 ID • Twitter: ar1 • ar@debian.org 好きなAWSサービス • Amazon Virtual Private Cloud • AWS Direct Connect 4. 4 web server web server web server EC2で生成 S3に集約 EMRで集計 FluentdS3Plugin S3DistCp hiveorstreaming RDSに出力 /main?page=1 /main?page=2 /main?page=1 {“page”:”1”} {“page”:”2”} {“page”:”1”} page1 t 2 page2 t 1 page | count --------------- page1 | 2 page2 | 1
Welcome to Apache Flume¶ Flume is a distributed, reliable, and available service for efficiently collecting, aggregating, and moving large amounts of log data. It has a simple and flexible architecture based on streaming data flows. It is robust and fault tolerant with tunable reliability mechanisms and many failover and recovery mechanisms. It uses a simple extensible data model that allows for o
Search and analytics, data ingestion, and visualization – all at your fingertips.
追記(2/8 11:30) id:naoyaによる一連のまとめが【今北産業】3分で分かるLTSV業界のまとめ【LTSV】 - naoyaのはてなダイアリーにあります。 また、仕様などをまとめるために http://ltsv.org/ を立ち上げました。 追記ここまで Labeled Tab Separated Values (LTSV) というのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからfluentd、Apache Hiveまで幅広く便利に使えています。 ログフォーマットに期待されることは、 フォーマットが統一されている → 共通のツールで集計し易い 新しいフィールドの追加が容易 → サー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
