Sumo Logicを使った爆速で行うELBログのビジュアライズと分析

ALBログをSumo Logicでビジュアライズしたり、分析してみました。 Sumo LogicはSaaSとして利用できるため、自分でEC2などを用意する必要がありません。また、ELBログのための事前定義されたビューやクエリが豊富にあるため、すぐにビジュアライズや集計が可能です。

モニタリングツール特集

#Sumo Logic

#Elastic Load Balancing (ELB)

#AWS

阿部洸樹

2018.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

個人的なことですがセキュリティ関連の実験のために、WordPressでサイトを運営しています。 ALBとEC2 1台の構成です。 ALBのログは取得しているものの特に分析や可視化は出来ていませんでした。今回は、ALBログをSumo Logicでビジュアライズしたり、分析してみました。

Sumo LogicはSaaSとして利用できるため、自分でEC2などを用意する必要がありません。また、ELBログのための事前定義されたビューやクエリが豊富にあるため、すぐにビジュアライズや集計が可能です。

Sumo Logicアカウント作成

Sumo Logicのページから、Sing Up Freeを選びます。メールアドレスを入力し、プランを選びます。

セットアップウィザード

Sign Upすると、セットアップウィザードが表示されます。 "Set Up Streaming Data"を選びます。

データタイプに AWS Elastic Load Balancingを選びます。

ELBログがPUTされるS3バケットの名前を入力します。 Path Expressionは*にしました。

IAMポリシーが表示されるので、画面の指示に従い、IAMユーザーを作成します。 IAMポリシーは以下のように参照権限を与えるものです。

{
  "Version": "2012-10-17",
  "Statement": [
  {
    "Action": [
    "s3:GetObject",
    "s3:GetObjectVersion",
    "s3:ListBucket",
    "s3:ListBucketVersions"
    ],
    "Effect": "Allow",
    "Resource": ["arn:aws:s3:::bucketname/*", "arn:aws:s3:::bucketname"]
  }
  ]
}

IAMユーザーを作成したら、アクセスキーを発行し入力します。

データの転送がはじまるので、しばらく待ちます。転送が完了したら、"Start Searching My Logs"を選択します。

ビジュアライズする

App Catalog ＞ AWS Elastic Load Balancer - Application ＞ Add to Libraryを選びます。

Source Categoryに"aws/elb"を選び、Add to Libraryを選択します。

AWS ELB - Application - Overviewのビューを選び、オープンします。リクエストが世界地図で表示されたり、OSをグラフで確認できます。

表示する時間の範囲は簡単に選択できます。

AWS ELB - Application - Overview

ビジュアライズで表示される内容を詳しく見ていきましょう。

Requests by Geolocation

リクエストのあった地域をみてみます。広東省からのアクセスが多いようです。地図は自由に拡大、移動できます。

Browsers and Operating Systems

アクセス元のOSやブラウザを確認できます。

その他

ELBごとのリクエスト、データ送受信量、HTTP Status Code 4xx/5xxのカウント数、平均のリクエスト処理時間/レスポンス時間、ターゲットグループごとのリクエスト処理時間などを確認できます。

レイテンシ分析

ここまでご紹介したのは「AWS ELB - Application - Overview」だけです。他にも、ディスパッチの失敗、レイテンシ分析、リクエスト、ステータスコードの観点でビジュアライズできます。

レイテンシ分析では、Webサイトが重くなっていないか確認できます。私のサイトではほとんど0秒に近いので、快適にサイトを閲覧できているようです。

仮にレイテンシが発生している場合は、クライアントIP、URLパス、ELB、バックエンドごとにプロセスタイムを確認できます。仮に特定のバックエンドのみレイテンシが発生している場合、インスタンスを入れ替える、インスタンスサイズをあげる、アクセスの偏りを確認するなどの対応が考えられます。

ステータスコード分析

ドメインとURLごとのステータスコードを確認してみました。 5xxはないため、Internal Error(HTTP 500)などは表示されていないようです。また、管理用のページにアクセスしようとして、4xxを返している様子がわかります。

クエリを書いて集計

クエリを書いて集計もできます。定義されたクエリがたくさんあるので、使ってみます。ステータスコード4xx,5xxのクエリを実行してみます。パーソナルフォルダを選択し、ELBフォルダ＞ELB Searches＞4XX and 5XX Status Codes by Backend Instance and ELBを選びます。

期間（過去7日間など）を選択し、Startするとクエリ結果が表示されます。

Messagesタブに切り替えると、ログを確認できます。表示、非表示するカラムは自由に選択できます。

手元で確認したい場合、CSV形式でダウンロード出来ます。

さいごに

日本語のコンテンツを掲載したサイトですが、広東省からのアクセスが多かったです。コンテンツはほとんど更新していないため、予想通り日本からのアクセスは少なかったです。小さいインスタンスサイズを使っていますが、レイテンシーは問題なさそうでした。

また、管理用のURLに対して、4xxのアクセスが多くあることがわかりました。場合によっては、AWS WAFで管理用のURLへのアクセス制限をかけたり、GeoIP制限をかけると良いと思います。こういった判断はそもそもログをモニタリング出来ていないと出来ません。ログをモニタリングし、適切なアクションを行なっていきましょう。