コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita
課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可
開発チームの生産性・健全性を可視化できるgilotを触ってみた - Activ8 Tech Blog
こんにちは。 株式会社 Synamon でエンジニアをしております、渡辺匡城(@mochi_neko_7)と申します。 今回はソフトウェアの開発チームの生産性・健全性を可視化できる gilot というツールを触ってみたのでレポートします。 ツールの作者の広木大地さん(@hiroki_daichi)は エンジニアリング組織論への招待 の著者であり、EM.FM などでも開発組織の話を発信されています。 そんな広木さんがツールを作成したと目にしたので、実際に触ってみて、弊社のプロダクトに適用してみました。 日本語での使い方やグラフ、指標の解説は Qiita にもまとめられていますので、こちらも参照ください。 qiita.com 上記の内容の補足として、環境のセットアップや Windows 環境ではまったところ、弊社のプロダクトの簡単な解析結果の紹介をします。 gilot gilot（ジロー）は
Scala + logstash-logback-encoder でJSONログを出力しよう! - FLINTERS Engineer's Blog
こんにちは、門脇(@blac_k_ey)です。 Tetris99に進捗を奪われるのが趣味です。 … 最近、アプリケーションログ周りを整えるお仕事をしておりまして、 その中で logstash-logback-encoder というライブラリを触りました。 使い心地がとても良かったので、今回はScalaアプリケーションでこれを利用する方法をご紹介したいと思います。 logstash-logback-encoderとは JSONでログを出力することの嬉しさ 前置き logstash-logback-encoderを使うための設定 ライブラリ依存を追加する Logbackを設定する logstash-logback-encoder を使ってログを出力する Hello, Logging with JSON! JSONに静的なフィールドを追加する フィールドを動的に追加する StructuredAr
フロントエンドエンジニアなら知っておきたい、JavaScriptのログ収集方法まとめ
サーバーサイドに比べて見落とされがちな、フロントエンドのエラーログ収集。JavaScriptのログ収集、確認に役立つ手法、ツール、ライブラリーを総まとめ。 開発進行中も本番モードでの運用時も、ソフトウェアアプリケーションにおいてロギングは大切です。 サーバーを運用しているなら、サーバーサイドの言語選択にかかわりなく無数のライブラリーを利用でき、広範に及ぶストレージメカニズムやログ出力を扱う際の各種ツールも使えます。 しかし、クライアント側アプリケーションとなるとロギングは見過ごされがちで、利用できる手法もかなり限られています。 この記事ではクライアント側アプリケーション、特にJavaScriptを中心としたシングルページアプリケーション（SPA）におけるロギングの実装方法を紹介します。 コンソール エラーとメッセージのロギング方法でもっとも一般的かつ分かりやすいのは、おそらくコンソールの使
エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
nginxでリクエスト/レスポンスヘッダーをログ出力
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 となる。 ドキュメントのどこか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
