Application monitoring has become a core component of IT infrastructure. It gives you a view of what’s happening to your applications at the higher level. With this information, you can detect anomalies and prevent failure before it happens, analyze trends which will help you predict growth and better estimate the sizing of your application, and so on.
Understanding how application monitoring works
Application monitoring includes three main parts:
- Agent – the agent acts as a sensor. It is the entity that plugs into the application, collects data at various points of the application flow, and reports them to the monitoring server.
- Monitoring server – the monitoring server is the part that collects all the data from the various application tiers, and stores it in a database, to enable aggregated analysis of application behavior and transaction flow over a period of time.
- Monitoring/reporting dashboard – the monitoring dashboard is the part that lets you view various reports on application behavior, based on the data that has been collected from the agent to the server.
New Relic – Application Monitoring as a Service
One of the main challenges involved in many of the existing application monitoring systems is the complexity involved in setting up a monitoring environment, as well as well the cost that is normally associated with it. To overcome these limitations, New Relic is offering real-time application monitoring, as a service, over the internet. What’s cool about it is that you can plug-in monitoring to your application in matters of minutes.
New Relic architecture overview
As can be seen in the above diagram, the New Relic agent plugs into your application and reports the state of the application to the New Relic services over the Internet. You can login through a browser and view your application behavior and statistics any time, by logging into their service.
Beyond the regular use cases of application monitoring (troubleshooting, business activity monitoring, alerting, etc), application monitoring as a service opens new usage opportunities:
1. SaaS/cloud application monitoring – SaaS providers are already used to an “As a Service” model – so monitoring as a service fits well with the way they run their own business and fits nicely into their cost model. As a matter of fact, this is how I got familiar with New Relic in the first place. When we built our cloud offering on Amazon, I was looking for a tool to monitor our cloud infrastructure. Geva Perry first introduced me to the New Relic concept, and it took me only a few hours to plug it into our platform. Bernd Harzog’s overview outlines nicely how we are now benefitting from New Relic in a cloud/virtualization environment:
Issues Unique to Monitoring Cloud Hosted Applications
Since RPM is designed to monitor applications that live in one or more clouds, we should explore exactly what it means to deal with the unique aspects of APM in cloud environments. The first set of challenges which must be addressed when performing APM for cloud hosted applications are the same challenges that must be addressed when monitoring applications that live on a virtual infrastructure – since we can safely assume that most clouds either today already live on a virtual infrastructure or will do so shortly. These issues are explored in detail in the white paper available for download at the end of this review, and are summarized below:
- Dynamic capacity. In virtual environments, capacity can be added automatically, and in many cases while the application is running. Therefore inferring application performance as a reciprocal of capacity utilization no longer works once an application is virtualized.
- Shared capacity. Virtualization puts guests into resource pools which share and pool CPU and memory capacity. Furthermore some virtualization platforms (like VMware) actually share memory across guests. Therefore whatever the number is that gets reported as the amount of a resource that is being used by the application can be warped, or made irrelevant by the degree of sharing that occurs in virtualized environments.
- Timekeeping issues. Virtualizing a guest causes its perception of elapsed time to warp as a function of how much that guest gets scheduled out by the hypervisor. This impacts time based metrics (like CPU utilization) collected by the guest OS and makes these metrics suspect and of dramatically reduced value.
- Dynamic configuration. In a virtual infrastructure, a guest may move between physical hosts, creating new “maps” of how the application is constructed. These moves may be driven by automated management solutions like VMware DRS. They may be driven by a decision to move an application from an internal cloud to an external cloud. APM solutions need to keep working as these moves are made, and if they include application topology mapping features, need to automatically update these maps to reflect changes in the deployment architecture of these applications.
The net effect of these issues is that when an application is hosted on a virtual infrastructure the old method of inferring performance as a reciprocal of resource utilization no longer works. A functional approach must start with an understanding of response time on a per transaction and user action basis within the application. This approach is essential not only because it is the only one that will work, but because it is the one that users and applications teams will insist upon in order to feel comfortable about “their” application residing on a shared/virtualized platform.
2. Real Time Collaboration - sharing your dashboard with third parties – in many troubleshooting situations you are asked to send your logs, CPU utilization traces, and so on, to the third party you are working with, so they can trace the root cause of your problem. The main reason you are asked for these things in the first place, is that you can’t share your local monitoring service with your partner – simply because you will need to worry about security, etc. With New Relic the fact that the monitoring service lives in a secured space outside your organization makes it easier to share this information in real-time, and make collaboration with other parties much simpler. A good analogy to this is Office and Google docs – it’s easy to share a Google document with someone, without worrying about security and without needing to actually send anything to anyone.
How to setup New Relic monitoring with GigaSpaces XAP on the cloud
To start using New Relic you should go through the following steps:
1. Create an account (If you don’t already have one).
2. Obtain the New Relic agent files.
3. Install the New Relic Agent and configuration file in your Java application.
After those two very simple steps you can start monitoring your application. More details on each step are below.
Step 1: Create a New Relic Account
To create a New Relic account, go to this page: http://www.newrelic.com/get-RPM.html
You can start with a free account by choosing RPM light – the free account is limited to basic monitoring usage.
For production monitoring, it is recommended to upgrade to one of the options listed in the page linked above. New Relic and GigaSpaces have announced a partnership that will enable you to get a discount on those other options. For details on how to obtain GigaSpaces/New Relic account, click here.
Step 2: Obtain your NewRelic agent files
The NewRelic agent setup consist of two files, newrelic.jar and a configuration file named newrelic.yml. You need to download them from the newrelic site and place them in your application environment.
Step 3: Add the New Relic Agent to your GigaSpaces environment
You can add the NewRelic agent simply by adding the following environment variable.
To verify that your New Relic agent has started properly, look at the log file located on the same directory as newrelic.jar. If everything worked properly, you should see a message indicating that the agent established connection with the New Relic site. Once this step is done, you can start monitoring your GigaSpaces application simply by logging in to your New Relic account.
Note that by default, New Relic uses a default application name, “MyApplication”. To provide a more meaningful name you should change the app_name: attribute in the newrelic.yml configuration file.
Setting New Relic in GigaSpaces XAP on the cloud
GigaSpaces XAP is integrated with various cloud and virtualization environments. Mostly recently we have integrated with GoGrid and VMware. In these environments, you’ll generally boot the system through a GigaSpaces agent, gs-agent. The agent makes it easy to deploy an application cluster using a simple symmetric configuration across all machine nodes. You can set up the New Relic agent through the same environment variable, as mentioned above. For example, EXT_JAVA_OPTIONS=-javaagent:/full/path/to/newrelic.jar. Since the agent normally starts automatically when the machine boots, you should make sure that this environment variable is set before the agent is called. In a Linux environment, this would normally be your init.d script.
To set the New Relic agent in this environment, follow these steps:
1. Copy the newrelic.jar and newrelic.yml into your application S3 directory
2. Add the following transfer-file elements to your deployment xml:
[crayon-57e81f88706a7305606139/] [crayon-57e81f88706b4889097924/] [crayon-57e81f88706bb956741577/] [crayon-57e81f88706c2686182790/] [crayon-57e81f88706c9451591274/] [crayon-57e81f88706d0905290274/] [crayon-57e81f88706d6574837156/] [crayon-57e81f88706dd126470936/] [crayon-57e81f88706e3435814132/] [crayon-57e81f88706ea912746824/] [crayon-57e81f88706f1492757758/]
3. Set the environment variable to point to add your New Relic agent:
To set the New Relic application-name attribute in your newrelic.yml configuration file to the cloud cluster-name, you can use the following shell utility:
You should place this command line in the deployment initialization script of your GigaSpaces cloud XML file.[crayon-57e81f887070c209011756/]
Your feedback is needed
Adding application monitoring as a first class citizen to the GigaSpaces environment is very exciting for me. We started this journey by adding more visibility and control to our environment through our cluster management API (also called the administration API). We are only scratching the surface on how the two technologies can work together and produce more valuable information for our customers. There are lots of options and tradeoffs involved in getting a productive metering and control system, so it would be extremely valuable to get feedback based on your specific experience and expectations. Feel free to send even your craziest wish list to pm at gigaspaces dot com or simply post a comment on this post.