监控和维护 Adobe Experience Manager 实例 monitoring-and-maintaining-your-aem-instance

部署AEM实例后，必须监视和维护其操作、性能和完整性。

这里的一个关键因素是，要识别潜在问题，您必须了解系统在正常条件下的外观和行为。 最好通过监视系统和收集随时间变化的信息来实现此功能。

备份 backups

最佳做法是将备份用于：

贵公司可能遵循备份策略，关于备份的内容和时间的其他考虑事项包括：

通常，会定期（例如，每日、每周或每月）执行完全备份，并在中间进行增量备份（例如，每小时、每日或每周）。

备份软件安装 backing-up-your-software-installation

在安装或配置发生重大更改后，创建软件安装的备份。

要完成此任务， 备份整个存储库 然后：

备份存储库 backing-up-your-repository

此 备份和恢复 CRX文档的部分涵盖了与CRX存储库备份相关的所有问题。

有关进行在线“热”备份的完整详细信息，请参见 创建联机备份.

版本清除 version-purging

此 清除版本 工具用于清除存储库中节点或节点层次结构的版本。 其主要用途是通过删除节点的旧版本来帮助您减小存储库的大小。

本节介绍与AEM版本控制功能相关的维护操作。 此 清除版本 工具用于清除存储库中节点或节点层次结构的版本。 其主要目的是通过删除旧版本的节点来帮助您减小存储库的大小。

概述 overview

此 清除版本 工具作为每周维护任务提供。 在首次使用之前，必须先添加它，然后对其进行配置。 之后，它可以按请求运行，也可以每周运行。

清除网站的版本 purging-versions-of-a-web-site

要清除网站的版本，请按照以下步骤操作：

试运行 — 分析控制台 analyzing-the-console

经典UI提供了 练习 选项来源：

该流程会列出已处理的所有节点。 在此过程中，节点可以具有以下状态之一：

此外，控制台还提供了有关版本的有用信息：

在下一个示例中：

使用审核记录和日志文件 working-with-audit-records-and-log-files

可在多个位置找到与Adobe Experience Manager (AEM)相关的审核记录和日志文件。 下面提供了可以找到的内容以及可在何处找到内容的概述。

使用日志 working-with-logs

AEM WCM会记录详细的日志。 打开包装并启动“快速入门”后，您可以在以下位置找到日志：

日志文件轮换 log-file-rotation

日志文件旋转是指通过定期创建文件来限制文件增长的过程。 在AEM中，一个名为 error.log 会根据给定规则每天轮换一次：

查找日志文件 finding-the-log-files

各种日志文件保存在安装AEM的文件服务器上：

激活DEBUG日志级别 activating-the-debug-log-level

默认日志级别(Apache Sling日志记录配置)是信息，因此不会记录调试消息。

要为记录器激活调试日志级别，请设置属性 org.apache.sling.commons.log.level 以在存储库中进行调试。 例如，在 /libs/sling/config/org.apache.sling.commons.log.LogManager 配置 全局Apache Sling日志记录.

调试文件中的行通常以DEBUG开头，然后提供日志级别、安装程序操作和日志消息。 例如：

DEBUG 3 WebApp Panel: WebApp successfully deployed

日志级别如下所示：

创建自定义日志文件 create-a-custom-log-file

在某些情况下，您可能希望创建具有不同日志级别的自定义日志文件。 在存储库中，执行以下操作：

Felix控制台还在以下位置提供有关Sling日志支持的信息： ../system/console/slinglog；例如， https://localhost:4502/system/console/slinglog.

查找审核记录 finding-the-audit-records

审核记录用以提供何时何地作出之审核记录。 AEM WCM和OSGi事件会生成不同的审核记录。

页面创作时显示的AEM WCM审核记录 aem-wcm-audit-records-shown-when-page-authoring

AEM WCM审核存储库中的记录 aem-wcm-auditing-records-within-the-repository

在 /var/audit 文件夹内，根据资源保存审计记录。 您可以向下展开，直到看到单个记录及其包含的信息。

这些条目包含的信息与编辑页面时显示的信息相同。

Web控制台中的OSGi审核记录 osgi-audit-records-from-the-web-console

OSGi事件还会生成审核记录，这些记录可在以下位置查看： 配置状态 选项卡> 日志文件 AEM选项卡：

监视复制代理 monitoring-your-replication-agents

您可以监控 复制队列 检测队列何时关闭或阻塞 — 这反过来可能表明发布实例或外部系统有问题：

监视复制代理：

