New Relic Reviews

The way some transactions are recorded, you can dig through and see what’s going on with the request, how many times you’re making a certain call. That’s the biggest part – almost like application profiling.

We get greater insight into what our application is doing once it’s in production. We can identify issues faster, and being able to identify issues before they become a big problems is an improvement. We use it in load testing to identify inefficient query patterns.

At times some of the data can be opaque. Some of the aggregates over time tend to become more vague, so you lose resolution. Greater resolution going further back in time would be nice. If I start going back a month or two, the resolution is a lot lower, which is kind of challenging and makes it harder to do in-depth historical analysis.

Alongside APM, we're using New Relic servers, plugins, and pretty much everything else except Insights, Synthetics, or the mobile product.

Pretty stable. Sometimes the charts will fail to load or there are some random errors. But because of the way we use APM, there’s no significant impact.

Our use doesn’t really push the limits of New Relic, but it looks like it will scale just fine.

It was already in production when I joined the company.

I don’t see us being able to operate without New Relic. It’s important to collect a lot of metrics, but it’s more important to identify the ones that are essential to your business purposes. Know which data are really important and what you should keep an eye on.

Dashboards let us monitor applications. We can see exactly what the problem is and where we need to go to troubleshoot it to solve the problem. Most of the time it tells us what the problem is. When you see it up in the application you put it exactly where you need it; we can troubleshoot simply by looking.

If something goes bad, we can resolve it faster and in the proper way, rather than spending a lot of time just trying to understand what’s going on. We can see easily what’s working and not, so there’s less downtime.

It’s really powerful with a lot of features, but some training and documentation from New Relic would be useful.

We had some problems at the beginning, but we may not have set it up properly. It’s not clear if it was stability problem in New Relic or in our application, and it was just at the beginning.

Our stack is fixed, so we only scale within the set number of servers.

I wasn’t on the implementation team.

Sometimes we just don’t know how to maximize the use of its features. If we had some additional training, that would help.

The main APM page with the graphs. We leave that up on our wall and we can tell pretty quickly if something is about to go wrong, or if the response time slows down. Database queries are really helpful as they helps to figure out where the low hanging fruit is in terms of making the site faster on the database site. 

I use key transactions a lot when I’m tweaking the resources for the site. There are certain transactions that I care about more than the rest. 

I use the throughput numbers a lot, especially working on workers as opposed to web. If I’m going to add more workers, first I want to know if there will be a bottleneck somewhere.

It saves time and engineering resources in terms of making things faster and diagnoses problems. For us, engineering uses it but no one else even knows what it is. Overall, it improves the experience of the customers and site users.

It’s pretty solid. Sometimes they have downtime – for the most part the New Relic site is up all the time, but once in a while the data is delayed on the graph (like every month or two), but other than that it works!

It’s scalable – thumbs up. We turn on new servers and New Relic just works.

It was already in production when I joined.

All the information is there, but sometimes it’s hard to figure out what it means. You have to have used it a number of times in order to understand where to look. It doesn’t tell you the whole story, it just gives you pieces.

• Ease of installation
• Ease of use
• It provides a common platform for Dev and Ops to be able to pinpoint and communicate problems
• The solution allows us to quickly pinpoint problems
• There’s good integration between all the products in the suite – browser and some of the plugins

Being able to quickly figure out the root causes of issues. It also makes it very easy to share that information with developers and other people within engineering – we can drill down in parallel.

There are a number of plugins that New Relic makes. It would be nice to be able to instantly integrate that with APM. Right now, they’re in their own little area, so it’s not as easy to quickly dive into a problem, for example in PHP. It’s a little hard to get data on the back end.

The stability and uptime have been great. They do a great job in notifying of maintenance windows. We have had some graph inconsistencies which might represent a quirk in the solution, but we haven’t seen that in a while.

It’s a very scalable solution. We have it on maybe a couple of hundred hosts today. We use an automation tool, Puppet, so we’re able to quickly install the New Relic agent across classes of servers easily. On their end as well, they’re collecting more data, so it seems like they’re scaling out very well too. There are no performance issues with scale.

Actually we haven’t had to use it yet.

