2013年4月30日火曜日

sumologicってなんじゃ?(sumologic fluent pluginをつくってみた)

ログ解析システムはいろいろあるみたいで、今回はsumologicを触ってみました。

sumologicはサービス型のログ解析システムです。
このサービスについて、また、ログ解析システムが何故必要とされているかは以下のAWS荒木さんのスライドがわかりやすいです。

ログブラウズ、解析サービスSumologicの紹介
http://www.slideshare.net/ar_maniacs/sumologicno

さっそく使ってみます。
いままでと同じようにfluentdでデータを入れ込みたいのですが、Sumologic用のPluginはないようです。
ログ収集基盤としてfluentdで統一させたい場合もあるので、今回はSumologic用のプラグインも作ってみます。



Sumologicへの登録と設定



まず、会員登録して、ログインします。


「Get Started Now」をクリックします。

次にCollectorを追加します。Collectorはログ収集コンポーネントです。
Collectorにはログがあるサーバー側にモジュールをインストールすることもできますし、ログサーバー側で待ち受けることもできます。今回は後者を選択します。


「Add Collector」の画面で「Hosted Collector」を選択します。




ここでは仮に「testhost」という名前で登録します。




次に作成されたtesthostの「Add Source」をクリックします。




すると、入力ソースの選択画面が表示されます。
S3のデータがある場合はS3の場所を設定します。
今回は、fluentでログを送るので、HTTPタイプを選択します。



詳細な設定画面が表示されますが、とりあえずNameだけ入力して「Save」します。



作成されたら一段落です。




あとでfluentdのエンドポイント設定に使用するため、ソースの「Show URL」で表示されるURLをコピーしておきます。





Fluentdの設定



次にfluentdの設定です。
sumologic用のプラグインが無かったので作ってみました。
テストコードはスタブのままですが、、

fluent-plugin-sumologic
https://github.com/memorycraft/fluent-plugin-sumologic
https://rubygems.org/gems/fluent-plugin-sumologic



作成手順は、tagomorisさんの記事が非常に参考になります。

これをtd-agentにインストールします。
# /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-sumologic


sumologicはjsonのパースが面倒そうなので、今回は、素のテキストで送って、プリセットのapacheフォーマットでパースさせます。そのためapacheログのinputには普通のtailではなく、生のフォーマットでtailできるtail_asisを使用しました。
# /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-tail-asis


次に設定ファイルです。
sumologicの設定では、host, port, path は先ほどコピーしたURLを分解したものをそれぞれに設定します。
<source>
  type tail_asis
  format apache
  path /var/log/httpd/access_log
  tag server1.apache.access
</source>

<match *.apache.*>
  type sumologic
  host collectors.sumologic.com
  port 443
  format json
  path /receiver/v1/http/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX==
</match>



まずは、formatをjsonに設定した状態で、使用してみます。
# /etc/init.d/td-agent start


しばらくしてログが溜まっていくのがわかります。
ログの内容を見ると、messageがJSONになっているのが分かります。




これはこれで使い道がある場合もありますが、sumologicはJSONのパースに長い正規表現を使用しないと行けなそうなので、format textにしてみます。
<match *.apache.*>
  type sumologic
  host collectors.sumologic.com
  port 443
  format text
  path /receiver/v1/http/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX==
</match>



そのあとのログはクエリ欄に以下のように入力すると、カラムごとに項目がわかれて表示されます。
_collector=testhost | parse using public/apache/access





このようにすることで、集計も以下のようなクエリで簡単にレポートを作ることができます。
_collector=testhost | parse using public/apache/access | count by status_code






料金は、無料版は1日500MBまでで、データ保持期間は7日間、トータルで3.5GBまでのデータが保持可能です。有償の場合は1日5GBから1TB以上までの段階型のプランで、データ保持期間によっても価格が異なります。(⇛ 料金表 )

あくまで無料枠での体感ですが、同じサービス型のSplunkStormよりも動作は軽快なようです。
また、Splunkと同じくユーザーとロールを追加できるのでプロジェクト毎の設定などもできそうです。

以上です。

2013年4月27日土曜日

