After your CQ instances have been deployed certain tasks will be needed to monitor and maintain their operation, performance and integrity.

A key factor here is that to recognize potential issues you need to know how your systems looks and behaves under normal conditions. This is best done by monitoring the system and collecting information over a period of time.

If you are operating a third-party application server, then additional folders may be in a different location and may also need to be backed up. See How to install AEM with an Application Server for information about installing application servers.

Uzmanību!

Incremental backup of the file data store is supported; when using incremental backup for other components (such as Lucene index), please ensure deleted files are also marked as deleted in the backup.

Piezīme.

Disk mirroring can also be used as a backup mechanism.

Backing up your repository

The Backup and Restore section of the CRX documentation covers all issues related to backups of the CRX repository.

Version Purging

The Purge Versions tool is intended for purging the versions of a node or a hierarchy of nodes in your repository. Its primary purpose is to help you reduce the size of your repository by removing old versions of your nodes.

This section deals with maintenance operations related to the versioning feature of CQ. The Purge Version tool is intended for purging the versions of a node or a hierarchy of nodes in your repository. Its primary purpose is to help you reduce the size of your repository by removing old versions of your nodes.

Overview

The Purge Versions tool is available in the Tools console under Versioning or directly at:

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

Start Path

An absolute path on which the purge must be done. You can select the Start Path by clicking the repository tree navigator.

Recursive

When purging data you can choose between performing the operation on one node or on a whole hierarchy by selecting Recursive. In the last case the given path defines the root node of the hierarchy.

Maximum versions to keep

The maximum number of versions to be kept for a node. When these number exceeds this value, the oldest versions are purged.

Maximum version age

The maximum age of the version of a node. When the age of a version exceeds this value, it is purged.

Dry Run

Because removing versions of your content is definite and can not be reverted without restoring a backup, the Purge Versions tool provides a dry run mode that allows you to preview the purged versions. To launch a dry run of the purge process, click Dry Run.

Purge

Launch the purge of the versions on the node defined by the Start Path.

Purging Versions of a Web Site

To purge versions of a web site, proceed as follows:

Navigate to the Toolsconsole, select Versioning and double-click Purge Versions.

Set the start path of the content to be purged (e.g. /content/geometrixx-outdoors).

If you want to only purge the node defined by your path, unselect Recursive.

If you want to purge the node defined by your path and its descendants select Recursive.

Set the maximum number of versions (for each node) that you want to keep. Leave empty to not use this setting.

Set the maximun version age in days (for each node) that you want to keep. Leave empty to not use this setting.

Click Dry Run to preview what the purge process would do.

Click Purge to launch the process.

Uzmanību!

Purged nodes can not be reverted without restoring the repository. You should take care of your configuration, so we recommend you to always perform a dry run before purging.

Analyzing the Console

The Dry Run and Purge processes list all the nodes that have been processed. During the process, a node can have one of the following status:

ignore (not versionnable): the node does not support versioning and is ignored during the process.

ignore (no version): the node does not have any version and is ignored during the process.

retained: the node is not purged.

purged: the node is purged.

Moreover the console provides useful information about the versions:

V 1.0: the version number.

V 1.0.1*: the star indicates that the version is the current one.

Thu Mar 15 2012 08:37:32 GMT+0100: the date of the version.

In the next example:

The Shirts versions are purged because their version age is greater than 2 days.

The Tonga Fashions! versions are purged because their number of versions is greater than 5.

Working with Audit Records and Log Files

Auditing records and log files relating to Adobe Experience Manager (AEM) can be found at various locations. The following is provided to give you an overview of what you can find where.

Working with Logs

AEM WCM records detailed logs. After you unpack and start Quickstart, you can find logs in:

<cq-installation-dir>/crx-quickstart/logs/

<cq-installation-dir>/crx-quickstart/repository/

Log file rotation

Log file rotation refers to the process that limits the growth of file by creating new file periodically. In AEM, a log file called error.log will be rotated once a day according to the given rules:

