Ultimate Guide to Python Debugging
Even if you write clear and readable code, even if you cover your code with tests, even if you are very experienced developer, weird bugs will inevitably appear and you will need to debug them in some way. Lots of people resort to just using bunch of print statements to see what's happening in their code. This approach is far from ideal and there are much better ways to find out what's wrong with
【第21回Elasticsearch勉強会】aws環境に合わせてelastic stackをログ分析基盤として構築した話
データベースにおけるSaaSパーティショニングモデル、データベースエンジン毎の構成イメージ、マルチテナント化に向けた考慮点について解説しています。
2種類のログ解析基盤 - wyukawa's diary
僕は仕事では2種類のログ解析基盤を見ています。 1つ目はどちらかというとエンジニアよりの解析基盤でサービス側のエンジニアがShib, ShibUIを通して好きにクエリを投げることができます。ただしtableをcreateしたりdropしたりinsertしたりはできません。selectのみです。データの更新作業は別途cronのhive batchで行います。データはFluentd経由で各サービスのサーバーから収集します。こっちのシステムは古くからあって僕は引き継いだだけなので見ているとはいってもそんなにやることは無いですし、語れることも少ないです。 2つ目は約1年前に僕が一から構築したシステムでプランナーよりのシステムになってます。僕のチーム内のエンジニアだけがrawデータを触ったり更新したりすることができて、プランナーはレポートを通して加工されたデータを見る形になります。なので1つ目のシス
地味でつまらないログ収集をおもしろおかしく! 最強ログコレクタ「Fluentd」のチカラ
2013年になってもバズり続けている"ビッグデータ"ですが、データ分析において最も重要となるプロセスは何かというと、やはり肝心のデータを集める作業ではないでしょうか。そしてデータからビジネスに役立つ情報を高い精度で得ようとするなら、やはり母集団となるデータの量は多いに越したことはありません。 中でもソーシャルネットワークやソーシャルゲーム、eコマースなどBtoCなWebサービスを提供している企業の場合、ユーザの振る舞いを記録した膨大なアクセスログは、ビジネスを展開していく上で何よりも大切な宝ものだといえます。サービスの品質を向上し、収益性を高め、競合と差別化を図っていくためには、ログから何を読み取るかが勝負の分かれ目になります。そしてログ解析の精度を高めるには、当然ながら大量のログが必要です。つまりログ収集という作業は本来、Webアプリケーションを使ったビジネスであれば最も手を抜いてはいけ
開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - naoyaのはてなダイアリー
開発メモ#6 です。前回から少し間があいてしまいました。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で書いたように、EC2 へのアプリケーションのデプロイにあたっては Elastic IP の利点を活かしてカジュアルにホストを入れ替えまくっています。ちょっとこのデプロイは慎重になりたいな、と思ったらスナップショットからインスタンスを立ち上げては切り替える、の繰り返し。 この運用をしていると、スナップショットとの差分ができやすいのは chef-solo で吸収するというのが前回、前々回のはなし。 もう一点問題があります。アクセスログやアプリケーションのログです。フロントエンドのサーバをあっちこっち切り替えているうちに、そのままではログが分断されてしまう。ホストを Terminate しようものならログは消失してしまいます。 この
統合ログ管理基盤としてのFluentdを試してみました。
先日、朝ご飯を家で食べてきたにも関わらず、通勤途中の駅のカレー屋さんの匂いに誘惑され、 朝カレーしました！周りのメンバーにはこの幸せがまったく響かなかったのが残念です。 アライドアーキテクツの唯一のインフラ基盤エンジニアの平野です。 「からあげ朝カレー」というメニューでした。 さて今回のお題は、インフラ界隈で盛り上がりを見せているFluentdという技術についてです。 私ももれなくこの技術に注目し、先日もFluentd Meetup in Japan #2 に参加させていただいたり、 自社のシステム合宿で、周りのメンバーが粛々とプログラムをしている横でFluentdをいじり倒してました。 ◇背景 昨今ビッグデータ、ビッグデータと注目され、Webサービスにおけるユーザの行動解析、 即時性のあるマーケティングデータの抽出要望がシステムに課せられます。 NoSQLと呼ばれる大量データを分散処理に
fluent-agent-lite と td-agent で、小さくはじめる fluentd - Studio3104::BLOG.new
fluentdを使ってみたいけど、「JSONでシリアライズしなくていいのに・・・生でいいのに・・・」と思ってなかなか使い出せないというケースはままあるのではないでしょうか。 こんなときに困ってしまうからですよね。 rsyncやscpで毎日深夜にやってくる生ログを解析するスパゲッティスクリプトたちを使えなくなってしまう アプリケーションサーバにログをパースさせるための負荷をかけたくない それでも使ってみたい、現存の古臭い解析機構をアクティブにしたまま、徐々にfluentdによる先鋭的なログ解析を始められたらいいなと思っている方、 fluent-agent-lite と td-agent で、fluentd を小さくはじめてみたらいいと思います。 結論を先に言うと、fluent-agent-lite + fluent-plugin-file-alternative + fluent-plugi
Fluentd meetup #2
20121115 オープンソースでハイアベイラビリティ！ ～クラスタ管理の設計構築ハウツー＆エンジニア思考力～Iwasaki Noboru
#fluentd で maillog を読み込んで MongoDB に投入 - 酒日記 はてな支店
MTA が吐く maillog は普段あまり見ないのだけど、トラブルがあったときには大変重要。これも Mongo に入れれば、問い合わせがあったアドレスで検索してログを管理画面で見るとかできて便利！ということでやってみた。 # fluentd.conf <source> type tail path /var/log/maillog tag maillog format /^(?<date>[^ ]+) (?<host>[^ ]+) (?<process>[^:]+): (?<message>((?<key>[^ :]+)[ :])? ?((to|from)=<(?<address>[^>]+)>)?.*)$/ </source>正規表現がなかなかですが、これで maillog を parse して以下のような生ログから 2012-03-26T19:49:56+09:00 worker00
イベントログ収集ツール fluent リリース！ - Blog by Sadayuki Furuhashi
こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました！ Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です：イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め
Quickstart Guide | Fluentd
Let’s get started with Fluentd! Fluentd is a fully free and fully open-source log collector that instantly enables you to have a ‘Log Everything’ architecture with 125+ types of systems. Fluentd treats logs as JSON, a popular machine-readable format. It is written primarily in C with a thin-Ruby wrapper that gives users flexibility. Fluentd’s scalability has been proven in the field: its largest u
ウィークリーFluentdユースケースエントリリレーまとめ（現在12本まで。） - oranie's blog
ウィークリーFluentdユースケースエントリリレーの記事をまとめます。 書いた人はhttp://www.zusaar.com/event/415005で次の人に順番が来たと教えてあげて下さい。 ウィークリーとか書いているけど、早く書けたらバンバン回しちゃってね！あと、参加人数が想像以上に多いので2人同時に依頼させて頂きます＞＜ #1 oranie 「tailプラグインの仕様について」 #2 studio3104 「fluentdで、1つのログから複数のメトリクスを得る。」 #3 shun0102 fluent-plugin-dstatの紹介 #4 tnmt fluentdのout fileプラグインの仕様について #5 fujiwara fluentdで複数箇所から同一のファイルに出力する #6 riywo fluentdのプラグインとかユースケースの話 #7 kenjiskywalke
ITmedia エンタープライズ：PD思考法の基礎と情報収集（その2）
Linux環境で問題が発生した場合、管理者がするべきことは「その原因がどこにあるか」の正確な把握である。今回は、発生した問題に対し原因がどこにあるかを判別するための基本的な考え方と、問題判別に必要な情報収集の基礎について解説しよう。 情報収集のポイント PDにおいて、問題を特定するために情報収集は必要不可欠である。実際に収集すべき情報はケースに応じて異なるが、問題自体に関する記録がないからといって、不要な情報であるとは限らない。情報の収集は、問題そのものを直接に特定するほか、システムの構成や問題点を絞り込むための要素を見つけるためにも必要である。そのことを認識して、情報収集を行っていただきたい。 Linuxで取得できる情報には、OSやユーザープロセスの稼働に関するものと、ハードウェア関連の構成に関するものがある。また、ハードウェアの稼働に関する情報はBIOSから直接取得するほか、最近のIA
klogd - Linuxの備忘録とか・・・(目次へ）
ログファイルとロギングの仕組みのklogdについて記事を読んで、成る程。という思い出でした。それを踏まえてこの記事をアップします。従って内容的には先のシステムログ1/システムログ2の焼き直しみたいなものです。 klogdとカーネルのログデーモンと言う事で、カーネルスレッドと思ってしまいそうですが、ログファイルとロギングの仕組みの図解のように、ユーザランドから起動されるもので、もちろんユーザプロセスです。(なお、図解ではdmesgも/proc/kmsgから取得するようになっていますが、私の調べたレベルではdmesgは直接リングバッファから取得しているようです。） /proc/kmsgから読み出すと、do_syslog()をtype=2でコールしていました。その処理はlog_start - log_end=0なら、log_waitキューでウエイトさせていました。 DECLARE_WAIT_QU
fluentdで、1つのログから複数のメトリクスを得る。 - Studio3104::BLOG.new
ウィークリーFluentdユースケースエントリリレーの記事です。 「1つのログから複数のメトリクスを得る」という目的主眼の記事です。 各プラグインの仕様や紹介していないオプションについては、他の方が書かれる記事や、作者様のブログやGitHubをご参照ください。 WEBのレスポンスタイムをグラフ化する fluentd casual talks で、fujiwaraさんが発表されたfluentdでWebサイト運用を楽にするがきっかけで、WEBのレスポンスタイムを可視化し始めた方、多いと思います。 (かなり極端な例ですが)こんなふうにグラフが出ることによって、「14:30頃からレスポンスが著しく悪くなっている！」ということが見て取れるようになります。 これによって"14:30から遅い応答が増え始めた"ということはわかるようになるのですが、「じゃあどこが遅いの？」となって結局生のログを漁ったりする
ログ解析を支えるNoSQLの技術
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～ （Kubernetes Meetup Tokyo #33 発表資料） 2020/08/26 NTT DATA Yasuhiro Horiuchi
Web上でシステムログの閲覧、監視·Clarity MOONGIFT
ClarityはRuby製のオープンソース・ソフトウェア。システムのログを見る際にはSSHを使ってサーバにログインして確認するというのが一般的だ。だが何台もあるサーバに個々にログインするのは面倒だ。社内のサーバであれば、セキュリティ的にも厳しい制限がないことも多い。 そこで使ってみたいのがWebブラウザベースで使えるログ監視ツールだ。Clarityはサーバ上で実行することでWebブラウザ上でログ閲覧を行える。監視したいログの種類も設定できるので、多数のサーバを管理する上で便利に使えるかも知れない。 モードは二つあり検索とTailになっている。検索は指定したログファイルから入力した検索ワードをチェックし、一覧で結果を表示する。Tailはまさに更新されるたびに表示が追加されるTailだ。自動スクロールを有効にすれば自動的にスクロールして表示が更新されるようになる。 背景は黒、文字は白でターミナ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Log Pattern Recognition: LogMine
fluentd を利用した大規模ウェブサービスのロギング
Fluent event collector