Prior to New Relic, we did not have an APM solution. We had a lot of home-built tools but nothing like this with dashboards. Mainly the maintenance of the home-built tools was difficult. It was tribal knowledge with no documentation, so we were constrained by the engineers and their specific knowledge of the tools.

Very straightforward – it was great that everything was packaged so we didn’t have to do too much customization. We changed maybe two lines in the config. The documentation was very straightforward. Once we installed it a couple of times manually, we were able to script it, which was very easy as well.

There weren’t really any contenders – it was go with our home grown solution or this. Initially the product effectiveness was the top of the list. Cost is a consideration. Really cost was secondary to whether the tool actually worked and delivered value. Support wasn’t high on the list but it was a consideration. Mainly the ease of use and product effectiveness are the two main considerations.

It’s a solid product. They continue to innovate year after year. They’re getting closer to a 10, but because of the speed of innovation I think there are a few disconnects within the suite/product line. That’s the main thing that keep sit from being a perfect solution, but they’re a very solid product and a very solid company.

It needs to be a cross-organizational evaluation. Can’t be Dev or Ops-only. The solution definitely needs to be low friction to get it into the environment. Being open to the customers in terms of what their product roadmap is and what the customer can expect, and then getting feedback from the customer to help them along as well is important.

Reviews are important. A lot of times other companies are trying to solve similar problems. People are going to be trying competitive solutions, so getting feedback is important to the vetting process.

The ability to look at applications directly and be able to dig down to server error details.

In APM, we can see error details for things that we never logged before – things that were occurring in our apps that we never knew about. The “a-ha” moment is the first install, and we immediately started to fix things.

We work in a small team in a startup with a lot of customers. From a customer to a software engineer was a one-step process, so tickets could come directly to me. I could go directly into New Relic to investigate what the customer was reporting and verify what they were saying. We can address those issues much faster with New Relic, which is brilliant. That changed things drastically for us.

Previously, we didn’t know what was broken. Now, New Relic tells us so we can prioritize what our teams work on. More importantly, it gives us the ammunition to go back to our product development team to convince them of the priority of fixing certain issues, which helps us prioritize our team’s activities.

Based on what New Relic is adding to the product, they’re adding more real-time graphs and ability to see interactions in real-time. For our business those features could really impact our business.

Never had any problems.

We had agents on servers delivering service from 11 different data centers worldwide. We never experienced a problem. Once the agents were installed, we forgot about them. We've never needed any special maintenance or anything. It scaled really well.

Never had occasion to use it.

Not involved in the initial implementation, but I was involved in agent deploys and bootstrapping data centers. It was super easy.

It’s hard to compare it to other vendors because nobody offers the quality of monitoring tools that we get with New Relic. Otherwise, it’s choosing among disparate products.

When looking, we look at the reliability of the vendor and the level of adoption of the solution we’re interested in.

I feel like it’s the best-in-class, and its differentiator is aggregation and the speed at which you can query large amounts of data. I don’t think any other product gets close. The easy of adoption, also. Start opening up servers and adding agents, and you’re done. You immediately have data.

Just get started. Pick something and try it. Regarding New Relic, you’re going to learn a lot about yourself even if you can’t afford it and you’re going to pick another solution. Too many of us do analysis paralysis on these sorts of things when you should just get started. That’s why trials are so valuable in the vendor space – if you have a way to try it out and you can immediately see the value, you can prove it to someone else.

Just to show the response time of the app, and how much time each request spends in the tiers. Database is a tenth of a second, web takes two-tenths, and Ruby takes one-tenth.

I can tell you that there are two use cases. One is to look at how we are performing on average over time. So, assuming the systems are healthy and we look at the last month, the average response time is very good at telling us that. Let's say I add capacity, I can see it trend downwards. The other use case is pinpoint key problems happening right now. Uber called and they are saying that their Freshdesk isn’t working. We look in and can see clearly that only the database is taking 27 times longer than it should, and it helps us solve acute broken things.

It helps with current broken things and help us understand what is happening on our system overall.

It just gives us an idea for how fast were running. That cuts down to it -- how fast we're running, and if there is slowness, where it's coming from. It's really fast at telling us.