The error.log file is renamed according to the pattern {original_filename}.yyyy-MM-dd. For example on July 2010 11th, the current log file is renamed error.log-2010-07-10, then a new error.og is created.

Previous log files are not deleted, so it is your responsibility to clean old log files periodically to limit the disk usage.

Piezīme.

If you upgrade your AEM installation, note that any existing log file that is no more used by AEM will remain on the disk. You can remove them without risk. All new log entries will be written in the new log files.

Finding the Log Files

Various log files are held on the file server where you installed AEM:

<cq-installation-dir>/crx-quickstart/logs

access.log
All access requests to AEM WCM and the repository are registered here.

ImageServer-<PortId>-yyyy>-<mm>-<dd>.log
This log is only used if dynamic media is enabled. It provides statistics and analytical information used for analyzing behavior of the internal ImageServer process.

request.log
Each access request is registered here together with the response.

s7access-<yyyy>-<mm>-<dd>.log
This log is only used if dynamic media is enabled. The s7access log records each request made to Dynamic Media through /is/image and /is/content.

stderr.log
Holds error messages, again of varying levels of severity, generated during startup. By default the log level is set to Warning (WARN)

stdout.log
Holds logging messages indicating events during startup.

upgrade.log
Provides a log of all upgrade operations that runs from the com.day.compat.codeupgrade and com.adobe.cq.upgradesexecutor packages.

<cq-installation-dir>/crx-quickstart/repository

revision.log
Revision journaling information.

Piezīme.

The ImageServer and s7access logs are not included in the Download Full package that is generated from the system/console/status-Bundlelist page. For support purposes, if you have Dynamic Media issues, please also append the ImageServer and s7access logs when you contact Customer Support.

Activating the DEBUG Log Level

To activate the debug log level for a Logger, set the property org.apache.sling.commons.log.level to debug in the repository. For example, on /libs/sling/config/org.apache.sling.commons.log.LogManager to configure the global Apache Sling Logging.

Uzmanību!

Do not leave the log at the debug log level longer than necessary, as it generates a lot of log entries, thus consuming resources.

A line in the debug file usually starts with DEBUG, then provides the log level, the installer action and the log message. For example:

DEBUG 3 WebApp Panel: WebApp successfully deployed

The log levels are as follows:

0

Fatal error

The action has failed, and the installer cannot proceed.

1

Error

The action has failed. The installation proceeds, but a part of AEM WCM was not installed correctly and will not work.

2

Warning

The action has succeeded but encountered problems. AEM WCM may or may not work correctly.

3

Information

The action has succeeded.

Create a Custom Log File

Piezīme.

When working with Adobe Experience Manager there are several methods of managing the configuration settings for such services; see Configuring OSGi for more details and the recommended practices.

In certain circumstances you may want to create a custom log file with a different log level. You can do this in the repository by:

If not already existing, create a new configuration folder (sling:Folder) for your project /apps/<project-name>/config.

Name: org.apache.sling.commons.log.LogManager.factory.config-<identifier> (as this is a Logger)
Where <identifier> is replaced by free text that you (must) enter to identify the instance (you cannot omit this information). For example, org.apache.sling.commons.log.LogManager.factory.config-MINE

Type: sling:OsgiConfig

Piezīme.

Although not a technical requirement, it is advisable to make <identifier> unique.

Name: org.apache.sling.commons.log.LogManager.factory.writer-<identifier> (as this is a Writer)
As with the Logger, <identifier> is replaced by free text that you (must) enter to identify the instance (you cannot omit this information). For example, org.apache.sling.commons.log.LogManager.factory.writer-MINE

Type: sling:OsgiConfig

Piezīme.

Although not a technical requirement, it is advisable to make <identifier> unique.

Set the following properties on this node:

Name: org.apache.sling.commons.log.file
Type: String
Value: specify the Log File so that it matches the file specified in the Logger;
for this example, ../logs/myLogFile.log.

Configure the other parameters as required:

Name: org.apache.sling.commons.log.file.number
Type: Long
Value: specify the number of log files you want kept; for example, 5

org.apache.sling.commons.log.file.size controls the rotation of the log file by setting either:

