LTSVはLabeled Tab-separated Valuesの略で、コロンで区切られたラベルと値の組み合わせ(key:value)をタブ区切りで表現したフォーマットです。 主にログデータのフォーマットとしての利用が想定されています。 uri:/upload status:400 size:13599 reqtime:0.280 apptime:0.150 uri:/downalod status:200 size:12812 reqtime:0.330 apptime:0.210 uri:/item/new status:200 size:29830 reqtime:0.050 apptime:0.050 uri:/item/fav status:200 size:33123 reqtime:0.100 apptime:0.099 uri:/top status:301 size:1
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
モバイルファースト室の @rejasupotaro です。 クックパッドでは、サービスをリリースしてログを収集して分析して改善してまたリリースして、というサイクルを素早く回すことでより良いものを作るということをウェブではやってきました。 クックパッドのサービス開発のフレームワークをモバイルアプリでも適用したいのですが、モバイルアプリにはウェブアプリと違ったロギングの難しさがあります。 今回はモバイルアプリのロギングの問題点とPureeというログ収集ライブラリについて話します。 モバイルアプリのロギングの難しさ ウェブアプリでは、基本的にはサーバー側でログを収集することができますが、モバイルアプリの場合は画面の制御はアプリ側で行われ、APIを介してデータを受け取るため、クライアント側でログを収集して送信する必要があります。 アプリのログを収集するのに、画面遷移をしたりタップするたびにサーバー
これは Hubot Advent Calendar 2014 - Adventar の 8 日目の記事です!!!111前日は id:bouzuya さんの 簡単な Hubot スクリプトをもっとつくろう (おみくじ系) - Qiita でした。 早速本題だが、チャットオップスで最初に思いつくのがコマンドをラップする！とかだろうけど、これが意外と考えることが多くて、 実行時間が長いといつまでも帰ってこなくて不安では？ ログの扱いをどうする？ みたいな当たり悩ましい。 ここで、npmにcarrierと言うモジュールがある。 pgte/carrier · GitHub これは標準出力、標準エラー出力のストリームをつなげば、一行ずつイベントを発火してくれると言う代物。この一行ずつと言うのが大変便利で、使い方としてはこれだけで良い。 # Description: # 例えば、 aws-cli のコマ
*トレジャーデータはデータ収集、保存、分析のためのエンドツーエンドでサポートされたクラウドサービスです。 「Login（アクセス）ログからわかる12の指標 シリーズ」 その１，その２，その３，その４ クエリ内のTreasure UDFのリファレンスはこちら。 本シリーズの主張は，例え単純な ”ログイン”（アクセス）の記録のみを取るだけでも，それにユーザーIDが付くことでトレジャーデータ上で遙かにリッチな示唆を得ることができる，ということです。 もしユーザーを識別できるサービスをお持ちでこれから分析を始めたい企業様は，きちんとそれをloginログを残すことから始めましょう。本記事では「login（アクセス）ログ」というたった1種類のデータから得られる12の指標を紹介したいと思います。 定義 以下の項目で定義されるログを「loginログ」と定義し，かつ各ユーザーの登録時からこのログデータが取得
こちらは Perl入学式 Advent Calendar 2014 の10日目の記事です。 昨日は @__papix__ さんの「Perl入学式の歴史 〜その2 2012年〜」でした。 とてもドラマチックで、人間同士の一つ一つのつながりが「Perl入学式」を作ってきたのだなあ、と思いました。 僕の方は、このAdvent Calendarでこれまでに2本、やや抽象的で概念的な話を書いてきましたので、 38才からのプログラミング入門 - the code to rock 独学の作法 - the code to rock 今回はもう少し具体的に、ではプログラミングを学んで何を作ったのか？ ということについて書いてみたいと思います。 イントロダクション 〜 Markdown環境について 前回までの記事にも書きましたように、僕の本業はCDブックの編集者です。 したがって、普段の仕事でプログラミングを
lighttpd では mod_fastcgi や mod_proxy 経由でアプリケーションが、 X-Lighttpd-Hogehoge: foobar のような X-Lighttpd- ではじまるヘッダーを返してもそれをクライアントに送り返さないという仕組みがあり、 たとえばそれを利用してアプリからユーザーIDを返してあげたりすると、それをクライアントに送ることなく lighttpd のアクセスログにだけ記録する、といったようなことが出来て便利なのですが、 同じようなことを nginx でやりたかったのでしらべてみた。 アプリから X-MyApp-User: foobar みたいなのを返してそれをクライアントに送ることなくアクセスログに記録したい場合、まずクライアントに送らないように、 proxy_hide_header X-MyApp-User; とし、さらに accesslog の
Index ログ集計システムの要件 DB設計 データ保存方針 table設計 サーバ構成 Fluentd fluentd,fluent-plugin-mysql-bulk install td-agent.conf mysqlにデータが格納される事を確認する 集計用のバッチ その他 Table肥大化防止 可視化 ログ集計システムの要件 爆弾ログ処理班の@yutakikuchi_です。 ログ集計システムというものを作る時に皆さんはどのように対応していますか？ 以下の候補から要件のレベルで使い分けをしている人が多いと予想しています。ざっくりの評価ですが、導入難易度、正確性、可視化、リアルタイム、長期集計、スケール、運用費用という点で評価を書いています。 ツール 導入難易度 正確性 可視化 リアルタイム 長期集計 スケール 運用費用 リンク GA(スタンダード) ○ × ○ ○ ○ ○ ○ Go
Description Labeled Tab-separated Values (LTSV) format is a variant of Tab-separated Values (TSV). Each record in a LTSV file is represented as a single line. Each field is separated by TAB and has a label and a value. The label and the value have been separated by ':'. With the LTSV format, you can parse each line by spliting with TAB (like original TSV format) easily, and extend any fields with
AmazonRDSでslow queryを出力するようにする方法
AmazonRDSは、デフォルトの設定ではslow queryを出力するようになっていない。 また、MySQLが動いているサーバにアクセスすることができないので、slow queryをログファイルに出力したとしてもそれを閲覧する術がない。 RDSでも採用されているMySQL 5.1からは、slow queryをテーブルに保存できるようになったので、それを使う。 方針 ログはテーブル(mysql.slow_log)に出力する。 実行に1秒以上かかったクエリを記録する 100行以上を読み込んだクエリを記録する 普通なら以下のオプションをmy.cnfに設定すればOK。 [mysqld] slow_query_log = ON long_query_time = 1.000 log_output = TABLE min_examined_row_limit=100 RDSの場合は、db-param
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
ここでは、ログの肥大化を防ぐためのログのローテーションについて解説していきます。syslog や他のプロセスが出力するファイルは放置していくとどんどんサイズが大きくなり、ディスクスペースを圧迫していきます。インストール時は/var ディレクトリのディスク占有率が0%であっても、数週間、数ヶ月経過するごとにあっという間に占有率が増大していることに気がつくと思います。しかし、これらの出力されるログを何世代分ローテーションさせるかといったことを予め決めておけば、指定した以上のファイルは作成されなくなり、その中でログがローテーションされていくのでログサイズの肥大化を防止することができるのです。RPMでパッケージをインストールしている方は、ほとんどログのローテーションをカスタマイズする必要はありませんが、ソースからコンパイルしてインストールした場合には、ログのローテーションは必須の作業となります。ま
404 error お探しのページは移動もしくは削除された可能性がございます。 The page has might be moved or deleted.
GC_Utils_Ex::gfPrintLog(String msg); を使う。
毎回、どこに書いたか探しているので自分用にメモ logファイルの初期設定（コマンド引数取らない版） import os import logging BASE_PATH = os.path.abspath(os.path.dirname(__file__)) logFormat = '[%(asctime)s] %(levelname)s %(message)s' logFilename = 'hogeApp.log' logLevel = logging.INFO logging.basicConfig(level=logLevel, format=logFormat, filename=os.path.join(BASE_PATH,logFilename), filemode='a') logging.debug('current dir: %s'%(os.getcwd())) log
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
