gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
AWKのススメ - クックパッド開発者ブログ
はじめまして。インフラチームの菅原といいます。 今年の7月に入社してから、コンソールとにらめっこする毎日を過ごしています。クックパッドのようにアクセスの多いサイトのサーバを扱うことが今まで無かったので、いろいろと勉強になることが多いです。 さて、インフラチームではサーバの状況をモニタリングして、サーバに問題がないかを常に把握するようにしています。そのため日常的にtailでログを追いかけているのですが、そんなときはAWKが非常に便利なことに気付き、最近はかなりAWKにハマっています。 今回は絶賛マイブーム中のAWKの活用例をご紹介したいと思います。 なぜAWKなのか？ 残念ながらAWKの知名度はあまり高くないようで、社内でも「なぜRubyでやらないのか？」と聞かれることがありました。僕も入社するまではcutの代わりぐらいにしか使っていなかったのですが、あるときログ出力の整形に使って以来、AW
Linuxサーバのディスク容量減少アラートが飛んできた！ってときにどう対処するか - たごもりすメモ
完全に このエントリ のネタパクりです。すいません。 何に使われてるかわかったもんじゃないマシンとか開発用サーバとかだと超巨大なバイナリとか置いてあるかもしれませんが、プロダクション用のサーバでそういうことは無いとしましょう。 その場合、原因はだいたい以下のどれかです。www/appとdbが別マシンに分かれてる場合は更に絞り込めますね。 wwwサーバやappサーバ ログ 圧縮してあるが保存世代数が多くて厳しいケース 圧縮し忘れてるケース 圧縮どころかローテーションすら忘れてて1ファイルどかんと存在するケース ローテーションがうまくいかなくて deleted ファイルなケース tmpデータなど(app) キャッシュサーバのディスクキャッシュ dbサーバ データ実体 (ib_data) バイナリログ ログの場合でも、ディスク上のどこにログが書かれてるかは色々なパターンがある可能性がありますね。
「fluentd」と「Storm」の比較について - Tous Les Jours 攻防記
まず、両者はかなり性質の異なるプロダクトなので、以下の比較は筋違い。 筋違いであることを前提に、ストリームデータ処理プラットフォームとしての両者を比べてみる。 基本情報 fluentd http://fluentd.org/ 今をときめくログコレクター/イベントアグリゲーター。Rubyで実装されているが軽量高速。 RPC基盤ではなく、その下のレイヤーに位置するプロダクト。 Storm http://storm-project.net/ 分散RPC基盤。ストリームデータ版MapReduce風フレームワーク。Java+Clojureで実装されている。 概要については、下記のスライドがとてもわかりやすかった。 Twitterのリアルタイム分散処理システム「Storm」入門 ストリームデータ処理で何をするのかについて ストリームデータ処理のニーズについて、自分が理解している範囲での簡単な説明。 典
GrowthForecast.plで自分ロギングしてみた - by edvakf in hatena
こちらのブログではお久しぶりです。 定期的に数字を投げておけば勝手にいい感じでグラフ化してくれるツールが欲しい…！と思っていたら、GrowthForecastというのがPerl界隈で流行ってると教えてもらいました。 http://kazeburo.github.com/GrowthForecast/ 早速使ってみようと思ったのですが、MacではRRDtoolが落ちるため、色々やった挙句諦めてVirtualBoxにインストールしてようやく使えました。 使い方については既に色々書かれているので省略しますが、グラフを作り始める設定とかも不要でHTTPでPOSTし始めれば今すぐにでも数値ログを取れるという、まさに思った通りのツールでした。 ところで最近はライフログにハマっています。 パソコンを触っている時間を記録しておいて、何時に眠りに落ちたのか分かるようにしたかったので、GrowthForeca
LTSV が行指向な Key-Value フォーマットで捗る話 - naoyaのはてなダイアリー
引き続き LTSV について。Text::LTSV はやってることは単にタブの split でしょうもないのだけど、せっかく作ったんだし何か利用方法はないかなと考えた。 LTSV のログは欠点があってそのままでは見づらいこと。 Text::LTSV でハッシュになるのだから、YAML とかで出力したらどうなるか試してみよう。さらに、YAML に色づけする YAML::Tiny::Color というのがあったぞ。 #!/usr/bin/env perl use strict; use warnings; use Project::Libs; use YAML::Tiny::Color qw/Dump/; use Text::LTSV; while (<>) { my $hash = Text::LTSV->parse_line($_); print Dump $hash; } こんなスクリプ
LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー
ここ数年のデータ解析の重要性の高まりから、ログに関するソリューションが方々で活発に探求されている昨今でございます。ウェブサーバーの単純なアクセスログをそのまま保存するではなく追加情報を添加してみたり、あるいはアプリケーションから直接ログを吐いてそれらをデータウェアに投げ込んで･･･というのも当然のように行うようになりましたね。 しかしあまり自由度のない access_log の combined フォーマット。さてどうしたもんか･･･ ここで id:stanaka の登場です。 Labeled Tab Separated Valueというのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからflue
Plack::Middleware::AccessLog でありがちな罠 - blog.nomadscafe.jp
Plack::Middleware::AccessLog は Apacheライクなログが残せる便利ミドルウェアなんですが使う上で一つ注意点があります。 use Plack::Builder; builder { enable "AccessLog", format => "combined"; sub { die }; }; これで、500エラーのログが残ることを期待するかもしれませんが、実際は記録されません。 例外がMiddleware層を飛ばしてServerまで伝わる為で、何らかの形で例外を補足してあげる必要があります。 例えば、Plack::Middleware::HTTPExceptions builder { enable "AccessLog", format => "combined"; enable "HTTPExceptions"; sub { die }; }; もしく
複数のサーバから一斉にファイルを収集するのにpslurpが便利 - Glide Note
以前、ブログに書いて以来、活用しているpsshとpscpなんですが、 付属コマンドのpslurpについてはすっかり忘れて全く利用していなかったんですが、 同僚の刺身さんが結構活用しているというのを聞いて、改めて使ってみると大変便利！ Parallel sshで複数のホストへ同時にコマンドを実行する | Glide Note - グライドノート 環境はSL6.1です。 pslurpの使いどころ 複数のサーバからaccess.logなどのログ、my.cnfといった設定ファイルなどの同名ファイルを持ってくる場合 DNSラウンドロビンや、ロードバランサを利用していてアクセスログが分散している場合 通常何も考えずscpとかで持ってくるとファイルが上書きされてしまうので、 ホスト毎にファイルを分けて管理したい場合にpslurpが活躍します。 pipを利用してpsshの導入 2012年なんでeasy_i
Webalizerの見方 ---ahref.org
サンプル 月の統計 日ごとの統計 時間ごとの統計 ヒット数ランキング/URL別、転送量別、Entry Pages別、Exit Pages別、サイト別、転送量 リファラー（どのページからのやってきたか） 検索文字列（Yahoo等の検索エンジンからどういう検索文字で検索されたか） ユーザエージェント（ブラウザ、OS） よくご覧になるのは「月ごとの統計」「日ごとの統計」「リファラー」「検索文字列」だと思います。 「リファラー」はどのサイトからリンクされているのかがわかり、また「検索文字列」はyahooなどの検索エンジンで、検索時に打ち込まれた文字がわかります。検索エンジンはyahoo,google,msnを始め約20サイトほどに対応しています。 Hits Files Pages Visits Sitesとは？ 単にアクセスといっても、いろんな種類があります。 例えば、 HTMLファイルへのアクセ
Perl から Fluentd にログ出力 - Fluent::Logger リリース - 酒日記 はてな支店
皆さん、ログ書いてますか！？(挨拶) Fluentd meetup in Japan も開催間近、最近大変熱いイベントログ収集システム Fluentd なわけですが、Perl からログを出力する Fluent::Logger というモジュールを CPAN にリリースしたのでお知らせします。 (最初の版は id:hirose31 さんが書かれて、それに同僚の id:shin1rosei と手を加えたものです) インストールは cpanm などでどうぞ。使い方は POD にもあるように簡単です。 use Fluent::Logger; my $logger = Fluent::Logger->new( host => "127.0.0.1", port => 24224 ); $logger->post( "myapp.info" => { foo => "bar" } ); 上記の例で送信す
イベントログ収集ツール fluent リリース！ - Blog by Sadayuki Furuhashi
こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました！ Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です：イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め
一行のログの向こうには、一人のユーザがいる - ihara2525's blog
クックパッドのトラフィックは、世界有数とはまだとても言えませんが、そこそこの規模ではあると思います。 サーバのアクセスログは毎日大量に流れていき、もはやtailで一行一行追っかけられるものではありません。 昔の僕は、少なくともアクセスの規模ではクックパッドよりも大きなサービスに関わっていて、今よりも大量のアクセスログにふれる機会がありました。 でも、こんな風に考えたことはなかった。というか、考えることができませんでした。 一行のログの向こうには、一人のユーザがいる 弊社のインフラエンジニアが言っていた、すごく感動した、今も大好きな言葉です。 アクセスがあるんだから当たり前じゃん、って話なのですが、その一行一行の向こうには、現実に生きている人がいて、その人たちが今その瞬間、端末に向かっています。 例えばクックパッドというサービスを例にすると、初めて使われる方もいらっしゃれば、古くからずっと使
だーにっき 作業ログの取り方
ターミナルエミュレータを使って作業するときの作業ログをとらないといけない。僕の作業環境はMacなので、TeraTermやputtyみたいに自動でログを取れない。iTermを使ってるけどiTermではログをとるのにメニューから指示して始めないといけない。これでは僕はまず間違いなく忘れる。 スマートに取りたいと思ってネットを探してみた。 http://blog.miraclelinux.com/ctd/2006/08/post_a6c8.html かっこいいなーと思ったが、基本的に僕の作業はトラブルシュートが多いのでシェルスクリプトで作業をすることは少ない。（定型作業をスクリプト化することは多いけど） MacOS X付属のscriptコマンドを利用するのもいい考えだけど、作業開始時にコマンドを一つたたく事を習慣づけるのは我ながら自分を当てにできない、というか多分無理。 というわけでiTermの
Regexp::Log::Common の使い方を覚えた - @kyanny's blog
これでもう access_log をパースするときに正規表現をどう書くべきかで悩む必要がなくなった。 普通に LogFormat combined なファイルをパースするときはこれでいい。 my $foo = Regexp::Log::Common->new( format => ':extended', capture => [qw(host rfc authuser date request status bytes referer useragent)], ); my $re = $foo->regexp; my @fields = $foo->capture; while (<>) { my %data; @data{@fields} = /$re/; # do something } ちょっとカスタマイズされた場合もこんな風にして拡張が可能。 my $format = q[%ho
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
イベントログ収集ツール #fluent 周りの最近の話題 - Togetter
http://dl.dropbox.com/u/224433/kamakura_pm_2/index.html