The most valuable features for us are:
- Application performance index score
- Error rate
- Transaction traces
The most valuable features for us are:
When an app goes down, we can get insights into the issue with New Relic. It tells us what the problem is. For example, if there is an issue in the code, we see a spike in the error rate in the applications. The load environment lets us stress test our application to find the bottlenecks in the code.
They already have everything we need, so I can't suggest an improvement.
I was not involved with deployment.
Very stable. No problems.
No problems.
One issue – there is no option for live chat or phone support. We can go to the community forum to post a question and wait for the answer.
The solution was already in production when I got to the company.
New Relic is the right solution in my opinion. The light version of server monitoring is free with New Relic, and application performance index and error rate are the key features to look into.
Debugging tools, as we’re huge on this. Being able to drill down into what’s actually going on with our stack, being able to see the performance issues, where our bottlenecks are.
We do continuous deployment and delivery. One of the things that’s useful is to be able to detect when we deploy bugs and issues into the live platform – error reports are hugely useful.
Throughput, apex, those kinds of things, so we can always see what’s going on. The New Relic Browser also gives us the front-end reporting, versus APM on the back-end.
Speed to issue resolution – making sure our stack is healthy. If someone reports an issue we’ll always go to New Relic first; that’s where it becomes a good product in and of itself. It gives us all the information we need in one place.
We have custom insights dashboards – massive screens with all this information aggregated.
A few issues in the past; there were some CSS issues where sometimes the CSS wasn’t rendering, but they seem to have overcome those. I’ve never experienced downtime which is impressive.
We use the APM scalability tools; more so in the past. Now we’re in the cloud we can see how the stack performs. We use some of the graphing to see at what point we’ll hit bottlenecks, and the in-depth reporting to identify weak points.
We’ve used it a couple of times. They’re great. They follow up with us as well, which is nice and quite unusual.
It was already in production, but I have done it in the past elsewhere. It’s so straightforward it’s ridiculous.
I like the solution so much I haven’t necessarily tried other products and don’t need or want to. Ask if the solution has the main features your stack needs. Does it support your languages, frameworks?
I like the integration with PagerDuty, so that helps spread out our on-call schedule. Application performance helps us drill down on the bottlenecks in our applications, to save us a lot of development time.
The real benefits are for end users. They’re getting a better experience with our software. It allows us to respond faster to any incidences.
No problem at all.
It's absolutely great.
No problem at all.
They were fine. I spoke to a developer from the mobile team and he answered the question on the first attempt.
This is our first APM. We were looking for a solution that helped us to improve our customer experience. It was borne out of database issues we were having at the time. We had no APM solution prior – it was all done manually.
Straightforward. It would have been better to have more transparency to understand how New Relic actually slots onto your page, how it fits into your application.
We also looked at AppDynamics. New Relic felt like a better solution and the data that came out during the trial was better.
Breadth of features, user experience, and constant development of the platform, as well as the value it’s adding to our business. Our products have grown with the New Relic platform; we see the value that people are getting from the platform. The data pretty much speak for itself – sign up, get a trial, and use it in production immediately.
Short turn-time to resolution is essential. It’s the flashlight to the core of an issue in a production environment that everyone may have missed in development, QA, and implementation.
So basically it allows the business to more efficiently spend its money rather than in QA. The faster you can identify these question marks and find answers, the faster we can solve the problem, and the quicker we can solve the problem. We can focus on net new value.
The new Insight stuff is pretty exciting, so that’s interesting to some of our clients. Some way to disable data scrubbing manually would be a big feature.
We’ve been in production for five years.
Never had an issue.
Again, no problems, but I've never run it at a site that is truly a top-100 site. We know there is some overhead, but nothing Google-scale.
The cost of the solution is high on a per-node licensing scheme and that’s the prohibitive factor, but in terms of the actual scalability there are no issues.
The licensing fee for a single node can be comparable in price to running that node, certainly in the modern cloud world.
We haven’t had an opportunity/need to use it.
The solution we were using before was cobbled together from a mixture of sources, various monitoring solutions. None of them really offered the visibility of the overall health of the application. They’re all sort of looking at unrelated data points and we were left to infer what was happening.
New Relic understands the common tools you’re using; they had the first player advantage, plus the kind of nailed everything else. When they first released APM for Ruby there was nothing else like it, and there was barely anything else like it for any other tech stack. When they first hit market they were fundamentally different and better.
New Relic “hides” all of the stuff that is less valuable and lets the good stuff bubble up which lets you focus on that rather than anything else. A huge part of it has been the lack of having to do any app configuration to get started.
Incredibly straightforward. Procurement is the hard part.
Dynatrace came up in conversations, but not really. Solarwinds also.
New Relic is the first thing we bring up. When the vendor is aligned with the rest of the development community around the technologies. They have nice trial periods, month-to-month, which does make it easy. We are looking for solutions that allow us to say with a straight face to our clients that they work and they’re safe.
They didn’t rake us over the coals to start extracting value, and there's no lock-in. We got really fast results times and it's a pleasure to work with. A growing suite of tools that work together, New Relic is going after bringing solutions to a contiguous set of needs. It’s a win for the clients, and it’s a safe bet for the future.
Understand whether you’re using a SaaS; the organization needs to be warm to the solution. Put together a PoC to show the value of the product – put it in a dev environment and start feeding it data to be able to understand the value of it.
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.
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.