a maximum file size

a time/date schedule

to indicate when a new file will be created (and the existing file renamed according to the name pattern).

A size limit can be specified with a number. If no size indicator is given, then this is taken as the number of bytes, or you can add one of the size indicators - KB, MB, or GB (case is ignored).

A time/date schedule can be specified as a java.util.SimpleDateFormat pattern. This defines the time period after which the file will be rotated; also the suffix appended to the rotated file (for identification).
The default is '.'yyyy-MM-dd (for daily log rotation).
So for example, at midnight of January 20th 2010 (or when the first log message after this occurs to be precise), ../logs/error.log will be renamed to ../logs/error.log.2010-01-20. Logging for the 21st of January will be output to (a new and empty) ../logs/error.log until it is rolled over at the next change of day.

'.'yyyy-MM

Rotation at the beginning of each month

'.'yyyy-ww

Rotation at the first day of each week (depends on the locale).

'.'yyyy-MM-dd

Rotation at midnight each day.

'.'yyyy-MM-dd-a

Rotation at midnight and midday of each day.

'.'yyyy-MM-dd-HH

Rotation at the top of every hour.

'.'yyyy-MM-dd-HH-mm

Rotation at the beginning of every minute.

Note: When specifying a time/date:
1. You should "escape" literal text within a pair of single quotes (' ');
this is to avoid certain characters being interpreted as pattern letters.
2. Only use characters allowed for a valid file name anywhere in the option.

Read your new log file with your chosen tool.

The log file created by this example will be ../crx-quickstart/logs/myLogFile.log.

The Felix Console also provides information about Sling Log Support at ../system/console/slinglog; for example http://localhost:4502/system/console/slinglog.

Finding the Audit Records

Audit records are held to provide a record of who did what and when. Different audit records are generated for both AEM WCM and OSGi events.

AEM WCM Audit records shown when Page Authoring

Open a page.

From the sidekick you can select the tab with the lock icon, then double-click on Audit Log...

A new window will open showing the list of audit records for the current page.

Click OK when you want to close the window.

AEM WCM Auditing records within the repository

Within the /var/audit folder, audit records are held according to the resource. You can drill down until you can see the individual records and the information they contain.

These entries hold the same information as shown when editing a page.

OSGi Audit records from the Web Console

OSGi events also generate audit records which can be seen from the Configuration Status tab -> Log Files tab in the Adobe CQ Web Console:

Monitoring Your Replication Agents

You can monitor your replication queues to detect when a queue is either down or blocked - which might in turn indicate a problem with a publishing instance or external system:

are all required queues enabled?

are any disabled queues still required?

all enabled queues should have the status idle or active, which indicate normal operation; no queues should be blocked, which is often a sign of problems on the receivers side.

if the size of the queue grows over time this can indicate a blocked queue.

To monitor a replication agent:

Access the Tools tab in AEM.

Click Replication.

Double-click the link to agents for the appropriate environment (either the left or the right pane); for example Agents on author.

The resulting window shows an overview of all your replication agents for the author environment, including their target and status.

Click the appropriate agent name (which is a link) to show detailed information on that agent:

Here you can:

See whether the agent is enabled.

See the target of any replications.

See whether the replication queue is currently active (enabled).

See whether there are any items in the queue.

Refresh or Clear to update the display of queue entries; this helps you see items enter and leave the queue.

View Log to access the log of any actions by the replication agent.

Test Connection to the target instance.

Force Retry on any queue items if required.

Uzmanību!

Do not use the "Test Connection" link for the Reverse Replication Outbox on a publish instance.

If
a replication test is performed for an Outbox queue, any items that are
older than the test replication will be re-processed with every reverse
replication.

If such items already exist in a queue, they can be found with the following XPath JCR query and should be removed.

/jcr:root/var/replication/outbox//*[@cq:repActionType='TEST']

Again you can develop a solution to detect all replication agents (located under /etc/replication/author or /etc/replication/publish), then check the status of the agent (enabled, disabled) and the underlying queue (active, idle, blocked).

Monitoring Performance

