监控和维护AEM实例 monitoring-and-maintaining-your-aem-instance

部署AEM实例后，将需要某些任务来监控和维护其操作、性能和完整性。

这里的一个关键因素是，要识别潜在问题，您需要知道系统在正常情况下的外观和行为。 最好通过监控系统并收集一段时间内的信息来实现这一点。

备份 backups

备份以下内容是最佳做法：

贵公司可能会有一个备份策略，您需要遵循该策略，有关备份内容和备份时间的其他考虑事项包括：

通常，完整备份是定期进行（如每日、每周或每月），增量备份介于之间（如每小时、每天或每周）。

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

安装后或对配置进行重大更改后，请备份软件安装。

为此，您需要 备份整个存储库 然后：

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

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

有关制作在线“热”备份的完整详细信息，请参阅 创建在线备份.

版本清除 version-purging

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

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

概述 overview

的 清除版本 工具在 工具 控制台 在 版本控制 或直接从以下网站访问：

https://<server>:<port>/etc/versioning/purge.html

开始路径 必须执行清除的绝对路径。 您可以通过单击存储库树导航器来选择开始路径。

递归 在清除数据时，您可以选择在一个节点上执行操作，或通过选择“递归”在整个层次上执行操作。 在最后一种情况下，给定路径定义层级的根节点。

要保留的最大版本 节点要保留的最大版本数。 当这些数字超过此值时，将清除最早的版本。

最大版本期限 节点版本的最大年龄。 当版本的年龄超过此值时，会清除该值。

干流 由于删除内容的版本是确定的，并且在不恢复备份的情况下无法恢复，因此清除版本工具提供了一种干式运行模式，允许您预览已清除的版本。 要启动清除流程的干式运行，请单击“干式运行”。

清除 在由“开始路径”定义的节点上启动版本清除。

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

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

分析控制台 analyzing-the-console

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

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

在下一个示例中：

使用审核记录和日志文件 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控制台还在 ../system/console/slinglog;例如 http://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事件还会生成审核记录，这些记录可从 配置状态 选项卡 — > 日志文件 选项卡：

监控复制代理 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 the request.log 注意反应缓慢。 分析更大的 request.log 我们建议 使用 rlog.jar 允许您对响应时间进行排序和筛选.

我们建议将“慢”页面与 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

为了最大限度地减少特殊情况（如垃圾收集等）的影响，建议使用诸如 apachebench (例如， ab 以帮助识别内存泄漏并有选择地分析响应时间。

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

$ ab -c 5 -k -n 1000 "http://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 1.6起，工具命令 jvisualvm 中。 安装JDK 1.6后，您可以：

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

信息收集 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 — 工具 — 查询：

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

每月的平均Live Copy数是多少？ what-is-the-average-number-of-live-copies-per-month

确定自安装后使用存储库查询所生成的Live Copy总数；通过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

下面列出了一些建议，说明在开始遇到某些性能问题时要检查哪些内容。 （不幸的）清单并不完全。

CPU为100% 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性能；这可能涉及监控因素，包括堆大小、算法等。

一些常见的选择包括：

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

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

或JConsole:

这将帮助您了解正在使用的内存量、GC算法的使用情况、运行时间以及这对应用程序性能有何影响。 如果没有这一点，调整就只是“随机摆弄旋钮”。