同样，您可以开发一个解决方案来检测所有复制代理(位于 /etc/replication/author 或 /etc/replication/publish)，然后检查代理的状态( enabled， disabled)和底层队列( active， idle， blocked)。

监控性能 monitoring-performance

性能优化 是一个在开发过程中接收焦点的交互式进程。 部署后，会在特定时间间隔或事件后对其进行审查。

收集优化信息时使用的方法也可用于持续监测。

下面列出了出现的常见性能问题，以及如何发现和处理这些问题的建议。

性能问题可能源于与您的网站无关的各种原因，包括连接速度暂时减慢、CPU负载等等。

它还可能影响您的所有访客或仅影响其中一部分访客。

在优化常规性能或解决特定问题之前，必须获取、排序和分析所有这些信息。

用于监控和分析性能的工具 tools-for-monitoring-and-analyzing-performance

下面简要概述了可用于监控和分析性能的一些工具。

其中有些工具取决于您的操作系统。

解释request.log interpreting-the-request-log

此文件注册有关向AEM发出的每个请求的基本信息。 由此可以得出有价值的结论。

此 request.log 提供了一个内置方式，用于了解请求需要多长时间。 对于开发目的，此函数可 tail -f 该 request.log 并留意缓慢的响应时间。 要分析更大的 request.log，Adobe建议 使用 rlog.jar 用于排序和筛选响应时间.

