モバイルアプリのログを送るの大変じゃないですか？ - Rejasupoem
モバイルアプリでログを取ろうと思ったとき、多くのアプリではGoogle Analyticsを使っていると思います。 Google Analyticsは2つの事象にうちどちらが多く発生しているかなどの用途では便利ですが、一方でGoogle Analyticsはサンプリングされているので誤差があったり、ユーザー属性から絞ったりということができません。 そのため、弊社のプロダクトではログはOAuthで認証してfluentd経由でTreasure Dataに流していたりします。 参考になる記事：Fluentdとログ収集のパターン - Go ahead! 京都の勉強会で（京都 Android 勉強会 2014.08）ログの話をしたら「そうそう大変なんだよね〜」と共感していただいて、やはり各自でログ収集のしくみを作って正確な値を取っていたり、クエリを投げて分析したりしているみたいでした。 しかし、この
combinedに代わるオレ流ログフォーマット - （ひ）メモ
こんにちは、combinedログ撲滅委員会のひろせです。 ApacheのcombinedやNginxのデフォルトのlog_formatは、機械処理(日付でのソートやパース)がしづらい上に、人の目にもあまり見やすいフォーマットとはいえないと思っています。 なので自宅のサーバーでは、 日付は ISO8601 にする sortコマンドとかで簡単にそぉーっとソートできるようになる 日付、レスポンスコード、所要時間とか固定長的なフィールドは左に寄せる URLとかUAとか可変長で長いのは右に寄せる リクエスト(%r)も右に寄せた方ががいいような気がしてきた。。。 数値だけだとわかりづらいのでなんとなくわかるようにフィールド名も添える フィールド名を長くするとわかりやすくなる反面、ログサイズが大きくなるので注意 という観点で次のようなログフォーマットにしています、 # Apache LogFormat
app serverがリクエストの処理にかかった時間をログに記録する
Webアプリケーションのパフォーマンスをトラッキングするために、app serverの処理にかかった時間を記録したい。 方法を、以下のように分類できる。 1. reverse proxy側で、proxy先のapp serverがレスポンスを返してくるのにかかった時間をログに記録する場合 1.1 nginx 1.2 apache 2. app serverでリクエスト処理にかかった時間を出して、ログに記録する場合 2.1 reverse proxyで記録する場合 2.2 app serverでログに記録する場合 1と2とでは出てくる数字が違うだろうけど、本件に必要なのはパフォーマンス改善を示す一貫した指標なので、どっちでもいいと思う。 1. reverse proxy側で取る場合 1.1 nginx log_formatディレクティブに$upstream_response_timeという変数
第11回 ログでアプリケーションの改善プロセスを回す（1） | gihyo.jp
本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回のハッカーはkazeburoさんこと長野雅広さんで、テーマは「ログでアプリケーションの改善プロセスを回す」です。 オペレーションエンジニアの仕事 小林篤さんから連載のバトンを受け取りました、長野雅広です。普段はNHN Japan（株）にてオペレーションエンジニアとして働いています。livedoor blogやポータルサービスなど自社Webサービスの運用に携わっており、cloudforecast（Perlで作られたリソース監視ツール）を使ったメトリクス収集をはじめ、アプリケーション設計のアドバイス、ミドルウェアの設定、障害対応のフォローなど、Webアプリケーションエンジニアにかかる運用の負担を減らすことが主な業務です。 ログはDevとOpsのコミュニケーション手段 監視サーバからのアラートメールが届いたり、リソース監視ツ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
