エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
logrotate によるログのローテーション
ここでは、ログの肥大化を防ぐためのログのローテーションについて解説していきます。syslog や他のプロセスが出力するファイルは放置していくとどんどんサイズが大きくなり、ディスクスペースを圧迫していきます。インストール時は/var ディレクトリのディスク占有率が0%であっても、数週間、数ヶ月経過するごとにあっという間に占有率が増大していることに気がつくと思います。しかし、これらの出力されるログを何世代分ローテーションさせるかといったことを予め決めておけば、指定した以上のファイルは作成されなくなり、その中でログがローテーションされていくのでログサイズの肥大化を防止することができるのです。RPMでパッケージをインストールしている方は、ほとんどログのローテーションをカスタマイズする必要はありませんが、ソースからコンパイルしてインストールした場合には、ログのローテーションは必須の作業となります。ま
サーバ/インフラエンジニア養成読本「ログ収集〜可視化編」を頂きました！ - oranie's blog
改めて著者の方々と実際に僕に本を送付する手配をして頂いた@yoshi_kenさん本当にありがとうございます。 社内の他のエンジニアが「本頂きました！^^」とかのツイートをしている*1のを見る度に「ブルジョワが！( ﾟдﾟ)､ﾍﾟｯ」とか思っていたらついに僕も貰える時が来るなんて・・・。もう二度とこんな機会はこなさそうなので、保存版として額に入れておこうかと思いましたが、せっかくなので読んでみました。 特集1「ログ解析から始めるサービス改善」 ここではまず「なぜログ解析をする必要があるのか？」「何のためにそもそもやるの？」という事が分かりやすく書かれているかなと思います。特にログは大規模であれば膨大な量や情報を抱える為、やみくもに「これも取ってみよう」「あれも計測してみよう」という事をやっても結局「そもそもなんでこれ必要なんだっけ？」で終わるパターンもあるので、まずここを読んで自分に必要な事
fluentd で集めたログを Splunk で可視化する - 技術ノート
ウェブアプリケーションのログ収集には fluentd を使うとして、集めたログを検索したりグラフ化するには、別途システムを組む必要がある。 最近だと、オープンソースの Kibana というのが流行っているようで、公式ページにも紹介がある。 Free Alternative to Splunk Using Fluentd | Fluentd ここで比較対象とされている "Splunk" だけど、これを fluentd と組み合わせて使っている人は多くないようなので、軽く紹介しておきたい。 Splunkとは？ 商用のログ収集＆検索エンジンとしてはメジャーな製品で、 独自のクエリ言語でログを検索、加工、集計、グラフ化する あらかじめダッシュボードを作っておいてPDFでレポートを送る 検索条件を設定しておいてアラートを飛ばす といったことが出来るようになっている。 詳しくは公式のビデオでも。 Sp
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
秒間数万のログをいい感じにするアーキテクチャ
