サービスに寄り添うログ基盤 - ログ収集のその先に - はてな・ペパボ技術大会〜インフラ技術基盤〜@京都 http://hatena.connpass.com/event/33521/
Infrastructure Building DistributedLog: High-performance replicated log service At Twitter, we’ve used replicated logs to address a range of challenging problems in distributed systems. Today we’d like to tell you about DistributedLog, our high-performance replicated log service, and how we used it to address one of these problems. Last year, we provided an in-depth look at Manhattan, Twitter’s di
JDK8およびJDK8u20では、GCログに関連する2つの便利な機能が追加されている。いずれの機能も2014/8現在最新のJDK7 update 67 には含まれていないが、JDK7u80にてバックポートされる予定。 GCログにpidと日付を含める (JDK8より) JAVA_OPTS="$JAVA_OPTS -Xloggc:/var/log/wildfly/gc_%p_%t.log" => 実際のファイル名例 : gc_pid31455_2014-08-31_14-20-16.log.0GCログのフォーマットに%pを入れるとpid形式のプロセスIDが付与される。また%tを付与すると"_2014-08-31_14-20-16"のようにGCログファイルを作成した日付時分秒が追加される。かつてGCログはJavaを再起動すると同じファイルが上書きされて消えてしまうため、出力先を-Xloggc:g
「ログを集めて保存する」と言うのは簡単だけど，ログ収集の構成にはいくつか方法があり，勉強会などでちょくちょく聞かれるので，いくつかのパターンについて書く． 「俺はもうバリバリログ収集やってるぜ！」という人は多分すでに知っていることが書かれているので，タブを閉じて良い． ここではログコレクタにFluentdを想定しているが，他のログ収集プロダクトにも適用出来るはず． ただ，Fluentdはタグベースのルーティングを持ち，単体でもキューのように動作させることが可能で，既存のものより複雑な問題を解決しようとしているので，少し工夫が必要かもしれない． Fluentdそのものについては公式ドキュメントや，Fluentdとはどのようなソフトウェアなのかを参考に． クライアントから直接保存する いきなりFluentdを使わないパターン．JavaScript SDKを提供している解析サービスやモバイル端末
ngxtop parses your nginx access log and outputs useful, top-like, metrics of your nginx server. So you can tell what is happening with your server in real-time. ngxtop is designed to run in a short-period time just like the top command for troubleshooting and monitoring your Nginx server at the moment. If you need a long running monitoring process or storing your webserver stats in external monito
The Log: What every software engineer should know about real-time data's unifying abstraction I joined LinkedIn about six years ago at a particularly interesting time. We were just beginning to run up against the limits of our monolithic, centralized database and needed to start the transition to a portfolio of specialized distributed systems. This has been an interesting experience: we built, dep
普段の癖でSumallyを開いた時にWeb Inspectorを立ち上げるとconsole.logにメッセージがあることに気がついた。 なんだこれｗｗ 「We need couple of talented geeks. Are you the one? Check this out」 「探しものはなんですか？見つけにくいものですか？HTMLの中も、JSの中も、探したけれど見つからないのにまだまだ探す気ですか？それより僕と働きませんか？」 「コードやHTTPの通信を見て、まだまだ改善の余地あるな、と思ったあなた！僕らのチームに参加しませんか？」 「おおっと！Web Inspectorでチェックですか！そういう精神好きです。僕らのチームに参加しませんか？」 「We want you for our engineering team. Check this out」 うまいけど僕はそこで上記の
こんにちは。kimukimuです。 Storm0.9.0-rc系がリリースされてから正式版が出るのを待っている今日この頃ですが、 Storm0.9.0はApacheプロジェクトに入る前の最終リリースとなるということで、かなり大きなマイルストーンになりそうです。 そのため、検証のためまだ正式版が出るまでにはかかりそうです。 なので、正式版が出る前ですが、Storm0.9.0で追加／変更された機能を順に試してみることにします。 今回は、実際にStormを使っている方にとっては非常にありがたく感じる 「Topology毎のログ出力切り分け」について。 1.StormのTopologyログ出力はわかりにくい？ 実際にStormを使ったことがある方だとわかるかと思いますが、StormTopologyのログ出力先はわかりにくいです。 理由は、以下の２点。 どのTopologyがどのログに出力されている
ゴクロの大平です。 私にとって一番大事で替えの効かないミュージシャンはさだまさしさんですが、私にとってクラウドコンピューティングのサービスの中で一番大事で替えが効かないサービスはS3です。 多種多様なAPIを用いて柔軟にファイルの操作が出来る事や、”99.999999999％”と謳われている高い耐障害性、S3にあるデータをElastic MapReduceやRedshiftなどを用いて手軽にデータ解析を行える基盤が提供されていることなど、あまりに便利すぎてS3の代替となるサービスを探しだすのが難しい状態です。 もちろん多くのAWSユーザーが同じようにS3の便利さを享受していると思いますし、インターネット上でも多くのブログ等でその魅力が語られています。その中で本記事は既に存在する記事と似たような内容を書いてしまうかもしれませんが、弊社なりのS3の使い方についてご紹介したいと思います。 なお
SLF4J & Logback JavaのLoggerといえばlog4jで十分なのでlog4jを使ってる場合も多いと思います。 ログの出力性能は最終的にはディスクの速度で決まり、ログ出力の要件は案件が変わってもそれほど変化することもないのでlog4jの定義ファイルもコピペして再利用すればいいですし、新たなLoggerを使うのは手間でしかありません。 今回紹介するSLF4J & Logbackは既存のソースコードに手を入れること無く、しかも他のLoggingライブラリのログ出力も統合できます。 SLF4J SLF4Jはロギング実装を持たず、出力先毎のライブラリを入れ替えることで色々なLoggingライブラリに対応しているFacadeです。 SLF4Jには標準でplaceholderを使えるAPIもあるのでlog4jなどでよく書いてたlog出力前に不要な文字列結合を避けるためのif文は必要なく
今まではJavaでログ出力といえば、log4jだったが、最近ではlogbackも使いやすくなっている。 [追記] logbackはintra-martで採用されたりしているので既にかなりメジャーであると言える。 http://www.intra-mart.jp/apilist/v70/doclet/im_commons/jp/co/intra_mart/common/platform/log/rolling/ExtendedTimeBasedRollingPolicy.html [追記-終] logbackでログをファイル出力する場合は下記のAppenderクラスを使う。 FileAppender - ファイルへ出力する。 RollingFileAppender - FileAppenderを継承し、ログローテーションを提供する。 詳細はリンクを参照。 logbackではログローテーション
今回は、Linuxサーバのログについての話です。 環境はCentOS 6.4です。 ログが捨てられている？ ログファイルの /var/log/messages でこのようなメッセージを見つけました。 Jun 10 14:31:01 www rsyslogd-2177: imuxsock begins to drop messages from pid 573 due to rate-limiting なんだろうと思って、調べみました。 これは、rsyslogのrate-limitingという機能で、rsyslogが扱っているログファイルのメッセージが捨てられてしまっているという事がわかりました。 デフォルトでは200行まで出力すると、その後が捨てられるみたいですね。 大事なログが捨てられてしまっているとしたら困るな。。。 ということで、ログの切り捨てをしないように設定してみました。 rsy
We’re getting things ready Loading your experience… This won’t take long.
追記(2/17) 変換スクリプトを見せてほしい、という要望があったので、 https://gist.github.com/stanaka/4967403 に上げておきました。ltsvを読み込んでオプションで指定したフォーマット(デフォルト JSON)に変更します。 追記ここまで LTSVの盛り上りも収束してきていますが、サイズに関する懸念があがっていたので、確認してみました。 手近にあったアクセスログ 186万件ほどを対象に、 ssv .. Combined Log Formatの拡張で、ラベルなし (レスポンス時間とか10個ぐらいのフィールドを拡張しています) json .. ラベルあり ltsv .. ラベルあり の3パターンで試してみました。 まずは行数を確認しておきます。 % wc -l access_log.json 1861706 access_log.json未圧縮だと、 a
某所で 人間の脳には人の顔を識別するための特別な神経回路が最初から組み込まれていて、人の顔の違いを見分けたりというのが、他の図形よりも格段に高速に行えるようになっています。ということで、ログメッセージに顔文字を入れてみたら、なにこれすごいヽ(=´▽`=)ﾉ ってなったところ。 という発言をみかけたので、つくりました。 Log::Minimal::Emotional - https://gist.github.com/hirose31/4958764 「エモーショナル」はお好みなものに容易に再定義可能です。 #!/usr/bin/env perl use strict; use warnings; use utf8; use Log::Minimal::Emotional; $Log::Minimal::Emotional::EMOTION->{CRITICAL} = '⊂二二二（ ＾ω＾）
2013年02月08日19:00 カテゴリTipsLightweight Languages perl - Apache Combined Log を LTSV に びっぐうぇ〜ぶに乗る前の準備として。 Labeled Tab-separated Values (LTSV) Labeled Tab Separated Valuesノススメ - stanakaのブログ タグ「ltsv」を検索 - はてなブックマーク 移行にあたっては当然「過去ログどうするよ」という問題が発生するわけですが、一番使われているであろう (common|combined) log をLTSVに変換するスクリプトが、ざっと見回しても見つからなかったので。つーかススメるならこれくらい用意しようよ＞id:stanaka ltsv.orgのexampleもcombined_ltsvの方がいいと思う。 Enjoy! Dan
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
