If you are a New Relic rookie you might find you have a few newbie questions about our service. So, I figured I’d provide you with a few getting started tips to help you on your journey to becoming a New Relic power user.
New Relic is the all-in-one web application performance tool that lets you see performance from the end user experience, through servers, and down to the line of application code. While New Relic supports several languages and frameworks, this blog post covers non-language specific subjects to help you better understand the basics. With that said, I do provide links to language specific documentation throughout this post to help you hone in on the details for your environment.
Here are the topics covered in this post:
* Types of Agents
* Server Monitoring Installation and Configuration
* Enabling Real User Monitoring
* Generic “Application Code” in Transaction Tracing Details
* Availability Monitoring
* New Relic REST API
Let’s get started…
The Server Monitoring agent collects operating system and server metrics such as the utilization of CPU, memory, network I/O, and disk I/O. Server Monitoring is a free product and can be installed on any (physical or virtual) server in your environment, whether that server is also running an Application Monitoring agent or not.
New Relic has Application Monitoring agents for Java, .NET, PHP, Ruby, and Python. Each agent has a unique installation process catered to the specific language. See the Application Monitoring agent installation instructions for your language.
So, how many agents do you need? Well, that depends on your environment. Let’s start with an easy example — the classic three-tier environment that includes a host running a web server, a different host running an application server, and yet a different host running a database server. In this example, you will want to install the Server Monitoring agent on each of the individual hosts and install the Application Monitoring agent in the application server.
A more typical example is when you have a horizontally scalable architecture where you have multiple instances of your application server supporting a single application. In this case, you will want to install the Server Monitoring agent on all (physical or virtual) hosts and the Application Monitoring agent in each of the application instances.
Yet another common scenario is when multiple languages are used to build different components of the same application. For example, it’s common for our customers to have both PHP and Java components supporting a single application. In this type of environment, you will want to install both the PHP and Java agent in the respective components of your application.
Server Monitoring Installation and Configuration
New Relic Server Monitoring currently supports Linux operating systems. A Server Monitoring agent for Windows is coming soon. Installing and configuring the Server Monitoring agent is easy but it always helps to read the documentation first:
Enabling Real User Monitoring
Real User Monitoring (RUM) is a New Relic feature that allows you to see the actual end-to-end response time experienced by your users — directly from their browser! Pretty cool huh? RUM reports the total response time for requests, i.e. from the point where the user clicks on a link, the request is sent to and processed by the application and database, and the browser receives the response and renders the page. New Relic breaks down each request by time spent in the application, on the network, performing DOM processing, and rendering the page.
The magic of RUM exists in the Application Monitoring agent, which means you don’t need to install anything else (assuming you have an Application Monitoring agent installed already).
Want to learn more about how Real User Monitoring works? Get the details here.
Generic “Application Code” in Transaction Tracing Details
New Relic automatically instruments specific frameworks for each language that we support. This instrumentation is how we are able to provide code-level performance details for your application. Applications that don’t use a supported framework or use a supported framework but also have custom code may see a Segment in their Transaction Trace Details called “Application Code.”
If you see a lot of “Application Code” segments in your Transaction Trace Details, you can enable custom metric collection for your application. Once you’ve done this, New Relic will replace the generic “Application Code” segment with actual code-level details in your Transaction Traces.
How you setup a Custom Metrics depends on the programming language you use. Look at the following documentation to learn more about Custom Metric collection for your application:
By now, you know that you can monitor the end-to-end performance of your application with New Relic. Did you know you can also monitor your application’s availability? Well, you can and it’s just a check box away. Here’s how to enable Availability Monitoring:
1. Select your application from the Applications list.
2. Select Settings -> Availability
3. Check “Turn on availability monitoring for your application name” and fill out the details specific to your application.
If you want to learn more about New Relic Availability Monitoring, check out our FAQ.
New Relic REST API
New Relic is known for it’s deep performance insight and intuitive and elegant user interface and data visualizations. We also provide a way for you to build your own custom views if you want to look at your data in ways we haven’t thought of yet.
Sometimes you just want to export your raw data and play with it yourself. We understand — we love playing with data too! That’s exactly why New Relic provides a REST API for you to extract your performance data from our system. Sound fun? Check out the New Relic REST API getting started guide and start exporting today.
Well, that’s all for now! Add a comment if there’s a topic you’d like to see covered in this blog post!