Anturis Blog

How to Monitor a Web Application (LAMP) Hosted on AWS EC2 Using Anturis

Subscribe to Anturis blog

SaaS-based Unified Monitoring

For servers, apps, websites, and services

  • Deploy in minutes
  • Scale with ease
  • Smart alerts
Try for free

September 23rd, 2016 - by Shrinivasan Patnaikuni

This article outlines basics of using Anturis in monitoring IT systems running on AWS. With respect to an application running on AWS, Anturis complements AWS’s monitoring service CloudWatch by allowing easy collection not only of OS-specific metrics, but also of metrics related to applications (databases, processes, services, web servers) and business logic (global response time and availability, full page load time, transactions, etc.). In addition, with IT resources outside AWS (e.g., in-house or other IaaS/PaaS, such as Azure or Rackspace), Anturis provides a single-pane-of-glass view of all distributed IT systems.

Anturis operates in two modes:

  1. External-public-agent based
  2. Internal-private-agent based

The external mode of operation involves remotely monitoring the IT systems using public agents running on Anturis’s global monitoring infrastructure and network. This mode requires that customers not install any custom software to avail a monitoring service.

The internal mode of operation primarily involves monitoring the operating system, software running on that OS, and local network devices accessible behind the firewall. This requires the installation of a private agent which runs as an internal system service. The internal private agent collects vital statistics of system resources and the collected statistics are viewed in a single window through Anturis’s web console.

Installing Linux agents on EC2 instance running LAMP stack

To allow Anturis to monitor CPU usage, disk usage, free physical memory, the Apache webserver, the MySQL server, and other system processes, the Anturis private Linux agent must be installed on the EC2 instance running a Linux-flavor OS. For the purposes of this article, the operating system is Ubuntu 14.04 LTS x86_64.

There are two ways to install Anturis Private Agent for Linux:

  1. Through the command line
  2. By downloading the installation package

We will install the Linux Agent through the command line, which is easier and automatically registers and connects the agent to the Anturis Monitoring Network.

To install the Anturis Linux agent, go to the Anturis portal and log in, then

  1. Click on the “Agents & Locations” tab > “Add new agent” (the + sign);

    • Under the heading “How to install,” choose Linux > Option 1.
    • Copy the command—in our example the command is the following:
    • curl -k -s https://anturis.com/api/1/agent/install/AWS-Anturis/385c1d4b2ab83fd2_nop | sh
      
  2. Log into the EC2 instance and ensure that the instance is able to access resources from the internet. If your EC2 instance is under a private subnet, ensure that the private subnet is configured to allow outbound internet access.
  3. Execute the command as the root user to install the Anturis Linux agent;
    After executing the command, the output would be messages similar to
    Starting Anturis Agent
    Setting settings...
    Success
    Setting settings...
    Success
    Connecting to server...
    Success
    

    These indicate successful installation of the Linux agent and that it is able to communicate with Anturis servers.

    Further verification that Anturis Linux agents are running can be obtained by verifying the command output as the root user as follows:

    ps –aux | grep anturis

    The following command can be used on Ubuntu 14.04 LTS on EC2 instance to check the status of the Anturis agent and to start, stop, or restart the Anturis agent:

    service anturis-agent-service {start|stop|restart|status}

Setting up internal agent-based monitoring

Now that the Anturis Linux agent has been installed and is running smoothly, we will set up internal private-agent-based monitoring for a LAMP stack running on EC2 instance:

  1. Go to Anturis web console.
  2. Go to the “Infrastructure” page on the main menu and add the component by clicking on the “+” icon; then follow the “New Component Wizard” to add a Linux Server component:

  3. Click on “Step 1” after selecting “Linux Server.”
  4. Step 2 will display a list of Anturis Linux agents already installed on EC2 instances that have successfully registered and connected to the Anturis monitoring network:

  5. Select the server you would like to monitor and click “Next” to proceed to step 3 (notice that the operating system, Ubuntu 14.04 LTS x86_64, is displayed).
  6. Upon proceeding to step 3, enter an appropriate name that uniquely identifies the EC2 instance being monitored, and click “Finish”:

  7. You’ll then arrive at the page that allows you to turn on/off the monitoring of disks, CPU, networks, and Linux services:

    Let’s now turn on monitoring for disks, CPU, networks, and system services. When monitoring of a resource is turned on, you’re prompted to decide on the monitoring parameters. For the purposes of this article, we will continue with the default parameter values by clicking “OK”:

    For the purposes of this article, when the monitoring of Linux services is turned on, we select “anturis-agent-service,” “apache,” “mysql,” and “cron”:

    Upon enabling the monitoring of all resources, the page would look similar to this:

  8. Click “Finish” to start viewing the status of the monitoring of the resources:

  9. In order to monitor EC2 instances’ free physical memory, click on the “+” icon under “Add custom monitor” > select “Local resources” tab > “Free physical memory,” and then click “Next”:

    Select the EC2 instance with the monitor period as 1 minute. Click “Next” and in the “Step 3 of 5” dialog, select the proper values for the warning state and error of the monitoring process:

    Click “Next” to verify that monitor test results indicate that the test has been passed:

    Click “Next” to finish.

  10. You can further edit the monitoring parameters by clicking on the “edit” icon; you can also pause the monitoring of a specific EC2 instances’ resource by clicking on the “pause” icon.