splunkってなんじゃ?(splunk stormでfluentd)

前回の記事でsplunk enterpriseを利用しましたが、今回はsplunk stormを使用してみます。
enterpriseはインストール型でしたが、stormはサービス型です。
stormでは無料枠ではデータストレージが1GBまでとなっています。

また今回はsplunkのfluentプラグインがあるので、ログをfluentでstormに投げてみたいと思います。

splunk stormに登録して、プロジェクトを作ります。




ストレージ容量を決めます。1GBまでは無料です。



データの入力を設定します。
ここではAPIを利用するように設定します。


APIのリンクをクリックすると、APIの認証とエンドポイントの情報が表示されます。
  • AccessToken
  • API Hostname
  • ProjectID




次に、fluentdの設定です。
splunkのAPIに対してログを送信するBufferedOutputプラグインを作成している方がいたので、それを使ってみます。

fluent-plugin-splunkapi
https://github.com/k24d/fluent-plugin-splunkapi

# /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-splunkapi


ソースやドキュメントを見ながらstorm用の設定を行います。
今回もapacheのログを送信します。

# vi /etc/td-agent/td-agent.conf
<source>
  type tail
  format apache
  path /var/log/httpd/access_log
  tag server1.apache.access
</source>

<match *.apache.*>
  type splunkapi
  access_token xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  project_id yyyyyyyyyyyyyyyyyyyyyyy
  protocol storm
  sourcetype fluent
  format text
  flush_interval 10s
  buffer_type memory
  buffer_queue_limit 16
</match>


access_tokenとproject_idには、上述のAPIの情報画面の情報を設定します。
fluentdを起動します。

# /etc/init.d/td-agent start


上の画像の「Explore data」をクリックすると、ログデータのサマリーが表示されます。
ソース欄に、fluentで設定したタグ名が表示されています。



このリンクをクリックすると、収集されたログデータの一覧が表示されます。




enterprise版と同様に、レポートを作成することもできますし、ダッシュボードに各種グラフを表示することもできます。





splunk stormでは、無料枠では1GB制限の他、1プロジェクトまでしか登録できないようです。

サービス型なので、サーバーメンテが必要ないのは良い点ですが、基本的にもっさりしています。
Plan選択画面で、2GB以上の有料枠に「Guaranteed response time for reported issues」とあるので
有料だとパフォーマンスが改善するのかもしれません。

自社でインフラを持ちたくなく、カスタマイズもそこまで必要ないという場合は、このようなサービス型のプロダクトは有効だと思います。

以上です。







2013年4月26日金曜日

StorageGatewayってなんじゃ?(バッファやキャッシュの容量を追加)

AWSのStorageGatewayを利用していて、パフォーマンスの見積もりが実際と合わず、最初に設定したバッファストレージやキャッシュストレージの容量が少なかったというケースがあるかもしれません。

公式ドキュメントでは、

Adding and Removing Upload Buffer Capacity (Gateway-Cached)

You can add more buffer capacity to your gateway without interrupting existing gateway functions. Note that when you add more upload buffer capacity, you do so with the gateway VM powered on; however, when you reduce the amount of upload buffer capacity, you must first power off the VM.

既存のゲートウェイ機能を中断せずにバッファ容量を追加することができます。
アップロードバッファ容量を追加する時は、ゲートウェイVMが起動中に行えますが
容量を減らす場合はまずVMをシャットダウンしておく必要があります。

As your application needs change and you add more storage volume capacity, you will might need to increase the gateway's upload buffer capacity. You can add more buffer capacity using the AWS Storage Gateway API (see AddUploadBuffer) or the AWS Storage Gateway console. 

アプリケーションのニーズが変化に応じてストレージ容量を追加すると、アップロードバッファ容量も増やす必要が出てきます。APIかAWSコンソールからバッファ容量を増やすことができます。




Adding Cache Storage (Gateway-Cached)


You can add more cache storage to your gateway without interrupting existing gateway functions and with the gateway VM powered on

既存のゲートウェイ機能を中断せずに起動したままキャッシュ容量を追加することができます。

