request.log分析示例 | AEM
Adobe Experience Manager (AEM)的request.log包含响应时间在内的丰富信息源，这对于分析性能问题至关重要。 本文提供了几个例子来说明这一点。
描述 description
环境
Experience Manager 6.5
问题/症状
Adobe Experience Manager (AEM) request.log包含各种用于分析性能问题的有用信息，如响应时间。 以下是使用Linux命令的分析示例列表（包括一些外部命令，如ruby [ 1]和datamash [ 2] ）。
安装指南
[ 1] https://www.ruby-lang.org/en/documentation/installation/
[ 2] https://www.gnu.org/software/datamash/download/
解决方法 resolution
目录
A。简介
request.log的格式
B。准备步骤
- 数据清理
- 重新启动时间
- 每小时的访问次数
- 最大并发处理量
- 拆分日志文件
- 合并请求记录和响应记录
C。分析示例
- 最重的访问
- 访问缺少的响应
- 访问速度慢
- 响应时间的时间序列数据
- 最小值、平均值（平均）、中间值、最长响应时间
- 每个时段的访问次数
- 每时段的响应状态数
- 最常见的URL
request.log记录的access.log条记录
天结论
A。简介
request.log的格式：
默认情况下，AEM 6.5将生成以下格式的request.log。 由于系统限制，本文中的命令行显示为图像而非纯文本。
request.log示例：
在本文中，包含“ — >”的行称为“请求记录”。 带有“< — ”的行是“响应记录”。
请求记录：
当AEM收到请求时，将记录请求记录。 它包含接收日期和时间、请求 ID、请求方法和 URL。
响应记录：
当AEM响应请求时，将记录响应记录。 它包含响应的日期和时间、请求 ID、状态代码、内容类型和响应时间（以毫秒为单位）。
B。准备步骤
步骤 1. 数据清理
在深入分析request.log之前，请务必标准化日志记录。
第一个sed命令删除响应记录的Content-Type中多余的空格，以防止用空格分隔错误字段。 ruby命令（请参阅上面的 [ 1] 以安装Ruby）将日期格式转换为ISO 8601。 Ruby 命令还用空格而不是冒号分隔日期和时间。
步骤 2. 重启时间
重新启动AEM并安装Service Pack会重置request.log的请求ID。 请求ID = 0的请求记录指示可能存在这些类型的操作。
在上面的示例中，请求 ID 在 13:08:49 和 13:26:13 处重置为 0。
步骤 3. 每小时访问次数
计算request.log的每小时访问次数和时间范围。
步骤 4. 最大并发处理
并发处理的数量信息有助于猜测 AEM 的服务器负载。
默认情况下，AEM 中 Jetty 的最大并发连接数设置为 200。完成响应后释放套接字存在延迟。当并发处理的数量超过大约 170 时会无法接受新的请求。
步骤 5. 拆分日志文件
当AEM重新启动或安装Service Pack时，将重置request.log的请求ID。 由于此行为，当request.log包含此类操作时，分析可能不正确。 要执行准确分析并减小一次处理的文件大小，请使用请求ID = 0的请求记录拆分request.log。
步骤 6. 合并请求记录和响应记录
按请求 ID 合并请求和响应记录可以更轻松地在性能问题开始时即刻发现。 此合并的日志文件将在后面的示例中使用。
最后一个sed命令向没有相应响应记录的请求记录添加一个虚拟响应。 也可能有没有请求记录的响应记录。但可以忽略这些记录，因为它们通常不是需要调查的问题。
合并的日志文件应该如下所示：
C。分析示例
示例 1. 最大量的访问
将合并后的日志文件按响应时间降序排列，包括没有响应的访问。
示例 2. 缺少响应的访问
使用虚拟响应时间提取缺少相应响应记录的访问。
如果在没有响应的情况下接收访问的时间与服务器负载的增加相关，则这些访问可能触发了性能问题。
示例 3. 访问速度慢
提取耗时超过 10 秒的访问。
当点击次数过高时，请在grep命令中将[ 0-9] {5}替换为[ 0-9] {6}，以缩小访问范围，使其耗时100秒以上。
示例 4. 响应时间的时间序列数据
仅从数据中提取时间戳和响应时间对于创建图形很有帮助。
省略立即响应的访问可以使数据更具效率。以下示例提取的是耗时超过一秒的访问。
示例 5. 最小值、中间值（平均）、中位值、最大响应时间
上面的例子使用 datamash 命令 (https://www.gnu.org/software/datamash/) 进行统计处理。如果日志中包含无响应的访问，则虚拟值将会影响结果。
示例 6. 一段时间内的访问次数
统计每十分钟的访问次数。结果有助于确定流量大是否导致了性能问题。
以下示例将数据缩小到仅 POST 请求。一个典型的用例是确定内容创作或复制是否集中到了发布层。
示例 7. 一段时间内的响应状态次数
使用 datamash 命令创建每十分钟每个响应状态数的表格。
示例 8. 最常见的 URL
打印每十分钟访问最频繁的前三个 URL。
示例 9. access.log 记录一条 request.log 记录
在access.log中搜索与特定请求ID对应的记录。
如果同时对同一URL进行了多次访问，则结果将显示单个请求ID有多个access.log记录。
天结论
本文中的示例应该有助于您分析性能问题。
所列示例已经在 CentOS 7.5 和 Ubuntu 22.04LTS 上进行了测试，但它们可能无法按预期工作，具体情况取决于您的环境，例如命令的不同版本或变体。 请根据您环境中安装的命令相应地调整它们。