Setting up external monitoring from multiple locations

Now that we’ve seen how to set up internal private-agent-based monitoring let’s see how to setup external public-agent-based monitoring. As an example of external public-agent-based monitoring, let’s configure website monitoring with a focus on response time.

In order test the LAMP stack on the EC2 instance, we have created a sample PHP script that prints the current date in different ways.

The sample PHP script has been taken from PHP examples at W3Schools.com. For the EC2 instance we’ve created for this article, the web address URL to access the sample page is http:// 52.45.63.26/index.php. 

The IP address 52.45.63.26 is the Elastic IP associated with the EC2 instance on which we have the LAMP stack running. Alternatively, if you have mapped the IP to your domain name, the URL would look like this: http://<your domain name>/index.php.

Now that we have a sample PHP script running on the EC2 instance, let’s monitor it externally:

  1. In order to create a new website monitor via a public agent, choose the “Infrastructure” tab on the main menu and click “+”; then follow the “New Component Wizard” to create a “Website” (step 1 of 3) , select “Website,” and click “Next”:

  2. Upon clicking “Next” to proceed to step 2 of 3, enable the monitoring of HTTP and “Ping” in order to monitor the webserver externally. Enter the URL as http:// 45.63.26/index.php (for this article, the webserver is running at IP 52.45.63.26 on EC2 instance with LAMP stack). Click “Next” to move to step 3 of 3:

  3. In step 3, before clicking “Next”, it’s important to enable ICMP traffic to the EC2 instance; in order to do that, we need to enable inbound traffic on all ICMP port numbers by editing the security group associated with the EC2 instance under consideration.

    To enable inbound ICMP traffic to the EC2 instance, follow these steps:

    1. Go to AWS management console > EC2 > Security Groups:

    2. Select the security group you want to edit and then click the “Inbound” tab:

    3. Click the “Edit” button, then “Add Rule”:

    4. Set
      Type: “Custom ICMP rule”;
      Protocol: “Echo Request”;
      Port Range: “N/A”;
      Source: “Anywhere”;
      Click “Save.”
    5. Test if you can PING the instance by the command “ping <IP of the EC2 instance>” (here, in our case, the command would be “ping 52.45.63.26”).

      You will see a successful PING request as follows:

      Pinging 52.45.63.26 with 32 bytes of data:
      Reply from 52.45.63.26: bytes=32 time=296ms TTL=48
      Reply from 52.45.63.26: bytes=32 time=297ms TTL=48
      Reply from 52.45.63.26: bytes=32 time=296ms TTL=48
      Reply from 52.45.63.26: bytes=32 time=296ms TTL=48
      
  4. Come back to the Anturis portal and finish the process (step 3 of 3) of adding external website monitoring by clicking “Finish.” Keep the names default. You can edit the names of the monitoring process in step 3 of 3:

  5. Click “Finish” to complete the process:

    Upon creation of a new monitor, it will take a short time—one or two monitor periods—before there is enough data collected for the monitor status to be updated on the Anturis web console.

  6. To configure HTTP(s) monitor parameters, go to “Infrastructure” > “Website Monitoring Component,” select the HTTP monitor you wish to edit, and then click on “Edit” and follow the steps below:

    1. On the “General Settings” tab, change the “Name” and verify the target points to the correct IP. Under “Monitoring location & Available agents,” select the one that you want to be part of external monitoring.
    2. Under the “Monitoring Settings” tab.
    3. In the “HTTP Properties” box, select “POST” or “GET” under “Method.” By default, the “GET” method is selected.
      If you select “POST,” the “POST BODY” box will appear, in which you can input the data you want to post.
    4. Enter the “Port Number.” This is optional as well, but it’s always good practice to specify the port number explicitly.
    5. Optionally, you can change the default value (min:sec) under “Monitor Period.”
    6. For the “Timeouts” option, enter the “Error Threshold” (ms) to receive an error warning if your website exceeds that amount of time, and/or enter the threshold value under the “Warning Threshold.” This is optional.
    7. Keep “HTTP Status” selected—that is the default setting.
    8. For the “HTTP Status” option, select “Matched” or “Not Matched” under “Valid If.” By default, the “Matched” method is selected.
    9. Enter a value for “Status Pattern.” This is optional.
    10. Enter a number for “Redirection Attempts.” This is optional.
    11. If your website uses basic authentication, you need to provide the user name and password in order to enable monitor access to your website. By default, this parameter is not selected.
    12. Select “Found In” or “Not Found In” under “Body Content” under “Content Matching.” By default, this option is not selected.
    13. Click “Finish.”