You can add more cache storage using the AWS Storage Gateway API (see AddCache) or the AWS Storage Gateway console.

APIかAWSコンソールからバッファ容量を増やすことができます

Removing a disk allocated as cache storage is currently not supported.

キャッシュストレージの取り外しは現時点ではサポートされていません。


ということで、稼働中にバッファやキャッシュを追加することができます。
また現時点では、WEBシステムなどで利用していて後々アクセスが下がってきた場合キャッシュボリュームは減らせないので、料金的にリスクがありそうです。
長期的に考え、増やすときは必要な分だけ、というのがよさそうです。


では試してみます。




キャッシュ、バッファの追加




今回はゲートウェイインスタンス(EC2)の場合でやってみます。
以下の様な既存のゲートウェイインスタンスがあるとします。







「Gateway」タブの「Configure Local Storage」をみると、アップロードバッファに10GBのボリュームが適用されているのがわかります。また、キャッシュボリュームは20GBです。






ここで、ゲートウェイインスタンスにさらにアップロードバッファ用に10GB、キャッシュ用に20GBのボリュームを用意しアタッチします。





StorageGatewayの画面で、ふたたび「Gateway」タブの「Configure Local Storage」をクリックします。





すると、新しいディスクが認識され、バッファ用かキャッシュ用かを選択できるようになっています。
ここでは既存と同様、バッファ10GB、キャッシュ20GBとします。
「Save」ボタンを押すと、すぐに適用され、以下の画面でもバッファが20GBになってことがわかります。








バッファの削除



それではバッファを削除します。
削除する場合はシャットダウンが必要です。
「Gateway」タブの「Shut Down」をクリックして、コンソールをリロードして以下の画面になるまで待ちます。





上のような画面になったら、先ほど追加したバッファ用の10GBをデタッチします。





ディスクステータスが「Available」になったら、StorageGateway画面に戻り、先ほどの「Restart」ボタンをクリックします。
しばらくして、Gatewayが「Available」になったら「Gateway」タブの「Configure Local Storage」でストレージをみてみると、、、、





このように無事バッファボリュームを減らすことが出来ました。


また、これと同じようにキャッシュボリュームを減らそうとすると、Gatewayが「IRRECOVERABLE」という恐いステータスになってしまい、ボリュームが壊れてしまうようなので、停止中でもキャッシュボリュームはデタッチしてはいけません。サポートされるのをおとなしく待ちましょう。



以上です。





2013年4月18日木曜日

Kibanaってなんじゃ?(Kibana+elasticsearch+fluentdでログ解析)

前回の記事では splunk enterpriseを使ってみました。

今回もログ解析プラットホームである、Kibanaを使ってみます。
Kibanaは検索などにElasticsearchを利用します。
またKibanaはデータの収集にLogstashの利用を推奨しています。

それぞれ以下のようなプロダクトです。

Logstash
ログデータを収集し、解析して保存します。
この組み合わせで使用する場合、保存先はelasticsearchになります。

Elasticsearch
リアルタイムデータの全文検索や統計などをRestfulインターフェースで提供します。

Kibana
データの情報を描画し、検索したりドリルダウンで情報をたどれるGUIアプリケーションです。



この3つを組み合わせて使用すると便利なログ解析プラットホームが作れますよというのがKibanaの売りです。
データの収集や解析を行うLogstashは、入力、フィルタ、出力のプラグインを組み合わせて使うようになっているようです。こう見るとfluentdを思い出さずにはいられません。

そこでElasticsearchにfluentdでOUT出来ればLogstashの替わりにfluentdを使うことができ、より便利そうです。

探してみると、、、、
やっぱり、elasticsearchプラグインを作っている方がいました。
https://github.com/uken/fluent-plugin-elasticsearch


つまり、


fluentd + fluent-plugin-elasticsearch
ログデータを収集し、解析して保存します。
この組み合わせで使用する場合、保存先はelasticsearchになります。



ということで、完全にLogstashを置き換えられそうです。

そういうわけで早速インストールしてみました。

