In part I of this series, I outlined why Application Performance Management is important for AEM.  In part II of this series, I’ll outline how to monitor AEM infrastructure.

The first type of APM metrics collected for AEM are infrastructure metrics.  These are metrics that are captured at the server level, and show the overall health of a server running AEM, but will not speak to details of why something is occurring within AEM itself.

I like to refer to these metrics as the “what” metrics.  They can tell an engineer what issues are occurring on a server, but often don’t speak to “why” the issue is occurring.

Monitoring “What” is Happening in AEM

For Adobe Experience Manager, monitoring the “what” typically means basic server metrics such as:

  • CPU/Processes – Is cpu running higher or lower than expected, what processes on the server are causing high cpu
  • Memory – Is AEM consuming more memory than expected, or are other processes running on the server consuming memory
  • Disk Space/IO – How much disk space is free, are there exessive reads or writes occurring on disk slowing down AEM
  • Network traffic – How much network traffic both inbound and outbound is being generated by the instance and on what network interfaces

Here is a combined screenshot of various charts generated by New Relic using this data:

And here is a view of an Elastic Dashboard showing the same data:

By monitoring these metrics, they can be used both proactively and reactively to find issues with AEM and it’s infrastructure.  Just keep in mind these metrics will answer the question of “what” is wrong with an instance, but won’t answer “why”.

For example, consider the case of the server running high CPU.  While there can be many causes, Freed Technologies often finds high CPU in AEM is due to:

  • A memory leak that causes the JVM to continuously perform garbage collection which eats up CPU
  • Newly introduced code causing performance bottlenecks or an infinite loop
  • Increased throughput to AEM causing it to render more pages than normal

The server metrics we’ve collected tell us there is a problem, but it won’t answer the question of “why” the problem is occurring, or which of the three scenarios outlined above is the root cause.

Ready to learn how to solve the “why”?   Continue to part III of this series, Monitoring AEM Applications with APM.

If you are interested in collecting server metrics using New Relic or Elastic, continue reading to learn how to install and configure each product.

Installing New Relic Infrastructure

New Relic offers a product named “Infrastructure” to monitor your server infrastructure.  Depending on your flavor of linux (or Windows), there are different ways to install the product.  Freed Technologies typically uses Red Hat 7 flavor linux distributions for running AEM.  While I’d always recommend you view and follow New Relic’s instructions to install their infrastructure agent, I’ve attached a quick guide for installing it on RHEL7:

Create a configuration file and add your license key:

Replace <YOUR_LICENSE_KEY> with your New Relic license key.


echo "license_key: &lt;YOUR_LICENSE_KEY&gt;" | sudo tee -a /etc/newrelic-infra.yml

Create the agent’s yum repository:


sudo curl -o /etc/yum.repos.d/newrelic-infra.repo https://download.newrelic.com/infrastructure_agent/linux/yum/el/7/x86_64/newrelic-infra.repo

Update your yum cache:


sudo yum -q makecache -y --disablerepo='*' --enablerepo='newrelic-infra'

Run the installation script:


sudo yum install newrelic-infra -y

New Relic Infrastructure is now configured and you can view the New Relic Infrastructure app to view your metrics.  Here is a screenshot of several charts generated by new relic showing server metrics:

Installing Elastic MetricBeat

Elastic offers a product named “MetricBeat” to monitor your server infrastructure.  Depending on your flavor of linux (or Windows), there are different ways to install the product.  Freed Technologies typically uses Red Hat 7 flavor linux distributions for running AEM.  While I’d always recommend you view and follow Elastic’s instructions to install MetricBeat, I’ve attached a quick guide for installing it on RHEL7:

Download the MetricBeat RPM:


curl -L -O https://artifacts.elastic.co/downloads/beats/metricbeat/metricbeat-6.5.3-x86_64.rpm

Install the RPM:


sudo rpm -vi metricbeat-6.5.3-x86_64.rpm

Configure MetricBeat:

MetricBeat is configured using a yml configuration file.  On RHEL 7, the file is located at /etc/metricbeat/metricbeat.yml

MetricBeat uses modules to track different types of metrics.  For basic server metrics, the system module is used.  The module can be configured to collect different metricsets from your server.  Typically Freed Technologies configures the following metricsets for monitoring AEM infrastrkucture in MetricBeat:


metricbeat.modules:
- module: system
metricsets:
- cpu
- load
- filesystem
- memory
- network
- process
- diskio
- socket

In addition to configuring metricsets, MetricBeat needs to be configured to send the metrics to Elastic.

The configuration file can be set to output your metrics directly to your elastic search instance:


output.elasticsearch:
  hosts: ["https://<YOUR_ELASTIC_HOST>"]

Or can use Logstash as a proxy for Elastic Search:


output.logstash:
  hosts: ["<YOUR_LOGSTASH_HOST>"]

Configure MetricBeat Custom Fields:

When metric beat sends metrics to Elastic, you can enhance the metrics with additional data.  For an AEM application, Freed Technologies uses two additional datapoints to enhance the data:

  • AEM Environment – Typically AEM is run in multiple environments, such as QA, Stage, and Production.  Each environment should add a field to the metric data indicating which environment the data is from, so it is easy to aggregate information across different AEM servers for a single environment.
  • Instance Type – AEM uses an Author, Publisher, and Dispatcher as types of servers.  When metrics are sent to Elastic, an additional datapoint should be added for the type of instance.  This makes it easy to filter MetricBeat data so you can view server metrics for all author, publish, or dispatcher servers combined.

To add custom fields to MetricBeat, include the following in the configuration:


fields:
environment: <YOUR_ENVIRONMENT'S_NAME>
instance_type: <TYPE_OF_AEM_INSTANCE>

Restart MetricBeat

Now that MetricBeat is configured, restart it to pick up the configuration changes:

sudo service metricbeat restart

MetricBeat is now configured and you can view predefined dashboards of your metrics.  Elastic also allows you to create your own custom dashboards by reusing their widgets.

Continue to part III of this series, Monitoring AEM Applications with APM.

Are you new to APM with AEM and are looking for assistance? Contact Freed Technologies to learn how we can kick start your APM efforts for AEM.