ログ収集サービスのlogdnaを試す - トレタ開発者ブログ
佐野です。ここ2ヶ月くらい坐骨神経痛を患って、座ると痛い、立つと痛い、歩くと痛い、朝起きると痛い、くしゃみすると痛い。靴下がはけない(痛いから)、しゃがめない(痛いから)、夜痛みで目が覚める。という生活をしています。こちらの記事( 頭痛に耐えかねて自殺する人も…【激痛を伴う病気ワースト5】 )によると、痛すぎる病気ワースト4位らしいです。さて、ご近所のplaidさんからlogdnaというログ収集サービスを教えていただいたのですが、試してみました。 logdna logdna https://logdna.com/ ローンチは2016年、つまり今年のようです。fluentd同様、エージェントをサーバに棲ませて、それがログをlogdnaに転送します。トレジャーデータ似ていますが、まだ機能は少なくて分析などはできないです。特定文言のハイライト、通知、grep...など全サーバのログを一覧するよう
Cloud Loggingの利用方法
Lv：41 Exp：305891 普段はGCP専門のエンジニアをやっています。 最近は個人的な活動としてGOとswiftでアプリ作ってます。 G+ はじめに 本記事はGoogle Cloud Platformの公式ページで公開されている「Google App Engine Articles」の紹介記事となります。今回はその中から「Using Cloud Logging in App Engine Apps」の記事を説明します。 ※前回は「GAEのスケーリング 前編」(後編も後ほどリリースします。)について解説しました。今回は記事解説の第2弾となります。 Cloud Loggingとは Cloud LoggingとはGoogle Cloud Platform(以下GCP)上で動作するアプリケーション(GAE、Managed VMs)のログを管理するための機能です。例えば、言語毎(Python
エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
謎の独自ERRORログをEmbulk + Elasticsearch + Kibana + PostgreSQLで監視する：運用設計からシステム構築まで - GMOインターネットグループ グループ研究開発本部
2015.05.28 謎の独自ERRORログをEmbulk + Elasticsearch + Kibana + PostgreSQLで監視する：運用設計からシステム構築まで 次世代システム研究室のDevOpsネタ担当（Embulkのコード読んでRuby復習中）のM. Y.です。 前回の記事（ERRORログが多すぎるWebアプリに出会ったら）では、ログ形式が統一されていない、大量のERRORレベルのログを吐き出すWebアプリに運悪く出会ってしまった場合に、そこから何とかログの傾向を把握するためのアプローチについてご紹介しました。 あれから、このアプローチを実践するためのログ監視システムを社内で実際に構築してみました。その結果、Embulk + Elasticsearch + Kibana + PostgreSQLという組合せで、割と手軽に、実用的なものを作れそうなことが分かりましたので、今
並列データ転送ツール『Embulk』リリース！ - Blog by Sadayuki Furuhashi
こんにちは。古橋です。 先日の*1 データ転送ミドルウェア勉強会で、新しいオープンソースツール Embulk をリリースしました。 Embulk, an open-source plugin-based parallel bulk data loader from Sadayuki Furuhashi Embulk は、リアルタイムなログ収集では常識となった fluentd のバッチ版のようなツールで、ファイルやデータベースからデータを吸い出し、別のストレージやデータベースにロードするためのコンパクトなツールです。 fluentd と同様にプラグイン型のアーキテクチャを採用 しているため、RubyやJavaで簡単なコードを書くことで、様々なファイルフォーマットやストレージに対応することができます。一方で fluentd とは異なり、高速性やトランザクション制御、スキーマを使ったデータのバリ
CloudWatch Logsエージェントを検証してみた
先日リリースされたCloudWatch Logs、監視ツールを開発していた者としては注目せざるを得ません。 特に、ログ監視エージェントにはこだわりがあるので、CloudWatch Logsエージェントの細かな動作に興味をもちました。 そこで、今回はCloudWatch Logsエージェントを5つの観点から検証してみました。 はじめに ログ監視エージェントにとって重要な5つのポイントを考えてみました。 メッセージラッシュ ロングメッセージ ログローテーション 一時的な通信断 エージェント停止 メッセージラッシュ 障害発生時等に短時間に大量のメッセージが発生することをメッセージラッシュと呼びます。 このメッセージラッシュが発生した際にも、安定して動作してメッセージをロストせずに監視できることは、ログ監視エージェントにとって重要なポイントです。 そこで、メッセージラッシュを意図的に発生させ、ロス
Norikraでログ集計してアプリのエラーを素早く検知しようという話 - kawamuray's blog
背景 webアプリを書いていると，以下のようなロギングコードを至る所にちりばめる事になると思います． $c->log(error => "Chou Yabai ERROR!"); ただいくらログを吐いても，アプリのログからは片時も目を話さないよ！！みたいな真面目なエンジニアじゃない限り，せっかく吐かれたログに気づけないとかあるわけです． そこで特に重要なログについては別途ikachanとかでIRC等にpostするコードを入れといて，即応できるようにしてることと思います． でも，levelがerrorとかcriticalで吐かれてるログって全部重要だし全部すぐ知りたくね？それにいちいち別途ikachanするコードとか入れるのめんどくね？っていう需要があるわけです． そこでロガーメソッドにif ($level == 'error') { post_to_irc($message) }みたいなコ
アクセスログをスマート解析してくれる「request-log-analyzer」が超絶便利だった件 - カイワレの大冒険 Second
最近、Ruby率が高くなってきた@masudaKです。 ちょいとアクセスログを眺める機会があったのですが、ワンライナーも限界があるし、なんかいいプラグインでもあるんじゃないかと探したら、良さそうなのがあったので、紹介。 その名も「request-log-analyzer」。Ruby製のログ解析ツールでございます。 プロジェクトページを見ると、Railsのログだけではなく、Apacheのアクセスログや、S3のログ、MySQLのスロークエリログなんかにも対応してるとのこと。 とりあえず、combinedなログを解析したかったので、試しにやってみました。 1 2 49.212.129.187 - - [27/May/2013:05:48:01 +0900] "GET /top HTTP/1.1" 200 162 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu)
ログ解析ツール「Splunk」を使ってみた - カイワレの大冒険 Second
先日、qpstudyに参加してきた@masudaKです。@ar1さんと話しながら、荒木さんがLTでお話されたログの話をブログにあげたら、 僕も書きます−と言ってしまったので、ちょいと書いてみます。 荒木さんの記事・発表ではSumoLogic中心に書かれてましたので、Splunkを試してみました。 Splunkとは んで、Splunkとは何かということですが、製品概要をみてみると、以下のように書かれています。 1 2 3 4 5 6 7 8 パワフルな検索、分析、および視覚化機能。数千社に及ぶ導入実績。すぐに始められます。 Splunk Enterprise はマシンデータ用のプラットフォームです。 すべての IT システムやテクノロジーインフラストラクチャから生成される膨大なマシンデータを収集、分析、および保護する簡単、スピーディかつ柔軟な方法を提供します。 問題のトラブルシューティングや
ログ解析で楽をする話 #qpstudy でしてきました。
ログ解析というのはインフラエンジニアの基礎の基礎です。アプリケーションが定まればそれなりのログ解析ツールは存在します。Debianのstableですら数十のツールがあります。 とはいえ、実際のログというのは往々にしてアプリケーション毎に全然ちがっているのでツールは役に立ちません。結果としてgrepを駆使したり、はたまたRDBに突っ込んだりして試行錯誤することになります。 見事に解析できたとしても、それを可視化することを考えると楽できることを考えておきたいわけです。 そこで役に立つのはログ解析SaaS．Sumologic, SplunkStorm, Logglyなどけっこうありますが、qpstudyではSumoLogicを紹介してみました。GUIでログを横断的に絞り込めますし、その処理構文はいつでも繰り返すことのできるすぐれものです。 無料で使えるサイズでかなりのことができますので、ちょっと
定期実行スクリプトの綺麗なロギング3選 - カイワレの大冒険 Third
オリンピックの流れに乗れてない@masudaKです。 職業柄かちょくちょくスクリプトを書くことはあるのですが、やはり色々自分で書いたり人のを見たりしてるうちに、この実行履歴綺麗だなーと思うことが多々あります。 今回は、そう思える対象のなかでも、「定期実行スクリプト」の「出力」を扱ってみたいと思います。 「定期実行スクリプト」というのは、バッチ処理だったり、何か必要に応じて叩かれるスクリプトで、具体的にはバックアップとか集計とか、一日に最低一回は叩かれるようなスクリプトです。cronやJenkinsで叩かれるような類ですかね。そのようなスクリプトの「出力」について書いてみたいと思います。 出力は標準出力であれば、tailfコマンドだったり、Jenkinsのビルドのコンソール出力で見られるようなもの。ロギングされてるのであれば、それと同様に追えるようなものとします。 以下に書くのはあくまで今の
なぜFluentdなどを使ってログデータ活用するのか？ | Act as Professional
髪を切った@HIROCASTERでございませう。 今日は巷で話題のfluentd（フルーエントディー）を使って、アクセスログを活用するための準備をしたいと思います。 簡単にfluentdを使って何をするのか 例えばこんなこと という、知識や目的の準備です。 fluentd とは？ Linuxサーバなどのログを集約するためのツールです。ログ形式は良くあるテキスト形式ではなく、JSON形式にて構造化された形で保存されるため、集約されたログデータを解析したりするのがとってもやりやすくなります。 従来のテキストデータで出力されるApacheのログなどを読み込んで、fluentdでリモートログサーバに飛ばして、集約保存することなんてことができます。 集約されたログデータを解析サーバで解析して、グラフで出力とかするわけです。 具体的にどういうことができるの？ ログデータの活用は無限大なので、さまざまな
Write parser with fun!
The document discusses using the fluentd log collector to parse logs from applications without requiring customization. It recommends extending the Tail input plugin to parse logs and provides a link to a code sample. The author expresses excitement to see more plugins developed for fluentd's parsing capabilities.Read less
glTail.rb - realtime logfile visualization
View real-time data and statistics from any logfile on any server with SSH, in an intuitive and entertaining way. FEATURES Real-Time Multiple logfiles on multiple servers Configurable layout Multiple logfile parsers (Apache Combined, Rails, IIS, Postfix/spamd/clamd, Nginx, Squid, PostgreSQL, PureFTPD, MySQL, TShark, qmail/vmpop3d) Custom events Show rate, total or average If you can 'tail' it, you
logtool使ってみた (iptablesのログを見るのに便利だった)
Software Design 2011年2月号 の第一特集内でちょろっと紹介されてた、Logtool を触ってみました。 man logtool すると "logtool - parse and filter syslog files" と記載されている通り、syslog形式やmultilog形式のログ出力をパース、フィルタしてくれるプログラムです。 安定版は 1.2.x tree, 1.2.8 (2005年リリースだけど...) をダウンロードして、RPMパッケージングしてインストールしました。 同梱されていたspecファイルちょっといじる必要ありました。2005年だけあってspecファイルのフォーマットが若干古い。 余談ですが、logtool作者がRedHatのライセンスやポリシーに怒ってシステム全部Debianにしたよ！RPMなんかメンテしねーよ！ って書いてあった。何があったんだ
Webサーバログ転送・ストリーム処理系私案 - たごもりすメモ
HTTPアクセスログをHiveが読める書式への変換やその他必要なデータ変換などストリーム処理で行いつつ転送して最終的にHDFSに時間ごとに書き込むぜー、というシステムを作ってる途中なんだけど、だいたい部品が揃いつつあるところでいったんまとめて書き出してみて見落としがないかどうか考えてみるテスト。 実在のシステムとは異なる可能性があるので(特に後日これを読む人は)あまり真に受けないほうがよいです。あと解析処理自体はHadoop上でHiveでやるのが大前提で、そこにデータをもっていくまでがここに書く話です。 (12/1 考えた末、構成を変えることにしたのでエントリ後半に追記した。) 前提システム 既にscribeを使用したログ収集・配送・保管系がある。各Webサーバは scribeline を使用してログをストリーム転送する。 scribelineのprimaryサーバとして配送用サーバ、se
Apacheログに色を付けて快適tail生活 - y-kawazの日記
ツイッターで「Apacheログをtail中にステータスコード部分だけに色つけしたい」ってのを見たので作ってみた。 #!/bin/sed -f ## MEMO # [0m reset # [1m bold # [3m italic # [4m underline # [5m blink # [30m black # [31m red # [32m green # [33m yellow # [34m blue # [35m magenta # [36m cyan # [37m white s/\(HTTP\/1..\"\) \(2[0-9][0-9]\) /\1 \x1b[34m\2\x1b[0m / s/\(HTTP\/1..\"\) \(3[0-9][0-9]\) /\1 \x1b[32m\2\x1b[0m / s/\(HTTP\/1..\"\) \(4[0-9][0-9]\) /\1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
秒間数万のログをいい感じにするアーキテクチャ
main
Google Code Archive - Long-term storage for Google Code Project Hosting.