# cd ~/
# mkdir app
# cd app/
# curl -OL https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.20.6.tar.gz
# tar xzvf elasticsearch-0.20.6.tar.gz
# cd elasticsearch-0.20.6
# ./bin/elasticsearch -f

フロントで起動されました。今回はこのまま使います。

別のターミナルで同じマシンにログインします。

# cd ~/app
# yum -y install gcc ruby ruby-devel rubygems rdoc
# git clone --branch=kibana-ruby https://github.com/rashidkpc/Kibana.git
# cd Kibana/
# gem install bundler
# gem install eventmachine -v '1.0.3'
# bundle install

設定ファイルを以下のように編集します。
# vim ./KibanaConfig.rb
~略~

  Elasticsearch = "localhost:9200"

  #Set the Net::HTTP read/open timeouts for the connection to the ES backend
  ElasticsearchTimeout = 500

  # The port Kibana should listen on
  KibanaPort = 5601

  # The adress ip Kibana should listen on. Comment out or set to
  # 0.0.0.0 to listen on all interfaces.
  #KibanaHost = '127.0.0.1'
  KibanaHost = '0.0.0.0'

~略~


それでは起動してみます。
# ruby kibana.rb


これでKibanaとElasticsearchが起ち上がりました。

Kibanaはデフォルト5601ポートで起動するので、
http://xxx.xxx.xxx.xxx:5601/
にブラウザでアクセスします。



なにもデータがないため殺風景です。
データを用意しましょう。

データは別のサーバーからfluentdで送信します。

apacheを稼動しているサーバーで、fluentdを起動し、プラグインをインストールします。

# vim /etc/yum.repos.d/td.repo
[treasuredata]
name=TreasureData
baseurl=http://packages.treasure-data.com/redhat/$basearch
gpgcheck=0
# yum install td-agent -y


次に、プラグインをインストールします。
/usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-elasticsearch


そして、設定ファイルを作ります。 今回は、apacheのaccess_logをtailしてelasticsearchに送信します。
# vim /etc/td-agent/td-agent.conf
<source>
  type tail
  format apache
  path /var/log/httpd/access_log
  tag server1.apache.access
</source>

<match *.apache.*>
  index_name adminpack
  type_name apache
  type elasticsearch
  include_tag_key true
  tag_key @log_name
  host 54.248.82.123
  port 9200
  logstash_format true
  flush_interval 10s
</match>

ここで、ポイントは、sourceのtagにサーバー名.apache.accessとしたことです。
matchディレクティブでtag_key @log_nameとすると、Kibanaに送られた後にこの名前で絞込みができ、別サーバーや別のタイプのログなどと区別できます。

それではfluentdを起動します。
# /etc/init.d/td-agent start


これで準備は整ったので、このサーバーのコンテンツにアクセスしてアクセスログを発生させます。
その後、Kibanaの画面を再度確認すると、、


ログのデータが表示されています。
左側のペインで一覧にカラム表示する項目を+押下して選択します。

ヘッダ中央のキーワード入力欄に
code:404などとすると404レスポンスを返したログだけを絞り込めます。

また、@log_nameという項目が、先ほどのtagになるので、キーワード入力欄に
 @log_name:"server1.apache.access"
と入力すると、サーバーやログの種類で絞りこまれます。




現在Kibanaは複数ログに対応する機能がないようなので、このようにしてログ毎の集計をとる形になりそうです。


やはりsplunkと比べると機能面では物足りませんが、用途によってはこれで十分な場合もありますので、選択肢の一つとして覚えておきたいです。

以上です。

2013年4月17日水曜日

splunkってなんじゃ?(splunk enterpriseを使ってみる)

ちまたでsplunkがちょっとキテるようなので、ためしにインストールしてみました。

splunkは日時のあるデータは全てログだとして、ログのデータを収集、集計、検索、レポートできるダッシュボード付きのログ解析プラットフォームです。
また、splunk streamというサービス型とsplunk enterpriseというインストール型の2つの製品にわかれているようです。
enterprise型は60日間無料試用でき、1日最大500MBのデータのインデックス化が可能だそうで、それ以上は有償版が必要だそうです。

今回はenterprise型を試用してみます。



インストール



