監視和維護您的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的檔案伺服器上會保留各種記錄檔：

啟用偵錯記錄層級 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 Console也提供Sling記錄支援的相關資訊，位於 ../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事件也會產生稽核記錄，可從 配置狀態 tab -> 記錄檔 標籤(在AEM Web控制台中):

監視複製代理 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個前1個請求：

$ 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 的URL區段。 安裝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 — 工具 — 查詢：

計算自安裝以來經過的月數以計算平均值。

每月的即時副本平均數量是多少？ 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算法、運行所花的時間，以及這對應用程式效能的影響。 如果沒有這個，調音只是「隨機擺弄旋鈕」。