Adobe建议将“慢”页面与 request.log，然后单独对其进行调整以获得更好的性能。 包括每个组件的性能量度或使用性能分析工具，例如 [yourkit](https://www.yourkit.com/).

监测网站流量 monitoring-traffic-on-your-website

请求日志记录发出的每个请求，以及发出的响应：

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

通过合计特定时段（例如，各种24小时时段）内的所有GET条目，您可以声明网站上的平均流量。

使用request.log监控响应时间 monitoring-response-times-with-the-request-log

请求日志是性能分析的一个良好起点：

<cq-installation-dir>/crx-quickstart/logs/request.log

日志如下所示（为了简单起见，这些行被缩短）：

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

此日志的每个请求或响应都有一行：

使用小型脚本，您可以从日志文件中提取所需信息并汇编所需的统计信息。 根据这些统计数据，您可以看到哪些页面或页面类型速度较慢，以及整体性能是否令人满意。

使用request.log监控搜索响应时间 monitoring-search-response-times-with-the-request-log

搜索请求也将在日志文件中注册：

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

因此，如上所述，您可以使用脚本提取相关信息并构建统计信息。

但是，在确定响应时间后，请分析请求花费时间的原因，以及可以做些什么来改进响应。

监控并发用户的数量和影响 monitoring-the-number-and-impact-of-concurrent-users

再次 request.log 可用于监控并发性和系统对此的反应。

在出现负面影响之前，必须执行测试以确定系统可处理多少并发用户。 再次可使用脚本从日志文件中提取结果：

31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

使用rlog.jar查找持续时间较长的请求 using-rlog-jar-to-find-requests-with-long-duration-times

AEM包括以下内容中的各种辅助工具：
<cq-installation-dir>/crx-quickstart/opt/helpers

这些工具之一， rlog.jar，可用于快速排序 request.log 以便按持续时间（从最长到最短）显示请求。

以下命令显示了可能的参数：

$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

例如，您可以运行它以指定 request.log 文件，并显示持续时间最长的前10个请求：

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

连接个人 request.log 文件（如果必须对大数据示例执行此操作）。

Apache Bench apache-bench

为了最大程度地降低特殊情况（如垃圾收集）的影响，建议使用 apachebench (例如， ab 以获取更多文档)，以帮助识别内存泄漏并有选择地分析响应时间。

Apache Bench可通过以下方式使用：

$ ab -c 5 -k -n 1000 "https://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

上述数字取自访问Geometrixx公司页面的标准MAcBook Pro笔记本电脑（2010年年中），如默认AEM安装中所示。 页面很简单，但并未针对性能进行优化。

此 apachebench 还会以所有并发请求的平均值显示每个请求的时间；请参阅 Time per request: 54.595 [ms] （所有并发请求中的平均值）。 您可以更改并发参数的值 -c （一次执行的多个请求数）以查看任何效果。

请求计数器 request-counters

有关请求流量（特定时间段内的请求数）的信息可让您指示实例上的负载。 此信息可以提取自 request.log，但使用计数器会自动收集数据，让您看到：

要自动收集信息，您还可以安装RequestFilter以在每个请求上递增计数器。 多个计数器可用于不同的时间段。

收集的信息可用于表明：

HTML注释 html-comments

建议每个项目都包含 html comments 提高服务器性能。 可以找到许多很好的公共示例。 选择一个页面，打开要查看的页面源，然后滚动到页面底部。 可以查看以下代码：

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

使用JConsole监控性能 monitoring-performance-using-jconsole

工具命令 jconsole 可用于JDK。

使用 （J）VisualVM 监控性能 monitoring-performance-using-j-visualvm

对于 JDK 6-8，可以使用该工具命令 visualvm 。 安装JDK后，可以执行以下操作：

您可以使用此工具生成线程转储和内存头转储。 技术支持团队经常要求提供此信息。

信息收集 information-collection

尽可能多地了解您的安装情况可以帮助您跟踪可能导致性能更改的原因以及这些更改是否合理。 定期收集这些量度，以便轻松查看重大更改。

以下信息可能很有用：

有多少作者使用系统？ how-many-authors-are-working-with-the-system

要查看自安装以来使用系统的作者数量，请使用命令行：

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

要查看在给定日期工作的作者数量，请执行以下操作：

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

每天的平均页面激活数是多少？ what-is-the-average-number-of-page-activations-per-day

要查看自服务器安装以来的页面激活总数，请使用存储库查询；通过CRXDE — 工具 — 查询：

然后，计算自安装以来经过的天数来计算平均值。

您当前在此系统上维护多少个页面？ how-many-pages-do-you-currently-maintain-on-this-system

要查看服务器上当前页数，请使用存储库查询；通过CRXDE — 工具 — 查询：

如果您使用MSM，则每月平均转出次数是多少？ if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

要确定自安装以来的转出总数，请使用存储库查询；通过CRXDE — 工具 — 查询：

计算自安装以来经过的月数以计算平均值。

每月平均活动副本数是多少？ what-is-the-average-number-of-live-copies-per-month

要确定自安装以来生成的活动副本总数，请使用存储库查询；通过CRXDE — 工具 — 查询：

再次使用安装后经过的月数来计算平均值。

如果您使用AEM Assets，则您当前在Assets中维护多少项资源？ if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

要查看您当前维护的DAM资产数量，请使用存储库查询；通过CRXDE — 工具 — 查询：

资源的平均大小是多少？ what-is-the-average-size-of-the-assets

要确定文件夹的总 /var/dam 大小，请执行以下操作：

当前使用了多少个模板？ how-many-templates-are-currently-used

要查看当前服务器上模板的数量，请使用存储库查询；通过CRXDE — 工具 — 查询：

当前使用了多少个组件？ how-many-components-are-currently-used

要查看当前服务器上组件的数量，请使用存储库查询；通过CRXDE — 工具 — 查询：

在峰值时间，您在创作系统上每小时有多少请求？ how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

要确定在峰值时间创作系统上每小时的请求数，请执行以下操作：

在峰值时间，您每小时在发布系统上有多少请求？ how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

在发布实例上重复上述过程。

分析特定方案 analyzing-specific-scenarios

以下建议列表列出了检查哪些内容是否开始遇到某些性能问题。 这份名单并不完整（很遗憾）。

100%的CPU cpu-at

如果系统的CPU始终以100%的速度运行，请参阅以下内容：

内存不足 out-of-memory

虽然在开发和测试过程中应该检测到此类错误，但某些场景可能会漏过。

如果您的系统内存不足，可以通过多种方式发现此问题，包括性能下降和错误消息（包括下文）：

java.lang.OutOfMemoryError

在这些情况下，请检查：

磁盘I/O disk-i-o

如果系统磁盘空间不足，或发现磁盘颠簸，请参阅：

性能定期下降 regular-performance-degradation

如果您看到实例的性能在每次重新启动后（有时为一周或更晚）都出现恶化，则可以检查以下各项：

JVM调整 jvm-tuning

Java™虚拟机(JVM)在调试方面已得到改进(特别是自Java™ 7以来)。 因此，指定合理的固定JVM大小并使用默认值通常是合适的。

如果默认设置不合适，那么建立一种监测和评估气相色谱性能的方法非常重要。 请在尝试调整 JVM 之前执行此操作。 此过程可能涉及监视因素，包括堆大小、算法和其他方面。

一些常见选项包括：

生成的日志可由GC可视化器摄取，例如：

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

或JConsole：

您可以看到使用了多少内存，使用了哪些GC算法，运行它们需要多长时间，以及此过程对应用程序性能有何影响。 如果没有它，调整只是“随机地转动旋钮”。