使用 AWS ELB 获取访问日志！
大家好！
我是来自 Beyond Co., Ltd. 大阪办公室的拉面王 Hide。
这是我的第二篇博文。
这次，我想和大家分享一下如何使用 ELB 获取访问日志。
上次我还写了一篇题为“用 Makefile 轻松使用 Docker 命令！”的文章，
如果您正在使用 Docker，欢迎阅读！
使用ELB获取访问日志有什么好处？
读到这篇文章的某些人
可能会想：“啊？我们可以获取服务器上的访问日志，所以没必要这样做
当然可以在服务器上获取访问日志，所以
使用 ELB 获取访问日志可能意义不大……
发帖人我也曾想过，“既然可以在服务器上完成，那用 ELB 获取访问日志就没什么意义了……”
但如果您想分析访问日志呢？
如果服务器分布在多台机器上，访问日志将存储在每台服务器上。
因此，即使您尝试分析访问日志，它们也存在于不同的服务器上，
这使得集成和分析它们变得相当耗时费力。
例如，您可以使用 CloudWatch Logs 来聚合日志。
在这种情况下，您需要使用 IAM 管理权限，在目标服务器上安装代理，并
编辑 awslogs.conf 中的设置……
使用名为 fluentd 的开源数据日志收集工具
轻松收集和利用日志
但是，这也需要在 IAM 中管理权限、安装和配置该工具，
并将 S3 指定为聚合目标，这可能相当繁琐……
要分析访问日志，您无需配置 CloudWatch Logs 或 fluentd；
只需在服务器前面的 ELB 上启用访问日志，
即可轻松聚合访问日志
由于所有访问日志都聚合在 S3 中，因此存储和分析变得非常容易。
此外，通过使用 AWS Athena 和 Redshift，
您可以使用标准 SQL 轻松分析 Amazon S3 中的数据！
此外，即使由于系统崩溃导致访问日志丢失，
您也可以轻松查看 ELB 访问日志，了解发生了什么。
此外，由于 ELB 是 AWS 提供的完全托管服务，您可以放心使用。
即使出现问题，AWS 也会负责修复。
“已启用但无法获取访问日志……”的情况。
您可以完全放心，几乎不可能遇到
现在您了解了启用ELB访问日志的好处！
那么，让我们一起来看看设置步骤吧！
设置程序
①前往 EC2⇛负载均衡器
② 从操作菜单中单击【编辑属性】。
③选择“启用访问日志”
④指定 S3 存储桶名称
⚠① S3 存储桶中只允许使用小写字母、数字、句点 (.) 和连字符 (-) 的组合。
请注意，输入除上述内容之外的任何字符都会导致错误，如下图所示。
⚠②如果您输入的 S3 存储桶名称已被使用，则会显示警告，并要求您输入其他名称。
⑤ 勾选【创建此位置】并点击保存。
⑥前往 S3 并点击[您创建的 S3 存储桶名称]
⑦ 确认访问日志文件存在于以下目录中后，该过程即完成。
*日志文件每5分钟生成一次。
/已创建 S3 存储桶名称/AWSLogs/弹性负载均衡账户 ID 号/弹性负载均衡/区域名称/创建年份/创建月份/创建日期/
如何查看访问日志
①前往 IAM 并点击【创建用户】
② 填写必要信息
*请务必在访问类型中勾选【程序化访问】。
③选择[AmazonS3ReadOnlyAccess]策略。
④ 检查是否有输入错误并创建用户
⑤下载CSV文件
*以防万一，请记下您的访问密钥和秘密访问密钥。
⑥安装 AWS CLI
* 有关安装 AWS CLI 的信息，AWS 官方文档请参阅
⚠本指南使用 CentOS 7。
如果您使用的是 Amazon Linux 2，则已安装，因此无需安装。
⑥-① 请确认已安装 Python 2.7 或更高版本。
*如果未安装 Python，请单独安装。
*在 CentOS 7 上，默认安装的是 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 配置 AWS 访问密钥 ID [无]：输入您创建的 IAM 的访问密钥 AWS 秘密访问密钥 [无]：输入您创建的 IAM 的秘密密钥 默认区域名称 [无]：输入区域 默认输出格式 [无]：输入您想要输出的文件格式
⑧ 输出访问日志
*使用 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 1月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/tokuhara-test-tg-ec2/ee1e50320f3398ec "Root=1-6008c68b-4198b51b343e8f127df30e01" "-" "-" 0 2021-01-21T00:10:51.821000Z "forward" "-" "-" "-" "-" "-" "-"
| 场地 | 解释 | 样本值 |
| 类型 | 请求或连接的类型 | http |
| 时间 | 负载均衡器收到客户端请求的时间（UTC）。 | 2021-01-21T00:10:51.821814Z |
| 肘部 | ELB 的名称 | app/tokuhara-test-alb/20a1e21abd53f9e7 |
| 客户端：端口 | 发送请求的客户端的 IP 地址和端口 | 63.143.XX.XX:45662 |
| 目标：端口 | 处理此请求的目标的 IP 地址和端口 | - |
| 请求处理时间 | 从 ELB 收到请求到将请求发送到目标所经过的总时间。 | -1 |
| 目标处理时间 | 从ELB向目标发送请求到目标开始发送响应头所经过的总时间 | -1 |
| 响应处理时间 | 从ELB收到目标服务器的响应头到开始向客户端发送响应所经过的总时间 | -1 |
| elb_status_code | 负载均衡器响应的状态码 | 503 |
| 目标状态码 | 目标响应的状态码 | - |
| 接收到的字节数 | 客户端收到的请求大小 | 110 |
| 发送字节 | 返回给客户端的响应大小 | 337 |
| “要求” | 客户端请求中，该行内容用双引号括起来。 | "GET http://example.com:80/ HTTP/1.1" |
| "user_agent" | 用于标识发出请求的客户端的用户代理字符串 | "Go-http-client/1.1" |
| ssl_cipher | SSL 加密套件，如果不是 HTTPS，则设置为 - | - |
| ssl_protocol | SSL 协议，如果不是 HTTPS，则设置为 - | - |
| 目标组_arn | 目标组的亚马逊资源名称 | arn:aws:elasticloadbalancing:ap-northeast-1:485076298277:targetgroup/tokuahra-test-tg-ec2/ee1e50320f3398ec |
| "trace_id" | X-Amzn-Trace-Id 标头的内容（用双引号括起来）。 | "Root=1-6008c68b-4198b51b343e8f127df30e01" |
| "域名" | 客户端在 TLS 握手期间提供的 SNI 域名（用双引号括起来）。如果不是 HTTPS，则设置为 -。 | "-" |
| "chosen_cert_arn" | 要提供给客户端的证书的 ARN（用双引号括起来），如果不是 HTTPS，则设置为 - | "-" |
| 匹配规则优先级 | 与请求匹配的规则的优先级值 | 0 |
| 请求创建时间 | ELB 收到客户端请求的时间 | 2021-01-21T00:10:51.821000Z |
| “actions_executed” | 处理请求时要执行的操作（用双引号括起来） | “向前” |
| "重定向网址" | HTTP 响应的 Location 标头中的重定向目标 URL（用双引号括起来） | "-" |
| "error_reason" | 错误原因代码（用双引号括起来） | "-" |
| "target:port_list" | 处理此请求的目标 IP 地址和端口列表（用双引号括起来），以空格分隔。 | "-" |
| "target_status_code_list" | 来自目标响应的状态码列表（用双引号括起来），以空格分隔。 | "-" |
| “分类” | 不同步缓解分类（用双引号括起来） | "-" |
| 分类原因 | 分类原因代码（用双引号括起来）。 | "-" |
费用
关于定价，将收取 ELB 费用。
根据 AWS 官方 ELB 文档，
AWS 东京区域应用程序负载均衡器的使用费用如下：
其次，由于访问日志在检索后会存储在 S3 中，因此会产生 S3 费用。
根据 AWS 官方关于 S3 的文档，
AWS 东京区域的 S3 定价如下：
这有点令人困惑，但对于前 50 TB 的数据，您每月将按每 GB 0.023 美元收费。
例如，如果一个月内累计了 10GB 的日志文件，第一个月的费用约为 24.28 日元；
第二个月累计了 20GB，费用约为 48.56 日元；
第三个月累计了 30GB，费用约为 72.54 日元。
此外，当月容量超过 450TB 时，每 GB 将额外收取 0.022 美元的费用。
通过这样的定价计算，可以看出，获取访问日志的成本非常低。
概括
感觉如何？
能否轻松汇总访问日志？
启用 ELB 访问日志功能可整合访问日志，节省时间和精力，并
确保稳定运行，几乎不会因故障导致日志获取失败！
即使服务器问题导致日志缺失，也可以轻松进行调查！
因此，请务必启用 ELB 访问日志
，以确保服务器安全便捷地运行！
最后，如果你读到这里并且对S3产生了兴趣，
请务必看看Beyond's Persian Cat写的文章！
感谢您阅读本文！
0
加载中...0 
这篇文章的作者
关于作者
