[技術ブログVol.11] ELBのアクセスログをfluentd+Elasticsearch+kibanaで解析 - DENET 技術ブログ
先日ELB（Elastic Load Balancing）のアクセスログがS3に出力できるようになりました。 これによりスケールイン時のログの退避させたりアクセス解析のために各サーバにあるアクセスログを一か所にまとめたりする面倒な手間が省けます。 今回はS3に出力されたログを今流行のfluentd+Elasticsearch+kibanaで解析してみたいと思います。 ELBのログ出力の設定 デフォルトではログ出力はされないのでまずELBがログ出力するようマネジメントコンソールから設定を行います。 ELBの管理画面に行き対象のELBを選択し、[Edit]をクリック 設定画面からアクセスログを有効にし出力間隔やログを保存するS3のバケット等を指定 [Create the location for me] にチェックを入れているとログを出力するS3バケットのACLをよしなに設定してくれるのでお勧
![[技術ブログVol.11] ELBのアクセスログをfluentd+Elasticsearch+kibanaで解析 - DENET 技術ブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/0ed1951e1afa4f7d43d5530eecefd3fd83660d3f/height=288;version=1;width=512/https%3A%2F%2Fblog.denet.co.jp%2F2014%2F04%2Fkibana-300x205.png)
ELBのアクセスログをfluent-plugin-elb-logを使ってkibanaで表示する | DevelopersIO
はじめに 先日お伝えしました通り、ELBのアクセスログが取得出来るようになったのですが、すぐさまfluent-plugin-elb-logというfluentプラグインがリリースされました。さすがfluentd界隈、対応が早いです。 ということで、今回はELBのアクセスログをfluentd経由でElasticsearchに取り込み、それをKibanaで表示したいと思います！ セットアップ Elasticsearch Elasticsearchは最新のrpmパッケージを更新サイトから取得し、rpmコマンドでインストールします。 $ wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.0.0.noarch.rpm $ sudo rpm -ivh ./elasticsearch-1.
大量同時アクセスに備えて ELB を Pre-warming 状態にしておく – I'm Sei.
普段 EC2 を使っていると、ロードバランサーは導入の手間的にほぼ ELB 一択になっちゃいます。 ヘルスチェックはもちろん、高負荷時には自動でスケールしてくれるし、最近やっとコンソールから使えるようになった Auto Scaling とも連携してくれるので、たいへん重宝しています。 ただ、スケールすることを前提としているため、初期状態ではそこまで性能が良くありません。 自分が試した限りでは、HTTPリクエストは 2000 req/s くらいしか捌けませんでした。 また、転送量も 800 Mbps (100 MB/sec) くらいしか稼げませんでした。 (HTTPS の使用や Keep-Alive の設定によっても変わるので一概には言えませんが、ざっくりこのくらいということで。) また、公式のドキュメントによると、スケールするのに 1 ~ 7 分はかかるらしいです。 したがって、徐々にアク
大規模トラフィックを捌くための CloudFront 以外の選択肢 – I'm Sei.
〜 大晦日に秒間 1 万ユーザを捌くためにやったこと (ロードバランサー編) 〜今回、ロードバランサーは全面的に AWS の Elastic Load Balancing (ELB) を使用しました。 Web API を提供するシステムにはもともと ELB を使う予定だったのですが、静的ファイルの配信などは ClouldFront + S3 という構成でいこうと思っていました。 が、最終的には静的ファイルを配信するシステムも ELB + EC2 という構成になりました。 そのへんの経緯とか、AWS を使うときのシステムのフロント周りの負荷分散にはどういう選択肢があるのかとか、軽くまとめてみようと思います。 静的ファイルの配信には CloudFront を使ったほうがいいのかCloudFront は S3 と併用することで、静的なファイルの配信のことはほとんど考えなくていい、というくらい簡単
AWS Solutions Architect ブログ
AWSのソリューションアーキテクトの荒木(twitter: @ar1)です。 Amazon EC2のElastic Load Balancing(ロードバランサ、以下、ELB)のSSLターミネート機能は非常にパワフルで、利用されているユーザも多いかと思います。今日は、その機能を安全に使い続けるためのELBのSSL証明書更新の方法をまとめておきます。 忙しい方向け ELBのSSL証明書更新について覚えておくことは次の３つです。 SSL証明書の更新はマネージメントコンソール、CLIかAPIで可能です。 基本セッション切れはありません。 古くなった証明書はAPIで削除します。 ELBを長年使っていると、SSL証明書の更新のタイミングを迎えることとなります。また、不幸にも更新をせざるを得ない事は起こりえます。そこで、ELBのSSLターミネート機能を使いはじめる前に知っておくことはだれにとっても有益
ELBがアクセスログを出力できるようになりました！ | DevelopersIO
はじめに ついにELBがアクセスログを出力できるようになりました！(Elastic Load Balancing Announces Access Logs) ということでやってみました！ 設定 [Load Balancers]画面を開き、設定したいELBを選択します。画面下部の[Description]タブの一番下に[Access Logs]という項目があります！ なおこの項目は新しいManagement Consoleでしか表示されません。以前のManagement Consoleを使用されている場合は、画面右上に青い吹き出しのようなアイコンが表示されていますので、クリックし「Try the new design」の[Click here]リンクをクリックすると、新しいデザインのManagement Consoleに切り替わります。 さて、[Access Logs]の[Edit]リンク
ELBのEC2のOut of Serviceへの移行について調査
実験結果より考察 2012/11/07までの実験結果で考察してみる。 ELBとして紐づくインスタンスが以下のような状態であるときは記述したような挙動になるようである。 Out of Service：リクエストを投げない(他の生きているインスタンスにリクエストを投げる) In Serviceでコネクションが確立できない場合(サーバ停止中など)：リクエストを投げない(他の生きているインスタンスにリクエストを投げる) In Serviceでコネクションが確立できる場合：リクエストを投げる In ServiceからOut of Servie(もしくはELB管理外)移行時に存在するコネクションは切断され、他の生きているインスタンスがある場合は再度リクエストがそのインスタンスに行くようである。 実験1：ELBに紐付いたEC2インスタンスのサーバーを停止させてOut of Serviceにする ELBに
Termination Protection 対 Auto Scaling - okochangの馬鹿でありがとう
こんにちは＠okoc_changです。 Auto Scalingを使っていると、必要なタイミングでインスタンスが起動することが出来ますし、必要がなくなったタイミングでインスタンスを削除することが出来ます。 また、EC2にはTermination Protection（disable-api-termination）というインスタンスの削除を防止する機能があります。 今回はこれを同時に使った場合の挙動を確認します。 以下のリンクには ”Auto Scaling overrides the instance termination protection attribute, if enabled”と書かれてあります。 http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/us-termination-policy.html ま
ELBのCross-Zone Load Balancingを試してみる - okochangの馬鹿でありがとう
こんにちは＠oko_changです。 今回は先日対応されたELBのCross-Zone Load Balancingについて書いてみたいと思います。 Elastic Load Balancing Announces Cross-Zone Load Balancing 上記リンクには、今までのELBは各AZのEC2インスタンスへの分散はDNSに依存する部分があり、DNSのキャッシュ次第では各AZへのトラフィック分散が偏ってしまう可能性があったと書かれています。 しかしこのCross-Zone Load Balancingを有効にする事で、DNSのキャッシュを気にすることなく各AZのEC2インスタンスに同じようにトラフィックが分散されるようです。 ※英語なので間違ってたらごめんなさい＞＜ 今回の検証構成 以下のようにシンプルな構成です。 Cross-Zone Load Balancingを有効
ELB で SSL 復号するときしないときのベンチマーク - Qiita
sudo yum install npm --enablerepo=epel npm install express cat <<EOT >index.js var app = require('express')(); app.get('/*', function(req, res) { if (req.query.wait) { setTimeout(function() { res.write('OK'); res.end(); }, req.query.wait); } else { res.write('OK'); res.end(); } console.log('%s %s %s', new Date(), req.method, req.url); }); app.listen(10080); EOT node index.js $ ab -n 5000 -c 200 ht
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
