filtというツールを作りました github.com これはなに まずは以下のスクリーンキャストをご覧ください tail -F /path/to/access.log のようなログの流れを止めてはgrepをして、止めてはgrepのコマンドを変更してしています。 その間、実は裏では実際のストリームは止めていません。 つまり、ストリームのパイプ先に まずfiltを指定しておく ことで、ストリーム自体は止めずに、パイプ先のコマンドを 後で何度でも 変更できます。 grepやsedやawkが下手なので何度も試行したい 私はgrepやsedやawkなどのコマンドを一発で指定できるほど練度が高くないので、コマンドを組み立てるために何度も Ctrl+C でキャンセルしては再実行の繰り返しをしていました。 最近は stern や Harvest などでKubernetesのPodのログを流すことをもある
スマートニュースは昨年の 10/1 に米国版をローンチするにあたり、ログ解析基盤のリニューアルを行いました。日本に加えて米国やその他の国が入ってくることにより、単なるユーザ数の増加に加え、OS x 国 x タイムゾーン x 多種多様なメトリクスのような集計軸が増えることで、ログの前処理、集計、可視化に様…
PostgreSQLの運用管理にログの情報は不可欠ですが、PostgreSQLが出力するログは直接取り扱うのに適した形式とは言えません。ここではFluentdを使って運用管理に活用しやすい形にPostgreSQLのログを加工する方法を紹介します。 PostgreSQLの運用管理とログ データベースの運用管理には 死活監視、リソース監視 性能分析、チューニング バックアップ、リストア といったものが考えられますが、現状を把握しなければ何も対策できないので、まずは必要な監視を正しく行うことが重要です。PostgreSQLで監視に使える機能には稼働統計情報とログがありますが、今回はログに注目してみます。 PostgreSQLのログからわかること PostgreSQLが出力するログからは以下の様なことがわかります。 何らかの異常(エラー)が発生したこと 処理されたSQL チェックポイント、自動VA
Pascal〜Puree + ngx_lua + Fluentd + BigQueryでつくるメルカリのログ分析基盤〜 Backend Author: cubicdaiya エンジニアではなくプログラマと呼ばれたい@cubicdaiyaです。今回はメルカリのログ分析基盤のお話です。 メルカリにおけるログデータ分析 メルカリでは初期の頃からログデータの分析をサービスの成長にとって重要なタスクとして位置づけ、そのための基盤作りに取り組んできました。ログの種類はいくつかありますが、中でも代表的なのがアプリケーションサーバで出力されるアクセスログやアプリケーション固有のログです。これらのログはサイズが大きいので効率良くログデータを転送するための工夫が必要になります。そこで活躍するのがFluentdです。 大雑把に説明するとアプリケーションサーバで出力されたログはFluentdから最終的にBigQu
ログ分析サービスはアプリケーションのインフラであり、サービス開発/運用の中で重要な位置を占めます。グラニでは、今年に入って利用しているログ分析サービスを、 Sumo Logic から Google BigQuery に完全移行しました、 本記事は、グラニで議論された「ログ分析サービスとしての SumoLogic と BigQuery」のまとめを推敲、転載したものです。これからログ分析サービスを検討される方々にとって、議論の内容が少しでも参考になることを願い公開します。 アジェンダ まずは文脈を整えるためにアジェンダから。 アジェンダ 日常的なアプリケーション監視フロー APM として盤石な New Relic ログ分析サービスによるアドホックなログ分析 ログ分析サービスに求めること Sumo Logic の利用と課題 Sumo Logic の利点 Sumo Logicで発生した課題 ログ収
先日2014年9月9日(火)に開かれた『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！で、「Kibanaで始めるダッシュボード」というタイトルで発表させて頂きました。会場のGMOのみなさま、Treasure Data、技術評論社のみなさま、どうもありがとうございました。 養成読本で担当したKibanaの内容を中心に、Kibanaをつかったらこんなかんじで簡単にダッシュボードをはじめられるよ、という内容を発表しました。こういうかんじのログがあれば、とりあえずKibanaにつっこむだけで皆様の生活にダッシュボードを見る時間を組み込めるのではないでしょうか。Kibanaをはじめとしたダッシュボードを見ることがテストを書くことと同じように、業務として一般的になっていくんじゃないかと思っています。 Kibanaの詳しい使い方は本にたくさん書いたので是非買っ
モバイルアプリでログを取ろうと思ったとき、多くのアプリではGoogle Analyticsを使っていると思います。 Google Analyticsは2つの事象にうちどちらが多く発生しているかなどの用途では便利ですが、一方でGoogle Analyticsはサンプリングされているので誤差があったり、ユーザー属性から絞ったりということができません。 そのため、弊社のプロダクトではログはOAuthで認証してfluentd経由でTreasure Dataに流していたりします。 参考になる記事：Fluentdとログ収集のパターン - Go ahead! 京都の勉強会で（京都 Android 勉強会 2014.08）ログの話をしたら「そうそう大変なんだよね〜」と共感していただいて、やはり各自でログ収集のしくみを作って正確な値を取っていたり、クエリを投げて分析したりしているみたいでした。 しかし、この
nginx でクライアントの "Accept-Encoding" をログ出力する必要があったので調べた。 ログ出力の基本 ngx_http_log_module モジュールでログ出力する。 nginx.conf の log_format で指定。 Ubuntu では nginx.conf は /etc/nginx/nginx.conf にある。 書式 リクエスト/レスポンスヘッダーともに log_format に $prefix_{field_name} で指定する。 prefix はリクエスト/レスポンスで異なる field_name は正規化しなければいけない。 大文字は小文字にする ハイフンはアンダースコアにする リクエストヘッダーのログ出力 prefix は http Accept-Encoding の場合 $http_accept_encoding となる。 ドキュメントのどこか
Add your Ruby gems to AWS CodeArtifact Ruby developers can now use AWS CodeArtifact to securely store and retrieve their gems. CodeArtifact integrates with standard developer tools like gem and bundler. Applications often use numerous packages to speed up development by providing reusable code for common tasks like network access, cryptography, or data manipulation. Developers also embed SDKs–such
What is it? GoAccess is an open source real-time web log analyzer and interactive viewer that runs in a terminal in *nix systems or through your browser. It provides fast and valuable HTTP statistics for system administrators that require a visual server report on the fly. Why GoAccess? GoAccess was designed to be a fast, terminal-based log analyzer. Its core idea is to quickly analyze and view we
mysqlで一般クエリログをするためには、 my.cnfをいじるといいのだけど、 記載方法が少し前のバージョン辺りから変わったのでメモっておく。 ログの出力先ディレクトリはあらかじめ作成しておくことも忘れずに。 mkdir /var/log/mysql chmod 0777 /var/log/mysql vi /etc/my.cnf MySQL 5.1.12 以降 [mysqld] # 一般クエリログを出力する。 general-log=TRUE general-log-file=/var/log/mysql/query.log MySQL 5.1.12 それ以前 [mysqld] # 一般クエリログを出力する。 log=/var/log/mysql/query.log 設定が終われば再起動。 /etc/rc.d/init.d/mysqld restart 詳しくは、【公式ドキュメント】を
しょーもないことだけど意外にできなかったので。。 rotateオプションあるいはmaxageオプションだと man logrotateで出てくるsampleを例にとると /var/log/messages { rotate 5 weekly postrotate /usr/bin/killall -HUP syslogd endscript } こんな感じの設定だとして、この「rotate」オプションが世代管理の設定。 例の場合だと5世代残す設定になるわけだけど、これを世代管理なんかしなくて永久にファイルを残したい。 でもmanを見てみてもそれっぽいオプションがなさそう。 はじめ"rotate 0"かなーって考えてたけど"rotate 0"の場合は世代管理が0ってことで、1世代も残さずにローテート後のファイルが削除されちゃう。 If count is 0, old versions are
さくらのVPS契約してみたら設定されていた、なんていう恥ずかしい理由で知りました。 普通のlogrotateの設定だと、ローテートしているログファイルはmessages.1みたいな感じで一体いつ出たログなのか、よくわかりません。 最近のlogrotateにはdateextというオプションがあるようで、これを設定することでローテートしたログファイルに日付を付けられるようです。 こんな感じ。 # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create # use date as a suffix of the rot
ログ解析における統計値の妥当性をどうやって担保するのかは難しい問題だと思っていてぶっちゃけ最終的にはオレを信じろ、でも間違ってたらゴメンの世界な気がする。 社内で閉じていて外に出ない統計値ならまあいいんだけど、世の中そんな統計値ばかりではない。 例えばWebサービスを展開していてそこに広告を出稿してもらって売り上げをたてたいとする。広告を出す方としてはそのサイトにどれぐらいPV/UUがあるか知りたいと思うのは当然ですよね。 広告を出したら出したでインプレッション数が知りたいとかあるかもしれない。 このような統計値はログを集めて集計することによって求めるわけなんだけど、数値が正しいかどうかをどうチェックするかというのは難しい問題ですよね。 本来ならいろんなバリエーションのテストデータを作ってテストするんでしょうけど、テストデータ作るの大変だし、このビッグデータ時代？にはどんなデータが来るかわ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く