AWS Application Load BalancerのログをWindows PCからお手軽に見える化

2019.07.30

この記事を書いたメンバー：

大友佑介

大友(@yomon8)です。
みなさん、ALB(Application Load Balancer）のログをどうやって分析していますでしょうか。
最近はAthenaで簡単にSQL分析できたり、S3 Select使えば何も準備しなくても目的のログエントリまで辿り着けたりします。
障害ではないけどサイトが重いなどは、個別のログエントリではなく、傾向を見てみたい場合があると思います。
そんな時、選択肢の一つとしてCloudWatchがあります。もちろんCloudWatchも有用なツールなのですが、ALBのログの中身までは追えません。
そこで、画像のようなログの中身を分析するダッシュボードツールを作ったのでご紹介します。

作業前提

この作業をするのに唯一の前提はDockerがPCに入っていることです。Dockerのインストール手順は以下の公式サイト以外にも、ググると沢山記事が出てきますし、基本はインストーラーがガイドしてくれるので、とても簡単です。

https://docs.docker.com/docker-for-windows/install/

ダッシュボード起動手順

ダッシュボード起動の手順を見ていきます。PowerShellが動くWindows PCでDockerが入っていれば、どこでも動くはずです。（それがDockerの良いところです）

ツールのダウンロード

Gitがインストールされている環境の場合はPowerShellのコンソールから適当なフォルダで以下を実行してください。

PS> git clone https://github.com/yomon8/alb-log-analyzer.gitPS> cd .\alb-log-analyzer\

もしGitがインストールされていない環境の場合は、以下のURLにアクセスして、
https://github.com/yomon8/alb-log-analyzer
ダウンロードリンクからZIPをダウンロードして展開してください。

AWS接続設定(必須)

メモ帳で以下の名前のファイルを作成します。

notepad .\conf\awsenv.sh

AWSのIAM情報は、S3はALBのログを読み込める権限があれば大丈夫です。

例えば以下のように東京リージョンで、ALBのログが吐き出されていたとします。

 s3://beex-alb-logs/logs/alb-prod/AWSLogs/...

その場合は以下のような設定になります。

AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY
AWS_SECRET_ACCESS_KEY=YOUR_SECRET_ACCESS_KEY
AWS_REGION=ap-northeast-1
S3_BUCKET=beex-alb-logs
S3_PREFIX=logs/alb-prod

その他の設定(オプション)

以下のファイルで他にもいくつか設定ができます。

 notepad .\conf\env.sh

DURATION_MINUTES は取得するログの期間です。デフォルトは直近60分を取得する設定です。マシンスペックやネットワーク帯域、ログの容量などの原因で時間かかるようなら減らしてください。

CONTAINERNAME=alb-bananaSOLRPORT=8983
DURATION_MINUTES=60
UPDATE_COUNT=5000

実行

設定が完了したら実行してみます。以下が実行した際のコンソールをコピペしたものですが、実際に打ったコマンドはbinディレクトリにある、start.ps1というスクリプトだけです。
Dockerのイメージがダウンロードされるのでネットワーク環境によっては少し時間かかるかもしれません。

PS> .\bin\start.ps1Unable to find image 'yomon8/alb-banana:v0.1.2' locally
v0.1.2: Pulling from yomon8/alb-banana
b56ae66c2937: Pull complete                                                                                             81cebc5bcaf8: Pull complete                                                                                             3b27fd892ecb: Pull complete          
 
--省略--
                                                                                   710e1757f57e: Pull complete                                                                                             
531c5960fcc8: Pull complete                                                                                             
f6011d71557a: Already exists                                                                                            61cac4314388: Already exists                                                                                            5c6df04f9c48: Already exists                                                                                            Digest: sha256:36eb8093bceae8d49e19290727fd6ff1a5931027d181e718cc4a3c4add2f6705
Status: Downloaded newer image for yomon8/alb-banana-cli:v0.1.2
2019/07/24 12:49:27 [info]Solr Update Success (4565 docs)

最後に以下のようなメッセージが出れば正常です。4565 docsはインポートしたログの件数です。

2019/07/24 12:49:27 [info]Solr Update Success (4565 docs)

確認してみる

この時点でローカルPCでサーバーが立ち上がっていますので、以下からアクセスするとダッシュボードにログが入っているが見えるはずです。

http://127.0.0.1:8983/banana/#/dashboard/solr/ALB?server=%2Fsolr%2F

後片付け

停止用のスクリプトも用意しているので、完了したらコンテナ停止します。

PS> .\bin\stop.ps1alb-banana

仕組み・構成など

ここまで、ソフトウェアに触れずに来ましたが、少しだけ書きます。

今動かした、ざっくりとした構成は以下になります。Golangで開発したツールを起動して、Solrにログ情報を投入、Bananaでダッシュボード表示しています。

GolangのALBログ情報の取得ツールは単独でも利用できるように作っています。
https://github.com/yomon8/aloget
本体となる、Solr＆Bananaの部分。これと同じことする場合のパターンでは、Solr＆Bananaではなく、Elasticsearch&Kibanaの組み合わせが一般的だと思います。
まElasticsearchの代わりにApache Solrという検索エンジンを使っています、この２つの製品はApache Luceneという全文検索ソフトウェアを使っている共通点があります。実際に機能もかなり近いものになっています。
https://lucene.apache.org/solr/
Kibanaの代わりに使っているのは、Bananaというソフトウェアです。GitHubのリポジトリのREADME読んでわかる通り、Solr用にKibanaをポートしたものになっています。
https://github.com/lucidworks/banana
このように少しマイナーな構成で組んでいますが、Elasticsearch&Kibanaでも同じようなものが組めます。