I would say that the user interface is maybe a little bit overly complicated. But I don’t have any specific way to improve it. I would say that what’s not commonly used, that are rarely used, should be less conspicuous and buried behind. Like your iPhone has one or two buttons -- if you need settings you can dig down to that stuff, but you don’t want that in your face when you take a call. Similarly, when you are in New Relic there are all these things that I need to sift through mentally. I just want to see how fast the apps are responding. You can’t change that.

I want to see the potential for Docker statistics or container statistics. Like if we start running containers, will it be able to track data for a given container. If one container serves one purpose, we need to track how many requests per day, when does the usage peek, how much does it vary week to week. And then that needs to be organized per container.

Finally, there's lot of noise on the front page that I don’t want to see. If it is customizable then it isn't obvious. Another nuance is that it always shows the wrong throughput for the most recent five minutes, and it's always wrong. The system is wrong for the most recent five minutes. They show wrong data and that changes after the five minutes is up.

We've had it for more than two years.

10/10 - it's very stable. It went down, maybe, once.

Super scalable. For us it scales for what we need. Scale means does it work as well if you have three nodes or 500, and it does. It doesn't break when you scale it up.

I don’t know. Never had a problem. Never had an issue with it. Really simple, like your microwave. Does it well so I never needed support.

This has always been our solution since we started.

We looked for a product that gives the data in a way that is easy to visualize, is reliable, and is simple.

It helps you to define the transaction percentages, average time, and highest throughput. Also, it tells us the transactions that take the most time on average. Those are the high level, most useful features.

It also tells us about every single request that comes in and how the system reacts to it. You get to see everything from the dashboard, all these breakdowns per layer of your architecture.

Error rate is the second most useful feature – there are alerts tied to that. You get paged when the error rate is above an expected percentage and that has worked very consistently and reliably for us.

The best thing is that the team has grown, and a lot of people are developing the code, but you tend to have regressions that are clearly visible in those transaction traces.

When there’s a deployment, it shows by graphing if a regression has happened, and it allows us to react. Catching regressions in performance is very important, and since we now see the breakdown in every single layer in the application, you know right away if there’s something you’re not expecting. We can then go and figure out if it’s an infrastructure or code issue. It gives you a high level view of all of the requests coming in. Error rates are a good indicator for potential rollbacks for a potential deployment – and usually it’s pretty instantaneous. At the end of the day as users, we get what we want.

For the purposes for which we’re using it, it just works. So far I don’t have any requests for new features.

Currently, it is not the only solution we have for monitoring so there are things that it’s missing – for example what Datadog does for us. Timeline series, custom timelines and graphs, and I’m not aware of those features in New Relic.

Every now and then there are little quirks, like the web site will stop refreshing by itself, or the graphs will show something that’s not happening. But in my experience just refreshing the graphs will fix it. But we’ve never had any downtime with New Relic.

We have scaled up as well in terms of number of hosts. There is some perceivable difference in performance when you’re looking at a graph versus number of hosts, but so far it has been fine. It’s definitely not the same looking at a single host versus many hosts.

The fact that I’ve never had to contact support by email or phone is a good thing. The online documentation has been fantastic. Everything you want is available in the documentation.

It was already in production. I did deployments in the staging environment, but not the first deployment. We will be doing the first deployment for mobile as well.

It was already in production. I did deployments in the staging environment, but not the first deployment. We will be doing the first deployment for mobile as well.

You need to understand what’s in their stack, what technologies, what libraries, and it takes someone who has experience with those technologies to help make the decision. It also comes down to best bang for your buck, and I’d definitely recommend New Relic APM.

It was the first tool our company used for application level monitoring. It doesn't require much investment or technical expertise to implement, and I would recommend it for SME.

Support for plug-ins (RMQ, Redis etc.) is a valuable feature.

Older versions of .NET.

The agents are updated quite frequently, but New Relic doesn't offer tools for doing the upgrade in large environments.

Customer Service:

It's good.

Technical Support:

We had several issues that were dealt with by there tech support, and their level is pretty good.

No previous solution was in place.

The setup is quite simple and there are plenty of online resources.

We did it in-house.

Since the plug-ins that report to New Relic do not require license, the ROI is high.

In server pools, you can install the agent on one server. Also, make sure you make the most out of using plug-ins as they don't require licenses.

We are using it also for monitoring of Azure cloud.