Setting dependencies between components

When large IT systems are considered, they are usually not a single monolithic architecture-based server. Large IT systems contain multiple servers, each server running various technology stacks pertaining to business logic. In such systems, the health of the entire system depends on the health of each of the many individual server components.

Especially if a highly available application leveraging hybrid cloud containing its infrastructure spanned across AWS, Azure, and Google Compute Engine. The overall health of the application depends on several components. Any problem in the IT system must be tracked down in order to identify the root cause.

In the above situations, Anturis Monitoring Service’s internal and external monitoring can be extended with component dependencies to get a complete picture of a problem’s cause and effect, facilitating more accurate alerting of the appropriate responsible party.

Let’s set up a dependency for our current scenario in which we have a LAMP stack on an EC2 instance and simple PHP script running on it. It is obvious that the status of “Website Monitor” will be “failed” if the Apache server itself fails, which could further may be a result of server crash. Additionally, we will presume that our PHP script also depends on a MySQL server in order to function smoothly.

To create a logical infrastructure schema with existing components, go to the “Infrastructure” page and select “Schema” in the middle of the screen. Above the main area is a toolbar with three tools: “Select,” “Link,” and “Unlink.” To select a tool, just click on it.

For example, from an earlier section, we have three components as follows:

  1. Website on EC2 (checks HTTP)
  2. Apache on EC2 (checks Apache Process)
  3. EC2 Instance (checks instance reachability using PING tests)

Additionally, we will create a fourth component to monitor a MySQL server running on the EC2 instance, since our presumption was that the application depends on the MySQL server as well.

To create a component to monitor MySQL, follow these steps:

  1. Go to Anturis web console, click on “Components +” icon on the “Infrastructures” page. This will open a new component creation wizard:

    Select “MySQL*” and click “Next” to proceed to step 2 of 5:

  2. Select the internal agent and click “Next”:

  3. Enter the port number at which MySQL is running—usually, it is 3306. Also enter the username and password with which the application connects to MySQL. In our case, the username is “root” and the password is “mysql.” Click “Next” to proceed to step 4:

  4. In step 4, you are asked to select various metrics which Anturis Internal Agent will monitor. We select “Slow queries rate (%)” and “Connection usage (%).” Ticking the “Threshold” radio box lets us define thresholds for the monitored metrics upon which alerts would be issued. Click “Next” to proceed to step 5 of 5:

  5. Edit the name with a proper readable name and click “Finish” on “Component Creation Wizard.” Click “Finish” to mark completion of the creation of the component, and go to “Overview” page:

 You can observe that now we have all 4 components required for setting up component dependency:

  1. Website on EC2 (checks HTTP)
  2. Apache on EC2 (checks Apache process)
  3. EC2 Instance (checks instance reachability using PING tests)
  4. MySQL on EC2 (checks MySQL process)

To set up a component dependency as

  1. {Website on EC2} depends on {Apache on EC2} and {MySQL on EC2}
  2. {Apache on EC2} and {MySQL on EC2} depends on {EC2 Instance}
  1. Click the “Link” button, select a component {EC2 Instance}, and move the mouse pointer to select “{Apache on EC2}” (this denotes that the Apache web server depends on an actual physical server, i.e., EC2 Instance):

  2. Select the component {EC2 Instance} and move the mouse pointer to select {MySQL on EC2} (this denotes that the MySQL server depends on an actual physical Server, i.e., EC2 Instance):

  3. Select the component {Apache on EC2} and move the mouse pointer to select {Website on EC2} (this denotes that the website depends on an Apache web server):

  4. Select a component {MySQL on EC2} and move the mouse pointer to select {Website on EC2} (this denotes that website depends on MySQL server):

  5. To unlink two components, click the “Unlink” button, select a component, and move the mouse pointer to another component from which you want the selected component to be unlinked:

Brief overview of troubleshooting scenarios

With monitoring, some AWS issues can be identified by the various states of the monitors. Some of the possible scenarios are listed below:

  • An increase in website response time may be because of high CPU usage or less free memory, which may indicate that under normal presumptions you need to increase the EC2 instance size to a higher class of CPU cores and memory.
  • Failure of the EC2 instance PING test or of SSH connectivity tests may indicate that the EC2 instance is in an undefined state, which can be recovered by an EC2 instance reboot or a SHUTDOWN/START cycle.
  • Even in cases where high CPU usage is observed at low traffic, accompanied by high page load time, it may indicate that the EC2 instance needs to be scaled up.
  • A low free-disk-space state of a monitor signals that EBS disk volumes attached to an EC2 instance are full and need to be scaled to accommodate more storage.