前置き こんにちは。bayashi です。みなさん、意識は高まっていますか？ 僕は上々です。今回は拙作の App::Rolling というモジュールを紹介いたします。 といっても、絶賛開発中のモジュールなので、ここで紹介したインターフェースは変更されるかもしれません。 つまり、人柱、大歓迎で㌃ 何をするモジュール？ App::Rolling は、標準入力を世代管理されたファイルに書き出す目的で作っています。例えば、いつ起きるかわからない適当な通信のTCPダンプを取得したい場合、ひとつのファイルにひたすら書き出して捉えるのは、なんとなく気が引けますよね。そんなとき、App::Rolling に同梱される roll コマンドを使えば、好きな間隔で、好きな世代だけローテートさせながら、ファイルに書き出すことができるようになります。 通常、以下のようにダンプとったりしますね。 $ /usr/sbi
こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました！ Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です：イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め
追記 CPANにアップしました http://search.cpan.org/dist/Log-Minimal/ /追記 アプリケーションサーバでエラーが起きていたり、レスポンスが遅かったりする場合に、Operation Engineer(インフラエンジニア)がまず見るのは、エラーログです。エラーログにでているメッセージを手がかりに原因を探ります。 サーバでエラーが起きている時には、データベースに接続ができなかったり、外部のAPIからレスポンスが得られない、またプログラムのBugが原因となっている場合もあるでしょう。またエラーにならなくても、複数台あるデータベースのスレーブサーバうち一台が落ちて接続をretryしていたり、APIのレスポンスが遅い際にはサーバ全体のパフォーマンスが低下します。 エラーログに障害の原因を探る情報があれば、Operation Engineerは素早く対応を開始で
このブログをご覧のみなさんは、おそらく何らかの形で開発作業、あるいは設定作業の経験をお持ちだと思います。みなさんは、日々の作業の記録をどのように取られているでしょうか?もし、作業ログを取る習慣がない、あるいは忙しすぎて作業ログをとることに気が回っていないのであれば、作業ログを確実に取る習慣をつけることをお奨めします。この習慣は、きっとあなたの作業の信頼性を上げ、作業効率向上に貢献するはずです。 ●作業ログがなぜ必要か まず最初に、なぜ正確な作業ログをとる必要があるのでしょうか? その答えは簡単です。再現性を確保するためです。自分が不具合報告を受ける立場で考えてみてください。もし、部下やユーザから「動きません」や「バグです」という報告を受けた場合、すぐに問題があると判断するでしょうか? ほとんどの人は、まず報告されている状況を正確に理解したうえで判断したいと考えるのではないでしょうか? ●作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
