AWSでの法令に則ったログ設計及び実装/分析 - Adwaysエンジニアブログ
エージェンシー事業でリードアプリケーションエンジニアを行なっている大窄 直樹 (おおさこ)です. AWSのログ, サーバーのログってたくさん種類があって難しいですよね... 同じようなログがたくさんあるので, 何を取れば良いのかとか どのくらいの期間保持すれば良いのかとか またその後の, ログの実装や, 分析方法する方法も難しいですよね... 今回AWSに構築した商用アプリケーションのログを整備する機会があったので, このことについて書こうかなと思います. 概要 本題に入る前の準備 今回ログ実装するアーキテクチャ ログに関する法令 ログの取得箇所 設計 保管するログの決定 インフラのログ OSのログ アプリケーションのログ ログの保管 保管場所について 保管期間について バケット構造 アプリケーション, OSのログの転送 実装 アプリケーション, OSのログをfluentbitを用いてS3
個人的AWS ログ管理のベースライン - mazyu36の日記
AWSのログ管理についてはいくつか考えるポイントがあると思います。 どのログを保存するか。 CloudWatch Logs（以下CW Logsと記載）とS3のどちらに保存するか、もしくは両方に保存するか などなど。 システムの特性によるところも多いかと思いますが、自分の中でのログ管理のベースラインが定まりつつあるので、頭の整理がてらまとめます。 自分の中での大まかな方針としては以下です。 S3に保存できるものは基本S3に保存する。 以下の場合は、CW Logsに保存する。必要に応じてS3に転送する。 アラームを出したい場合 さっとCW Logs Insightでログを確認したい場合 CW Logs に出さざるを得ない場合 全体像としては以下になります。 なおあくまで個人的な経験に基づくものなので、実際にはシステムの特性を踏まえて方針の決定が必要かと思います。 またこれは必要、これは不要など
scriptとpsacctでオペレーションログを記録する | DevelopersIO
scriptは、実行コマンドとその結果をそのままテキストファイルに保存するコマンドです。 一方、psacctはバイナリファイルにコマンドの実行ログのみを保存するサービスです。 scriptによるログの保存 scriptコマンドで作業ログを記録でも紹介されていますが、scriptコマンドを利用するとコマンドの操作ログをファイルに記録することができます。このコマンドを利用し、SSHでログインした後のコマンド操作を記録できます。 SSHログイン後に、この設定を有効にするために /etc/profile （または ~/.bash_prrofile）の末尾に以下のコマンドを追加します。 # output operation log P_PROC=`ps aux | grep $PPID | grep sshd | awk '{ print $11 }'` if [ "$P_PROC" = sshd:
CloudTrail ログファイルの整合性の検証機能は有効化しておきましょう | DevelopersIO
地味な機能ですが CloudTrail ログファイルが攻撃者によって改ざんされる可能性も 0 ではありません。CloudTrail ログファイルの整合性の検証機能は有効化しておきましょう。 AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWS のアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 はじめに 昨今、AWS のアクセスキーを不正利用した攻撃が増加してきております。 攻撃方法はどんどん巧妙化されており、CloudTrail ログファイルを
コンテナログ処理の技術的なベストプラクティス：Dockerのケーススタディ - Qiita
この記事では、Dockerを例に、コンテナログ処理の一般的な方法やベストプラクティスをいくつか紹介しています。 背景 Docker, Inc. 旧社名：dotCloud, Inc）は、2013年にDockerをオープンソースプロジェクトとしてリリースしました。その後、Dockerに代表されるコンテナ製品は、分離性能の良さ、移植性の高さ、リソース消費の少なさ、起動の早さなど複数の特徴から、瞬く間に世界中で人気を博しました。下図は2013年からのDockerとOpenStackの検索傾向を示しています。 コンテナ技術は、アプリケーションの展開や配信など、多くの便利さをもたらします。また、以下のようなログ処理のための多くの課題ももたらします。 1、コンテナの中にログを保存した場合、コンテナが取り外されるとログは消えてしまいます。コンテナは頻繁に作成・削除されるため、コンテナのライフサイクルは仮想
Webアプリケーションのログに関するいくつかの考察 - Hatena Developer Blog
こんにちは、はてなでWebアプリケーションエンジニアをやっている id:polamjag です。 最近のはてなでは、若手エンジニアを中心として、いろいろな技術を見つめ直すワーキンググループをやっています。先日、id:onk も「デプロイ今昔」という記事を書きましたが、このエントリーはそのシリーズの続きで、ワーキンググループの「ログ」の回で議論したこと・話題になったことをまとめました。 Web開発におけるログを見つめ直す ログを4つの目的で分類する 目的ごとに求められる取り扱いの要求水準 いまどきのログフォーマットについて まとめ：どう実装するかを模索していく Web開発におけるログを見つめ直す Webサービス（Webアプリケーション）の運用には、多種多様なログがついてまわります。多くのミドルウェアは何もしなくてもそれなりの量のログを出力しますし、クラウド上のマネージドサービスも然りです。行
マイクロサービスのアプリケーションログ転送量の抑制と改善 | DevelopersIO
はじめに こんにちは。こむろ＠事業開発部です。あ、今回も改善の話です。新機能開発とかそういった話はありませんのであしからず。 所属している事業開発部では、prismatixというECプラットフォームサービスを開発・運用しております。ECですので、商品の管理、検索、購入や会員管理等の多種多様な機能があり、それぞれのサービスでは日々膨大なアプリケーションログを記録しています。 アプリケーションログは正常動作している時は、あまり必要ではないのですが、いざ何らかの問題が発生した際に、原因究明やデータ復旧には欠かせないデータです。従って保険としてできれば全てを保存しておきたいところです。 しかしながら、このログの保存。機能の数やリクエスト規模にもよりますが、膨大が故に非常にお金がかかります。そして正直なところ大抵は利用されないゴミです。 *1 このあたりの話については、Release It! 本番用
ロギングベストプラクティス - kawasima
#翻訳 https://www.scalyr.com/blog/the-10-commandments-of-logging/ CC BY 4.0 @Brice Figureau 1.自分でログの書き出しをしない printfをつかったり、ログエントリを自分でファイルに書き出したり、ログローテションを自分でやったりしてはいけない。運用担当者にお願いして、標準ライブラリやシステムAPIコールを使うようにしよう。そうすれば、実行中のアプリケーションが他のシステムコンポーネントと適切に連携して、特別なシステム設定なしに適切な場所またはネットワークサービスにログを記録できるようになる。 ロギングライブラリを使いたければ、特にJavaの世界にはLog4j, JCL, slf4j, logbackなど多くのものが存在する。私はslf4jとlogbackを組み合わせて使うのが好きだ。とてもパワフルで、設
ログ設計指針
概要 このドキュメントは、効率的かつ安定した、システム開発/運用をするためのログ設計指針です。 的確かつ無駄のない、ログ出力を目指します。 ログレベル ログの緊急度や用途により、以下のようにログレベルを設定する。 Log4j のログレベルを踏襲しているため、運用の状況によっては Critical などのレベルを適宜追加すると良い。 PHP における PSR-3 では、さらに細分化され emergency, alert, critical, error, warning, notice, info, debug となっている。 「出力先」「運用時の対応」は、各プロジェクトのポリシーに準じてください。 レベル 概要 説明 出力先 運用時の対応
エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
ログ分析勉強会 vol.1 - 資料一覧 - connpass
終了 2015/10/15（木） 19:00〜 ログ分析勉強会 vol.1 セキュリティの陣 kenji kobayashi 他 東京都千代田区平河町2-16-1 平河町森タワー2F
Logにまつわるエトセトラ
(きっと)あなたにも出来る！Hyperledger composer でブロックチェーンアプリを動かしてみたK Kimura
Webサーバのログをリアルタイムで解析、監視できる『GoAccess』コマンド | 俺的備忘録 〜なんかいろいろ〜
今回は、Webサーバのログ解析をリアルタイムで行えるコマンド『GoAccess』を紹介する。 1.インストール まずはコマンドのインストールから。 以下のコマンドを実行する。 ソースコードからmakeする場合 wget http://tar.goaccess.io/goaccess-0.8.5.tar.gz tar -xzvf goaccess-0.8.5.tar.gz cd goaccess-0.8.5/ ./configure --enable-geoip --enable-utf8 make sudo make install パッケージ管理ソフトからインストールする場合 brew install goaccess (Mac OS Xの場合) sudo apt-get install goaccess (Debian/Ubuntuの場合) sudo yum install goacc
logstash を試す - ようへいの日々精進XP
きっかけ fluentd + Elasticsearch + Kibana を試した流れで logstash というソリューション があることを知ったので試す logstatsh について Rebuild: 19: Accents, Git Workflow, Logging (sekimura) でも触れられていたのでちょっちタイムリー こちら 愛らしいｗ公式キャラが何とも言えない Kibana のログ収集を担っている Java が必要 JRuby で実装されている 検索エンジンに Elasticsearch が利用されている Plugin 方式を採用している Web UI が動く（Kibana 3 を使っている） スタンドアローンで動作させることも可能 一箇所で集中管理するようなソリューションもあり、以下のようなアーキテクチャで実装されている（図は拝借） 試してみる チュートリアル的な
ログ集計システムを自前で作る - Y's note
Index ログ集計システムの要件 DB設計 データ保存方針 table設計 サーバ構成 Fluentd fluentd,fluent-plugin-mysql-bulk install td-agent.conf mysqlにデータが格納される事を確認する 集計用のバッチ その他 Table肥大化防止 可視化 ログ集計システムの要件 爆弾ログ処理班の@yutakikuchi_です。 ログ集計システムというものを作る時に皆さんはどのように対応していますか？ 以下の候補から要件のレベルで使い分けをしている人が多いと予想しています。ざっくりの評価ですが、導入難易度、正確性、可視化、リアルタイム、長期集計、スケール、運用費用という点で評価を書いています。 ツール 導入難易度 正確性 可視化 リアルタイム 長期集計 スケール 運用費用 リンク GA(スタンダード) ○ × ○ ○ ○ ○ ○ Go
ログの差分出力スクリプト - mikedaの日記
昔Perlで書いたやつのRuby1.9版をとりあえず作りました ログファイルを指定すると、前回実行からの差分を出力してくれます $ echo 111 > test.log $ ./logtail.rb test.log 111 $ echo 222 >> test.log $ echo 333 >> test.log $ ./logtail.rb test.log 222 333 ソースコード #!/usr/local/bin/ruby # ログの差分出力スクリプト # 使用例 # 前回実行からの追記分を出力する # $ logtail.rb access_log # # ログのローテートに対応させる場合はオプションでローテートファイルを指定する # $ logtail.rb access_log -r access_log.1 # # デフォルトでは/tmp/<ログファイル名>.logt
アクセスログをスマート解析してくれる「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)
rsyslogでNW機器のログ集約 - mikedaの日記
NW機器のログはsyslogサーバに集約してWEBで見れるようにしてます 理由はこのへんです。 いちいちログインして見るのがダルい 障害時にログインして確認しようにも入れないことが多い（だってNW機器ですもん） 仕方ないので再起動するとログ消えちゃう 見ためはこんな感じ（サンプル） サーバ一覧 日付ごとのログ一覧 ログの中身 ずっとsyslog-ng派だったのですが、時代の流れに逆らえずrsyslogを使ってみたので手順をメモっておきます。 環境はCentOS6 & rsyslog5.8です。 手順 /etc/rsyslog.confを編集 # モジュール読み込み。UDP追加 $ModLoad imuxsock $ModLoad imklog $ModLoad imudp # Apacheユーザで読めるようにパーミッション設定 $umask 0000 $DirCreateMode 0755
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Log解析の超入門
サービス改善はログデータ分析から
