平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
RailsでHello, world!を表示してみるの続き Railsでログを出力してみる。 ログファイル とりあえずログファイルを見てみる。 特にログ出力の処理がなくても、デフォルトで、アクセスのログがdevelopment.logに出力されている。 $ cat log/development.log Started GET "/" for 192.168.56.1 at 2014-01-02 17:05:37 +0900 Processing by SampleController#index as HTML Rendered sample/index.html.erb within layouts/application (1.5ms) Completed 200 OK in 92ms (Views: 66.1ms | ActiveRecord: 0.0ms) Started GET
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
こんにちは。開発部の平田です。 今回は、PHP製のWeb APIをGoに移植するプロジェクトでアプリケーションの情報やエラーを出力する為のLoggerを検討した際に、uber-go/zapというライブラリが公表しているパフォーマンスがその他ライブラリと比べて大分良かったので、どこでパフォーマンスの差を出しているのか、そのアプローチを簡単に紹介したいと思います。 Zap 初めに、簡単にzapの紹介をしておくと今年の2月にUberから公開されたまだ比較的新しいプロダクトです。その為開発ステータスはBetaの段階で出力もJSONしか対応していませんが、Github上で800以上のスターが付いており注目されているプロジェクトとなっています。 「Fast, structured, leveled logging in Go」とあるように、構造化されたログを出力するためのライブラリで、標準のlogのよ
ソフト詳細説明 Apache 等のHTTPサーバーが出力するNCSA形式のログを見やすく表示するソフトです。 指定されたログファイルを読み込んで、セッション状態を解析し、日付ごとに一覧表示します。 また、任意のアドレスやフォルダ群に対するアクセス解析 ( ログ解析 ) も行います。 各種のアクセス情報を基準に多様な集計を行い、それらを相互に追跡して表示できるので、特定アクセス元の動作追跡や検索サイトの登録・参照状況等、詳細かつ個別なログ分析を可能とします。 IISの場合でも、convlog でログ形式を変換すれば使用できます。
2015 - 01 - 27 Gitで特定のファイルの変更履歴や特定の期間での差分を一覧にする 変更履歴 まずこれで変更履歴がざっと一覧にできる git log -p filepath 特定ファイルの任意のコミット間の差分 特定ファイルの差分を出すこともできる。これはよく使うと思う。 git diff <commit>..<commit> filepath 試行 例えば特定のコミットから過去の特定のコミットの差分を見たいときはこのような感じになる git diff bca7cd0..5545350 Gemfile これ昔どこかで試したからできるはずだと思うがブランチ間も超えられるはず。 既に運用中のコードに何度も手を入れていくとバグが発生するが、そのようなケースでは現行動いているコードからバグを探すよりも、正常に動作していた時との差分をとって変更点に問題がないか調べる方法が素早くデバッグで
ユーザ毎にアクセスログや操作ログなどを保存して出力するWEBシステムを作成しています。 基本的にデータの保存にはMySQLを使っているのですが、 1テーブルにログを蓄積していくと膨大になり、処理に影響が出る事を懸念しています。 自分で調べた解決策として (A)ログは月ごとにファイルを作成し、アクセスがある毎に追加書き込みする。出力時は、日付を選択して対象ファイルを読み込み、一括出力。 (B)SQLiteを使い、ユーザ毎に専用のDBを作成してそこに書き込む (C)MySQLのパーティショニングを使用する 現在はAで対処しているのですが、ログを検索したい時、DB構造ではないので困難です。 CはMySQLのバージョンに依存する為、出来れば使いたくないです。 Bの方法が良いとも思いましたが、はてなの過去ログを調べるとオススメ出来ないとの意見がありました。 そこで質問ですが、膨大化するデータを扱い、
SNSやソーシャルゲーム、アドネットワークなどのシステムではいろいろなログ情報をDBに保存することもあると思います。 そのさい、日々増えつづけるデータやパフォーマンスをどの様にさばいていくかが重要になってきます。 今回はログ系のデータをMysqlでどのように運用していくか、をテーマにいくつかのノウハウをまとめました。 ログ系テーブルの特徴 ログ系のデータとは、つまり何かのアクションの履歴データのことです。 一般的にはこのような形になるかと思います。 CREATE TABLE `t_logs` ( `id` bigint(20) unsigned NOT NULL, `user_id` int(10) unsigned NOT NULL DEFAULT '0', `event_id` int(10) unsigned NOT NULL DEFAULT '0', `created` datet
アプリの開発をしていると、アプリが吐き出すのログを見ることが多いと思います。 以前会社の同僚に教えてもらったので、自分で考えをまとめるために記事にします。 背景 僕の場合Railsで開発することが多く、development.logなどを見ることが多いです。 ログを垂れ流して見る場合ターミナルで tailf コマンドや tail -f を使っていて、 必要があれば Ctrl-c で止めてターミナルをスクロールしてログを見ていました。 あとはターミナルの検索機能で文字列検索したり。。。などなど そんな人に tail ではなく less を使うとちょっと便利だよという内容です。 lessの基本 Unix関連のOSには多分デフォルトでインストールされていると思います。 コマンドの引数にファイル名を指定して起動します。 操作感は more や vi と似ています。 vi とは違い起動時にファイルの
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
夜中に突然自鯖がウィーンと唸り出したので、vmstatとか見たら案の定cpuのidleが0になっていました。 topコマンドで見るとmakewhatisという見慣れないプロセスがゴリゴリ動いています。 -bash-3.00$ ps -ef | grep makewhat root 15448 15447 0 04:22 ? 00:00:00 /bin/bash /etc/cron.weekly/00-ma root 15449 15447 0 04:22 ? 00:00:00 awk -v progname=/etc/cron.weeklyme {????? print progname ":\n"????? progname="";???? }???? { pri root 15451 15448 6 04:22 ? 00:00:10 /bin/bash /usr/bin/makewha
現在オンラインゲームのバックエンド、KPIシステムを担当していますマサヨシです。 今回のブログでは【DMMオンラインゲームで実際に実装しているログとKPI】に関して3回にわたってご紹介致します。 DMMオンラインゲームでは、これまではオンラインゲームのプロジェクトごとに行っていたログの収集方法を統一し、プロジェクトに依存しない基本KPI機能とゲーム独自のKPI機能を実装するためのフレームワークを開発しましたのでその事例をもとにご紹介します。 ログ収集、解析の概要 まず、オンラインゲームのログ収集の全体像をご紹介します。 オンラインゲームのログ収集ではApacheやnginx、PHPのログをfluentdで収集しています。 fluentdに集めたログをHadoopの分散処理システムに保存し、HiveやImpalaで解析をする流れになっています。 ご存知の方も多いと思いますが、HiveとはHD
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く