Performance Optimization is an interactive process which receives focus during development. After deployment it is usually reviewed after specific intervals or events.

Methods used while collecting information for optimization can also be used for ongoing monitoring.

Knowing as much as possible about your installation can also help you track down what might have caused a change in performance, and whether these changes are justified. These metrics need to be collected at regular intervals so you can easily see significant changes.

Interpreting the request.log

This file registers basic information about every request made to CQ. From this valuable conclusions can be extracted.

We recommend isolating the "slow" pages from the request.log, then individually tuning them for a better performance. This is usually done by including performance metrics per component or using a performance profiling tool such as yourkit.

Monitoring traffic on your website

The request log registers each request made, together with the response made:

The number of the request, in square brackets. This number matches for the request and the response.

An arrow indicating whether this is a request (arrow pointing to the right) or a response (arrow to the left).

For requests, the line contains:

the method (typically, GET, HEAD or POST)

the requested page

the protocol

For responses, the line contains:

the status code (200 means “success”, 404 means “page not found”

the MIME type

the response time

Using small scripts, you can extract the required information from the log file and assemble the statistics you want. From these, you can see which pages or types of pages are slow, and if the overall performance is satisfactory.

You may need to concatenate the individual request.log files if you need to do this operation on a large data sample.

Apache Bench

To minimize the impact of special cases (such as garbage collection, etc), it is recommended to use a tool such as apachebench (see for example, ab for further documentation) to help identify memory leaks and selectively analyze response time.

The numbers above are taken from a standard MAcBook Pro laptop (mid 2010) accessing the geometrixx company page, as included in a default CQ 5.6.1 installation. The page is very simple, but not optimized for performance.

apachebench also displays the time per request as the mean, across all concurrent requests; see Time per request: 54.595 [ms] (mean, across all concurrent requests). You can change the value of the concurrency parameter -c (number of multiple requests to perform at a time) to see any effects.

Request Counters

Information about request traffic (number of requests during a specific time period) gives you an indication of the load on your instance. This information can be extracted from request.log, though using counters will automate data collection to let you see:

To automate information collection you can also install a RequestFilter to increment a counter on every request. Multiple counters can be used for different time periods.

The information gathered can be used to indicate:

significant changes in activity

a redundant instance

any restarts (counter reset to 0)

HTML Comments

It is recommended that every project includes html comments for server performance. Many good public examples can be found; select a page, open the page source for viewing and scroll to the bottom, code such as the following can be seen:

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

Monitoring Performance using JConsole

The tool command jconsole is available with the JDK.

Start your CQ5 instance.

Run jconsole.

Select your CQ instance and Connect.

From within the Local application, double-click com.day.crx.quickstart.Main; the Overview will be shown as default:

After this you can select other options.

Monitoring Performance using (J)VisualVM

Since JDK 1.6, the tool command jvisualvm is available. After you have installed JDK 1.6 you can:

Start your CQ5 instance.

Piezīme.

If using Java 5 you can add the -Dcom.sun.management.jmxremote argument to the java command line that starts your JVM. JMX is enabled per default with Java 6.

From within the Local application, double-click com.day.crx.quickstart.Main; the Overview will be shown as default:

After this you can select other options, including Monitor:

You can use this tool to generate thread dumps and memory head dumps. This information is often requested by the technical support team.

Information Collection

Knowing as much as possible about your installation can help you track down what might have caused a change in performance, and whether these changes are justified. These metrics need to be collected at regular intervals so you can easily see significant changes.

Regular Performance Degradation

JVM Tuning

The Java Virtual Machine (JVM) has significantly improved in respect to tuning (especially since Java 7). Because of this, specifying a reasonable fixed JVM size and using the defaults will often be suitable.

If the default settings are not suitable, then it is important to establish a method to monitor and assess GC performance before attempting to tune the JVM; this can involve monitoring factors including, heap size, algorithm and other aspects.

This will help you see how much memory is being used, what GC algorithms are being used, how long they take to run, and what effect this has on your application performance. Without this, tuning is just "randomly twiddling knobs".