Goのロギングライブラリ 2021年冬 - moriyoshiの日記
この記事はPySpa Advent Calendar 2021の14日目のエントリーとして書かれました。昨日のエントリーは冷凍食品でウキウキ引きこもり生活 でした。ちなみに私も70ℓの冷凍庫を購入しましたが本当にライフチェンジングでした。 総論: なぜログが必要か 可観測性 たとえ目的は自明でも、その動作までが自明なアプリケーションというものはほぼ存在しません。現実の世界のアプリケーションというものは、動作パラメータだったり実行環境だったり、起動時点でのさまざまな要因によって挙動を変えるものだからです。そして、そうしたアプリケーションにはライフサイクルというものがあります。ここでいうライフサイクルは、アプリケーションの処理が実行されるにつれ、アプリケーションの内外との情報のやりとりで生じる大局的な状態の変化のことです。アプリケーションが並行処理を行うようなものであれば、個々の並行処理の単位
分析と改善 Gunosyの大規模ログ解析を支える2つのアーキテクチャの裏側
2018年6月22日、Architecture Nightが主催するイベント「Architecture Night #1」が開催されました。単一のAPIではなく、複数のAPIが絡まって成立するような複雑性の高いアーキテクチャをどのように構成し、運用しているのか？ 各社が自社の知見を披露します。第1回となる今回は、Gunosyとサイバーエージェントの2社が登壇し、自社で用いられるアーキテクチャを紹介します。プレゼンテーション「Gunosyのログ収集基盤」に登壇したのは、株式会社Gunosy、開発・運用推進部 SREの茂木大夢氏。ニュースアプリGunosyのログ収集基盤で用いられる大規模アーキテクチャについて解説します。 グノシーのアクセスログ解析基盤 茂木大夢氏（以下、茂木）：「グノシーのアクセスログ解析基盤」というタイトルで発表させていただきます、茂木と申します。mgi166という名前でや
Dockerコンテナログパターン
MasterCloud #6 での発表資料です。 https://mastercloud.connpass.com/event/67023/
ソーシャルゲームのカスタマーサポートを支える行動ログとredash - KAYAC engineers' blog
この記事はTech KAYAC Advent Calendar 2016の21日目の記事です。 こんにちは、ソーシャルゲーム事業部のぼくらの甲子園！ポケットのサーバサイド開発・運用を担当しておりますマコピーことid:mackee_wです。 ↑のヘッダ画像の人物はワタクシ、という噂があります。みなさま答えはあっていましたでしょうか。 ぼくらの甲子園！ポケットとは 2014年9月にリリースされた共闘スポーツRPGのスマートフォン向けゲーム 現在3年目でございます！！！ 甲子園をモチーフにしてプレイヤーとプレイヤーが協力して別のチーム(CPUではない)と対戦して甲子園の頂点を目指す チーム(高校)の部員がプレイヤー9人揃わなければ試合が始まらない縛りとかも特徴です そんな感じで運営しておりますので興味を持たれましたらこちらからダウンロードのほどよろしくお願いしますm( )m。 ちなみにこの記事は
GoAccess - Visual Web Log Analyzer
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
Go言語のLogger「zap」は何故高速に構造化されたログを出力する事が出来るのか｜株式会社CA Wise
こんにちは。開発部の平田です。 今回は、PHP製のWeb APIをGoに移植するプロジェクトでアプリケーションの情報やエラーを出力する為のLoggerを検討した際に、uber-go/zapというライブラリが公表しているパフォーマンスがその他ライブラリと比べて大分良かったので、どこでパフォーマンスの差を出しているのか、そのアプローチを簡単に紹介したいと思います。 Zap 初めに、簡単にzapの紹介をしておくと今年の2月にUberから公開されたまだ比較的新しいプロダクトです。その為開発ステータスはBetaの段階で出力もJSONしか対応していませんが、Github上で800以上のスターが付いており注目されているプロジェクトとなっています。 「Fast, structured, leveled logging in Go」とあるように、構造化されたログを出力するためのライブラリで、標準のlogのよ
Tornado アプリのログファイル書き込みのチューニング : DSAS開発者の部屋
最近は協力プレイやPvPなどの「リアルタイムサーバー」を書くときは Go が主流になっているのですが、 Tornado を使ったシステムも健在です。 (以前の記事) 数人〜十数人程度の「部屋」を、1つの Tornado プロセスに複数もたせ、さらに一台のサーバーにその Tornado プロセスを複数置くことでCPUのマルチコアを活用する構成になっているのですが、最近各プロセスがログファイルを書く部分でブロックして応答性能が悪化するケースがあったので対策しました。 この記事ではその対策で行ったチューニングや、行わなかったチューニングについても紹介します。 ※なお、この記事は Tornado を題材にしていますが、似たような仕組みになっている node.js などの他の言語のフレームワークでも同じ事が言えるはずです。 前提知識 Tornado は epoll や select などのIO多重化
ログに何を出力するべきか - 日々量産
仕事でHTTPで使うAPIを書いているのだけど、問題が起きた時にログの内容から問題を特定できないといった問題があり、ログを見直すことになった。 そもそも、自分は今まで運用時の問題を意識してログを書いたりとかしたことがなかったので、何が必要なのかとか考えてみた。 何か良い感じの規則を決めるだとか、何も考えなくてもよい感じに解決してくれるような、そんな感じの答えを求めてる。 書きたいこと ログに出すべき情報 ログはあまり出さないほうがよいか 一例 たとえば、あるユーザが商品を購入しようとしたとき、システムエラーになったとする。 システム側の都合でエラー画面を出されたら、ユーザはいい気持ではないだろうから、早急に直す必要がある。 システム側はシステムエラーが起きていることはわかった。 しかし、この原因を特定したいとき、どういう情報が必要だろう。 ログに出すべき情報 当然、問題が起きた時にその問題
Amazon CloudWatch Logsでログファイルを監視する ｜ Developers.IO
ども、大瀧です。 本日開催されているAWS Summit New YorkでCloudWatchの新機能、CloudWatch Logsが発表されました。 バックでKinesisが動いているらしく、スケーラブルなログアグリゲーションサービスとして期待できそうです。ひとまず、どんなものか試してみたのでレポートします。 1. IAMユーザー/IAMロールの準備 動作する仕組みは一般的なログアグリゲーションサービスと変わらず、ログ収集対象のマシンにエージェントをインストールし、アグリゲータにログを順次送信する形態です。エンドポイントはCloudWatchのAPIなので、他のAWS APIと同様にCloudWatch Logsに必要な以下の権限を付与したIAMユーザー、もしくはIAMロールを準備します。 { "Version": "2012-10-17", "Statement": [ { "Ef
【進撃の巨大データ】Log集計用DBとシステム構成の美しい設計を考える - Y's note
[:W560] Log集計用DB設計 考える問題 Document無しのAgile開発をガチで推奨したい@yutakikuchi_です。【進撃の巨大データ】の第2回目として巨大アクセスLog集計用DBの設計について勉強した内容についてメモしたいと思います。DB周りはそこまで詳しく無いので詳しい皆様からの突っ込み大歓迎でございます。また図々しいですが知恵をください(笑)。 今日の主目的は下の2要件を叶えるためのDB設計を考える事です。特に問題になるのがRealTimeの話でTableにLogDataを書き込む処理と集計のSQLをどのように組み立てるか、それ以外にもSystemPerformanceとArchitectureにも関わってきます。 リアルタイムで大量データを集計したい 定期処理で大量データを集計したい 使うもの Fluentd : Fluentd: Open Source Log
感情に訴えかけるログ、 Log::Minimal::Emotional ！！！！ - （ひ）メモ
某所で 人間の脳には人の顔を識別するための特別な神経回路が最初から組み込まれていて、人の顔の違いを見分けたりというのが、他の図形よりも格段に高速に行えるようになっています。ということで、ログメッセージに顔文字を入れてみたら、なにこれすごいヽ(=´▽`=)ﾉ ってなったところ。 という発言をみかけたので、つくりました。 Log::Minimal::Emotional - https://gist.github.com/hirose31/4958764 「エモーショナル」はお好みなものに容易に再定義可能です。 #!/usr/bin/env perl use strict; use warnings; use utf8; use Log::Minimal::Emotional; $Log::Minimal::Emotional::EMOTION->{CRITICAL} = '⊂二二二（ ＾ω＾）
App::YG - ログをう゛ぁーてぃかるぱみゅぱみゅしちゃう！！ - Articles Advent Calendar 2012 Hacker
やあハッキングモンスターのみんな、元気かーい？ ぼくは普通です。 きょうはみんなでログをう゛ぁーてぃかるぱみゅぱみゅしちゃうぞ！あ、こんにちは bayashi です。 さて、ログは見てるかい？cat してるかい？ tail してるかい？ GB単位のログを vim で開いてフリーズさせてやいないかい？ログは吐いたら終わりじゃいけないぜ！ちゃんとうぉっちしないと鬼がでちゃうぞ！！ とはいえ、そんなログも、たいていは1行につらつらと書かれてて見るのがつらいね！！例えばこんなやつだ。 $ tail log 127.0.0.1 - bayashi [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.0 (compatible
YappoLogs: サービスをつぶさない為に Web アプリを書く時にやっとくと良い事2選
サービスをつぶさない為に Web アプリを書く時にやっとくと良い事2選 テンプレートのエラーが出た時にアプリケーションのログだけに書くのでは無く、誰にでも「ここがえらってるよ！」って見えるようにしとくと間違いが少なくなる傾向があるのでテンプレートエンジンでフック出来るようになっておいてたら、それをうまく使うと良い。 また、テンプレートエンジンがレンダリングしてるフェーズで DB にクエリが飛ぶような構造で書いてあると、非エンジニアのカジュアルにテンプレートいじる人が甚大なクエリを実装してしまう可能性があるので、これも早期に発見しないとサービスが止まってしまい会社の売り上げが下がってしまい社員が路頭に迷うケースが発生してしまうので、これらも未然に防がなければならない。 Text::Xslate + Amon2 ならこうかける。 package MyProje::Web; ...; { my
Apacheのサンプルログを生成し続けるスクリプト
最新の記事はこちらです。 Fluentdのテストをする過程で欲しかったので、Apacheのログを生成し続けるスクリプトを書きました。 と言っても生成部分はTreasureDataのスクリプトを丸ぱくりで流量制限をするオプションを追加して延々と出力するようにしただけです。 frsyuki++。 手元でサクッとproductionで確認できる人はうらやましす。 使い方は以下のような感じです。詳細はREADMEを見てください。 ruby sample_apache_gen.rb [--rate=0] [--limit=0] [--rotate=0] [--progress] [--json] [outfile] --rate 毎秒何レコード生成するかの指定。0以下は制限無し。 --limit 最大何件出力するか。0以下は延々と出力し続ける。 --rotate ローテーションの間隔。単位は秒指定。
Introduction of 'fluentd'
Introduction of ’fluentd’ — Presentation Transcript Introduction of ‘fluentd’@just_do_neet 1 Today’s Agenda•Backgrounds and Motivations•Introduction of ‘fluentd’•Real cases and Demos•Conclusion 2 Backgrounds and Motivations 3 Log analysis in the ‘not rare’ services•Analysis processing is done once every day. •Collect logs from multiple servers. (ex. rsync/scp/etc...) •Analysis of data using collecte
イベントログ収集ツール fluent リリース！ - Blog by Sadayuki Furuhashi
こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました！ Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です：イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め
Logstash：データの一元化、変換、保管 | Elastic
オブザーバビリティも、セキュリティも、検索ソリューションも、Elasticsearchプラットフォームならすべて実現できます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[Black Belt Online Seminar] AWS上でのログ管理![[Black Belt Online Seminar] AWS上でのログ管理](https://cdn-ak-scissors.b.st-hatena.com/image/square/4aa4db5464ac5ff8d2004c37991044a9b7729933/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Faws-log-mgmt-161201043056-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
秒間数万のログをいい感じにするアーキテクチャ
Webアプリケーションのログについてあれこれ - 酒日記 はてな支店
