【大阪 / 横浜 / 徳島】インフラ / サーバーサイドエンジニア募集中！
【導入実績 500社以上】AWS 構築・運用保守・監視サービス
【CentOS 後継】AlmaLinux OS サーバー構築・移行サービス
【WordPress 専用】クラウドサーバー『ウェブスピード』
【格安】Webサイト セキュリティ自動診断「クイックスキャナー」
【予約システム開発】EDISONE カスタマイズ開発サービス
【100URLの登録が0円】Webサイト監視サービス『Appmill』
【200ヶ国以上に対応】グローバル eSIM「ビヨンドSIM」
【中国への旅行・出張・駐在なら】中国SIMサービス「チョコSIM」
【グローバル専用サービス】北米・中国でも、ビヨンドのMSP
【YouTube】ビヨンド公式チャンネル「びよまるチャンネル」
AWS ELBでアクセスログを取得しよう!
こんにちは！
株式会社ビヨンド大阪オフィスのラーメン王、ヒデです。
これが2回目の投稿です。
今回は、ELBでアクセスログを取得する方法について書こうと思います。
前回は、【Makefileで楽してdockerコマンドを使おう！】という記事も書いたので、
dockerをお使いの方は、ぜひ、見てくださいね
ELBでアクセスログを取得するメリットとは？
この記事を見ている方の中には.....「え？サーバー内でアクセスログが取れるから不要やろ！」と....
そのように思った方もいらっしゃるのではないでしょうか？
確かにサーバーでアクセスログを取得することは可能であり、
ELBでアクセスログを取得するメリットはあまりないかも知れません....。
投稿者である僕も「サーバーでいけるし、メリットなんてないやろ...」とそう思っていました。
しかし、アクセスログを分析したい場合はどうでしょうか？
サーバが複数台に分散されている場合は、アクセスログはそれぞれのサーバーに保存されることになります。
そのため、アクセスログを分析しようとしても、別々のサーバーにアクセスログが存在するので、
アクセスログの統合をして分析することは、なかなか手間と労力がかかってしまいます。
例えば、CloudWatchLogsを利用してログの集約をすることができます。
その場合は、IAMで権限管理をしたり、対象サーバーにエージェントをインストールしたり、
awslogs.confで設定を編集しないといけません....。
また、fluentdと言われるオープンソースのデータログ収集ツールを利用して、
手軽にログを収集し、活用することもできます。
しかし、これもIAMでの権限管理からツールのインストールと設定をしないといけません。
さらに集約先にS3を指定したりとなにかと手間がかかってしまいます.....。
アクセスログを分析するために、CloudWatchLogsやfluentdを使って設定しなくても
サーバーの前段にあるELBのアクセスログを有効化することで、
簡単にアクセスログの集約ができちゃいます！！
全アクセスログがS3にすべて集約される形になるので、保存+分析を容易にすることができます
さらにAWS AthenaやRedshiftを利用することで、
Amazon S3 内のデータを標準 SQL を使用して簡単に分析できます！
また、ハングアップによるアクセスログの欠損が起こっても、
簡単に何が起こったのかをELBのアクセスログを調べて確認することもできます。
そして、ELBはAWSのフルマネージドサービスであるため、安心してお使い頂くことができます。
たとえ、不具合が起きてもAWSが責任を持って修復してくれます。
なので！！「有効化したのにアクセスログが取れない.......」ということは、
ほぼありませんのでご安心ください
これでELBでアクセスログを有効化するメリットもわかったはずです！
それでは、いよいよ設定手順を一緒に見ていきましょう！
設定手順
①EC2⇛ロードバランサーに移動
②アクションから【属性の編集】をクリック
③アクセスログの有効化を選択する
④S3 の場所にバケット名を指定する
⚠①S3 バケットには、小文字、数字、ピリオド (.) 、およびダッシュ (-) の組み合わせのみを使用できます。
上記以外で入力すると以下の画像のようにエラーが起こるので注意してください
⚠②入力したS3バケット名がすでに使用中の場合は、警告が表示されるので他の名前を入力してください
⑤【この場所の作成】 に✔を入れて、保存をクリックする
⑥S3に移動して【作成したS3バケット名】をクリック
⑦以下ディレクトリにアクセスログファイルがあることを確認できたら完了
＊ログファイルは5分ごとに作成されます。
/作成したS3バケット名/AWSLogs/Elastic Load BalancingアカウントID番号/elasticloadbalancing/リージョン名/作成年後/作成月/作成日/
アクセスログ確認方法
①IAMに移動して【ユーザー作成】をクリック
② 必要事項を記入する
＊アクセスの種類で【プログラムによるアクセス】にチェックを必ず入れてください
③【AmazonS3ReadOnlyAccess】のポリシーを選択
④入力に誤りがないか確認してユーザーを作成
⑤csvをダウンロードする
＊念の為、アクセスキーとシークレットアクセスキーをメモしておく
⑥AWS CLIをインストール
＊AWS CLIのインストールに関しては、AWS公式ドキュメントを参照してください
⚠ここでは、Centos7を使用しております。
Amazon Linux2の場合は、すでにインストールされているため、インストールは不要です。
⑥-①Pythonがバージョン 2.7以降であることを確認する
＊Pythonがない場合は、別途インストールしてください。
＊Centos7では、2.7.5がデフォルトでインストールされています。
python --version Python 2.7.5
⑥-②バンドルされたインストーラをインストール
curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip" sudo yum install -y unzip unzip awscli-bundle.zip sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws aws --version
⑦AWS CLIの設定
aws configure AWS Access Key ID [None]: 作成したIAMのアクセスキーを入力 AWS Secret Access Key [None]:作成したIAMのシークレットキーを入力 Default region name [None]:リージョンを入力 Default output format [None]:出力したいファイル形式を入力
⑧アクセスログを出力する
＊AWS CLI S3コマンドでS3バケットのファイルを一覧表示 aws s3 ls s3://tokuhara-test-alb-access-log/AWSLogs/485076298277/elasticloadbalancing/ap-northeast-1/2021/01/18/ 2021-01-18 08:05:12 884 485076298277_elasticloadbalancing_ap-northeast-1_app.tokuhara-test-alb.20a1e21abd53f9e7_20210118T0805Z_54.65.29.6_53o3j7p0.log.gz ＊ローカルにコピーする aws s3 cp s3://tokuhara-test-alb-access-log/AWSLogs/485076298277/elasticloadbalancing/ap-northeast-1/2021/01/18/485076298277_elasticloadbalancing_ap-northeast-1_app.tokuhara-test-alb.20a1e21abd53f9e7_20210118T2355Z_52.68.106.116_5qgag1lu.log.gz ./ ＊ローカルにコピーをできているか確認する ls -l ./ -rw-r--r--. 1 root root 295 Jan 18 23:55 485076298277_elasticloadbalancing_ap-northeast-1_app.tokuhara-test-alb.20a1e21abd53f9e7_20210118T2355Z_52.68.106.116_5qgag1lu.log.gz ＊圧縮ファイルを解凍する gunzip 485076298277_elasticloadbalancing_ap-northeast-1_app.tokuhara-test-alb.20a1e21abd53f9e7_20210118T2355Z_52.68.106.116_5qgag1lu.log.gz *アクセスログを表示 less 485076298277_elasticloadbalancing_ap-northeast-1_app.tokuhara-test-alb.20a1e21abd53f9e7_20210118T2355Z_52.68.106.116_5qgag1lu.log http 2021-01-21T00:10:51.821814Z app/tokuhara-test-alb/20a1e21abd53f9e7 63.143.XX.XX:45662 - -1 -1 -1 503 - 110 337 "GET http://example.com:80/ HTTP/1.1" "Go-http-client/1.1" - - arn:aws:elasticloadbalancing:ap-northeast-1:485076298277:targetgroup/tokuahra-test-tg-ec2/ee1e50320f3398ec "Root=1-6008c68b-4198b51b343e8f127df30e01" "-" "-" 0 2021-01-21T00:10:51.821000Z "forward" "-" "-" "-" "-" "-" "-"
出力結果とフォーマット
ELBアクセスログの設定！！お疲れ様でした٩(ˊᗜˋ*)و
でも、アクセスログが出力されるように設定しても見方がわからないと原因調査もできません....。
なので！『AWS公式ドキュメント』を参考にしつつ、
ELBで取得したアクセスログのサンプルに対して、
各項目に対応する値と説明がわかりやすいようにまとめて以下のフォーマットを用意しました。
一度どんな項目があるのか見てみてくださいね！
http 2021-01-21T00:10:51.821814Z app/tokuhara-test-alb/20a1e21abd53f9e7 63.143.XX.XX:45662 - -1 -1 -1 503 - 110 337 "GET http://example.com:80/ HTTP/1.1" "Go-http-client/1.1" - - arn:aws:elasticloadbalancing:ap-northeast-1:485076298277:targetgroup/tokuahra-test-tg-ec2/ee1e50320f3398ec "Root=1-6008c68b-4198b51b343e8f127df30e01" "-" "-" 0 2021-01-21T00:10:51.821000Z "forward" "-" "-" "-" "-" "-" "-"
| フィールド | 説明 | サンプル値 |
| type | リクエストまたは接続のタイプ | http |
| time | ロードバランサーがクライアントからリクエストを受け取った時刻(UTC) | 2021-01-21T00:10:51.821814Z |
| elb | ELBの名前 | app/tokuhara-test-alb/20a1e21abd53f9e7 |
| client:port | リクエストを送信したクライアントの IP アドレスとポート | 63.143.XX.XX:45662 |
| target:port | このリクエストを処理したターゲットの IP アドレスとポート | - |
| request_processing_time | ELBがリクエストを受け取った時点からターゲットにリクエストを送信するまでの合計経過時間 | -1 |
| target_processing_time | ELBがターゲットにリクエストを送信した時点からターゲットが応答ヘッダーの送信を開始した時点までの合計経過時間 | -1 |
| response_processing_time | ELBがターゲットから応答ヘッダーを受け取った時点からクライアントへの応答の送信を開始した時点までの合計経過時間 | -1 |
| elb_status_code | ロードバランサーからの応答のステータスコード | 503 |
| target_status_code | ターゲットから応答のステータスコード | - |
| received_bytes | クライアントから受け取ったリクエストのサイズ | 110 |
| sent_bytes | クライアントに返される応答のサイズ | 337 |
| "request" | クライアントからのリクエストで行は二重引用符で囲まれている | "GET http://example.com:80/ HTTP/1.1" |
| "user_agent" | リクエスト元のクライアントを特定するUser-Agent 文字列 | "Go-http-client/1.1" |
| ssl_cipher | SSL暗号であり、HTTPSでない場合は - と設定されます | - |
| ssl_protocol | SSLプロトコルであり、HTTPSでない場合は - と設定されます | - |
| target_group_arn | ターゲットグループの Amazon リソースネーム | arn:aws:elasticloadbalancing:ap-northeast-1:485076298277:targetgroup/tokuahra-test-tg-ec2/ee1e50320f3398ec |
| "trace_id" | X-Amzn-Trace-Id ヘッダーのコンテンツ (二重引用符で囲まれます)。 | "Root=1-6008c68b-4198b51b343e8f127df30e01" |
| "domain_name" | TLS ハンドシェイク中にクライアントから提供される SNI ドメイン (二重引用符で囲まれます)HTTPSでない場合は - と設定されます | "-" |
| "chosen_cert_arn" | クライアントに提示される証明書の ARN (二重引用符で囲まれます)。HTTPSでない場合は - と設定されます | "-" |
| matched_rule_priority | リクエストに一致したルールの優先度の値 | 0 |
| request_creation_time | ELBがクライアントからリクエストを受け取った時刻 | 2021-01-21T00:10:51.821000Z |
| "actions_executed" | リクエストの処理時に実行されるアクション (二重引用符で囲まれます) | "forward" |
| "redirect_url" | HTTP レスポンスのロケーションヘッダーのリダイレクトターゲットの URL (二重引用文字で囲む) | "-" |
| "error_reason" | エラー理由コード (二重引用符で囲まれます) | "-" |
| "target:port_list" | このリクエストを処理したターゲットの IP アドレスとポートのスペース区切りのリスト (二重引用符で囲まれます) | "-" |
| "target_status_code_list" | ターゲットの応答からのステータスコードのスペース区切りのリスト (二重引用符で囲まれます) | "-" |
| "classification" | desync 緩和の分類 (二重引用符で囲まれます) | "-" |
| "classification_reason" | 分類理由コード (二重引用符で囲まれます)。 | "-" |
料金
料金についてですが、ELBの料金は発生致します。
ELBに関する『AWS公式ドキュメント』によれば、
AWS 東京リージョンのApplication Load Balancersの利用料金については、次の通りです。
次にアクセスログを取得した後はS3に保存しているため、S3の料金が発生致します。
S3に関する『AWS公式ドキュメント』では、
AWS 東京リージョンの場合、S3の料金設定は以下のようになっております。
非常にわかりにくいですが、最初の 50 TBまでは、月に1GB当たり0.023USDの料金が発生致します。
例えば、1ヵ月に蓄積されるログファイルが10GBであった場合は、初月に約24.28円が発生し、
2ヵ月目に20GBが蓄積されるため、約48.56円が、
3ヵ月目に30GBが蓄積されたため、約72.54円の料金が発生致します。
そして、容量が450TB超えた月から1GB当たり0.022USDの料金が発生致します。
このように料金の計算を見ると非常に安価にアクセスログが取得できることがわかるのではないでしょうか？
まとめ
いかがでしたでしょうか？
とても簡単にアクセスログを集約できたのではないでしょうか？
アクセスログを集約するために、ELBのアクセスログを有効化することで、時間と労力を削減でき、
不具合でログ取得ができないこともほぼないため、安定して利用できます！
何かサーバーに異常が合ってログの欠陥が起こっても簡単に調べられることもできます！！
なので！！ぜひ、ELBのアクセスログを有効化して、
安全に、便利にサーバーを運用できるようにしておきましょう
最後に、この記事を見ている方の中で「S3に興味が湧いてきた！！」という方は、
ビヨンドのペルシャ猫さんが以下の記事を書いてるので、合わせてチェックしてみてくださいね!!
記事を読んで頂き、ありがとうございました！
0
読み込み中...0 
【2025.6.30 Amazon Linux 2 サポート終了】Amazon Linux サーバー移行ソリューション
この記事をかいた人
About the author