splunkのサイトでサインアップし、ダウンロードページを開きます。

インストールしたいプラットホームのファイルリンクをクリックして次に進みます。
今回はLinux32bitのtgzファイルを選択します。





右カラムに「Get  this URL.」リンクをクリックして表示されるフロートにあるコマンドをコピーします。




Linuxの適当な場所で、このコマンドをペーストして実行します。

# wget -O splunk-5.0.2-149561-Linux-i686.tgz 'http://ja.splunk.com/page/download_track?file=5.0.2/splunk/linux/splunk-5.0.2-149561-Linux-i686.tgz&ac=&wget=true&name=wget&typed=releases&elq=621f839c-c06b-404d-a422-118feac791fd'


解凍して実行します。
# tar xzvf splunk-5.0.2-149561-Linux-i686.tgz
# cd splunk
# ./bin/splunk start
SPLUNK SOFTWARE LICENSE AGREEMENT

THIS SPLUNK SOFTWARE LICENSE AGREEMENT ("AGREEMENT") GOVERNS THE
INSTALLATION AND USE OF THE SPLUNK SOFTWARE DESCRIBED HEREIN. THE
INSTALLATION AND USE OF THE SPLUNK SOFTWARE WILL BE SUBJECT TO THE
ORDER DOCUMENT(S).

YOU WILL BE REQUIRED TO INDICATE YOUR AGREEMENT TO THESE TERMS AND
CONDITIONS IN ORDER TO DOWNLOAD THE SOFTWARE, REGISTER THE SOFTWARE
WITH SPLUNK AND OBTAIN LICENSE KEYS NECESSARY TO COMPLETE THE
INSTALLATION PROCESS FOR THE SOFTWARE. BY CLICKING ON THE "YES" BUTTON
OR OTHER BUTTON OR MECHANISM DESIGNED TO ACKNOWLEDGE AGREEMENT TO THE
TERMS OF AN ELECTRONIC COPY OF THIS AGREEMENT, OR DOWNLOADING OR
INSTALLING THE SOFTWARE, OR USING ANY MEDIA THAT CONTAINS THE
SOFTWARE, YOU ARE CONSENTING TO BE BOUND BY THIS AGREEMENT, INCLUDING
ALL TERMS INCORPORATED BY REFERENCE. THIS AGREEMENT IS ENFORCEABLE
AGAINST ANY PERSON OR ENTITY THAT USES THE SOFTWARE AND ANY PERSON OR
ENTITY THAT USES THE SOFTWARE ON ANOTHER PERSON'S OR ENTITY'S BEHALF.
YOU AGREE THAT THIS AGREEMENT IS EQUIVALENT TO ANY WRITTEN NEGOTIATED
AGREEMENT SIGNED BY YOU.

IF YOU AGREE TO THESE TERMS ON BEHALF OF A BUSINESS OR A GOVERNMENT
AGENCY, DEPARTMENT OR INSTRUMENTALITY, YOU REPRESENT AND WARRANT THAT
YOU HAVE AUTHORITY TO BIND THAT BUSINESS TO THIS AGREEMENT, AND YOUR
AGREEMENT TO THESE TERMS WILL BE TREATED AS THE AGREEMENT OF THE
BUSINESS. IN THAT EVENT, "YOU" AND "YOUR" REFER HEREIN TO THAT BUSINESS.

THIS SOFTWARE IS BEING LICENSED AND NOT SOLD TO YOU. SPLUNK PERMITS YOU
TO DOWNLOAD, INSTALL AND USE THE FUNCTIONALITY OR FEATURES OF THE
SOFTWARE ONLY IN ACCORDANCE WITH THE TERMS OF THIS AGREEMENT.

1. DEFINITIONS. Capitalized terms not otherwise defined herein can be
found in Exhibit A.

2. TERM. This Agreement will be in effect perpetually unless earlier
terminated as provided herein (the "Term").

3. LICENSE GRANTS. Subject to your compliance with the terms and
conditions of this Agreement, including (as applicable) your timely
payment of license fees set forth in the applicable Order Document (the
"License Fees"), Splunk grants to you the following nonexclusive,
worldwide, nontransferable, nonsublicensable, revocable, limited
licenses during the Term (or such other period of time provided in your
Order Document) to use:

3.1 the Purchased Software solely for your Internal Business Purpose
and to index no more than the peak daily volume of uncompressed data
Do you agree with this license? [y/n]: y

This appears to be your first time running this version of Splunk.

Copying '/opt/cloudpack/app/splunk/etc/openldap/ldap.conf.default' to '/opt/cloudpack/app/splunk/etc/openldap/ldap.conf'.
Generating RSA private key, 1024 bit long modulus
...................................++++++
...................................................++++++
e is 65537 (0x10001)
writing RSA key

Generating RSA private key, 1024 bit long modulus
...++++++
...............++++++
e is 65537 (0x10001)
writing RSA key
Moving '/opt/cloudpack/app/splunk/share/splunk/sarch_mrsparkle/modules.new' to '/opt/cloudpack/app/splunk/share/splunk/search_mrsparkle/modules'.

Splunk> Be an IT superhero. Go home early.

Checking prerequisites...
 Checking http port [8000]: open
 Checking mgmt port [8089]: open
 Checking configuration...  Done.
 Checking indexes...
  Creating: /opt/cloudpack/app/splunk/var/lib/splunk
  Creating: /opt/cloudpack/app/splunk/var/run/splunk
  Creating: /opt/cloudpack/app/splunk/var/run/splunk/appserver/i18n
  Creating: /opt/cloudpack/app/splunk/var/run/splunk/appserver/modules/static/css
  Creating: /opt/cloudpack/app/splunk/var/run/splunk/upload
  Creating: /opt/cloudpack/app/splunk/var/spool/splunk
  Creating: /opt/cloudpack/app/splunk/var/spool/dirmoncache
  Creating: /opt/cloudpack/app/splunk/var/lib/splunk/authDb
  Creating: /opt/cloudpack/app/splunk/var/lib/splunk/hashDb
 Validated databases: _audit _blocksignature _internal _thefishbucket history main summary
 Done
New certs have been generated in '/opt/cloudpack/app/splunk/etc/auth'.
 Checking filesystem compatibility...  Done
 Checking conf files for typos...   Done
All preliminary checks passed.

Starting splunk server daemon (splunkd)...  Done
                                                           [  OK  ]
Starting splunkweb...  Generating certs for splunkweb server
Generating a 1024 bit RSA private key
..++++++
.++++++
writing new private key to 'privKeySecure.pem'
-----
Signature ok
subject=/CN=ip-10-132-86-233/O=SplunkUser
Getting CA Private Key
writing RSA key
                                                           [  OK  ]
Done

If you get stuck, we're here to help.
Look for answers here: http://docs.splunk.com

The Splunk web interface is at http://ip-10-132-86-233:8000


これでスタートできました。
このサーバーはデフォルトで8000番のポートで動いているようです。

それではブラウザで確認してみます。
http://xxx.xxx.xxx.xxx:8000/





データの入力



ログイン画面が現れたので、デフォルトのID/Passwordを入力してサインインします。
次の画面で本パスワードに変更すると、ホーム画面が現れます。
ここで、扱いたいログデータの追加をしてみます。

「データの追加」のリンクをクリックします。




データ追加画面が表示されます、ここではsyslogをセットしてみます。
syslogのリンクを選択します。




リモートのsyslogを取得することでもできますが、今回はこのサーバーのsyslogを取得します。




ログの場所として/var/log/messagesを設定して、次に進みます。




ソースタイプはそのまま続行します。




プレビューがちゃんと表示されてますね。




そのまま続行して完了です。
同じようにapacheのaccess_logをセットしておきます。




検索



ダッシュボードにいくと、2つのログが登録されているのが分かります。




ここで、ソースの/etc/httpd/logs/access_logのリンクをクリックしてみると、そのログの全検索結果が表示されます。「サーチ」入力欄をみるとわかるように、これは「サーチ」入力欄に
source="/etc/httpd/logs/access_log"
と入力したのと同じ結果になります。




また、更に絞り込むために、
source="/etc/httpd/logs/access_log" useragent="*Chrome*"
などと入れると、UserAgentがChromeを含んだもののみが表示されたりします。




レポート


これらの検索などを組み合わせたりした集計をレポートという形式で保存することもできます。
画面右上の「作成」から「レポート...」をクリックします。




するとレポート作成するための画面が表示され、サーチクエリかフォーム選択で作成するレポートの条件を決めることができます。
ここでは、ステータスコード別のレスポンス数の推移統計をとってみます。

【サーチクエリで指定する場合は】

source="/etc/httpd/logs/access_log" | timechart count by status


【フォームで指定する場合は】

レポートデータ
  • レポートタイプ:値の推移
  • レポートが表示されます:他のフィールドで分割された単一フィールド

フィールド
  • 表示:数(カウント)
  • /:イベント
  • 分割基準:status(n)

と設定します。


次にグラフの種類などを指定します。
種類を「面」で、スタックを「スタック」にして決定します。




決定して、名前を決めて保存します。
レポートページから保存したレポート名を選択すると以下のように、レポートをいつでも見ることができます。
httpステータスコード別のリクエスト数の推移がスタックグラフで確認できます。


クエリなどはドキュメントが必要ですが、ほとんどの操作を直感的にできてしまいました。

このように、ログとして扱うことの出来るデータならなんでも取り込んですぐに時系列データとして組み合わせたりフィルタリングしてグラフなどにしたり、特定条件の検索などもできるので運用やカスタマーサービス、マーケティングの強い味方になりそうです。

以上です。

EMRってなんじゃ?(別アカウントのS3に入出力)

EMRをつかって、別のアカウントのS3バケットにアクセスしたい時があります。

ここでは例として、アカウントAのEMRからアカウントBのS3のログを集計して、アカウントBのS3バケットへ出力してみます。

まず、アカウントBのS3バケットのACLを設定します。
方法は以前の記事と同じようにSDKで設定します。
S3ってなんじゃ?(S3のログファイルを別アカウントでダウンロード


$src = 'memorycraft-log';//入力ログバケット
$target = 'memorycraft-archive';//出力先バケット
$owner_canonical_id = 'オーナー(アカウントB)の標準ユーザーID';
$other_canonical_id = '別アカウント(アカウントA)の標準ユーザーID';
$s3 = new AmazonS3(array('key'=>'オーナーのアクセスキー','secret'=>'オーナーのシークレットキー');
$s3->set_region(AmazonS3::REGION_APAC_NE1);

$res = $s3->set_bucket_acl($src, array(
  array('id' => AmazonS3::USERS_LOGGING,     'permission' => AmazonS3::GRANT_READ_ACP),
  array('id' => AmazonS3::USERS_LOGGING,     'permission' => AmazonS3::GRANT_WRITE),
  array('id' => $other_canonical_id,         'permission' => AmazonS3::GRANT_FULL_CONTROL),
  array('id' => $owner_canonical_id,         'permission' => AmazonS3::GRANT_FULL_CONTROL),
));

$res = $s3->set_bucket_acl($target, array(
  array('id' => $other_canonical_id,         'permission' => AmazonS3::GRANT_FULL_CONTROL),
  array('id' => $owner_canonical_id,         'permission' => AmazonS3::GRANT_FULL_CONTROL),
));



このままの状態でEMR(Hive)で出力すると出力されたファイルは以下のようになります。





パーミッションがありません。
これは出力するファイル自体のパーミッションの設定がおかしいためです。
これに権限を追加するにはHiveの場合は、HiveScriptの先頭に以下のコマンドを追加します。

set fs.s3.canned.acl=BucketOwnerFullControl;

再度実行すると、出力されたファイルにも権限が与えられているのがわかります。





この説明に関しては、最近日本語化されたEMRの公式ドキュメントにPigやカスタムJARの場合の対応法とともに詳しく記載されています。
http://docs.aws.amazon.com/ja_jp/ElasticMapReduce/latest/DeveloperGuide/emr-s3-acls.html

これで、アカウントをまたいだリソース集計が可能になります。
以上です。