New Relic: Are You Wasting Its Power?

Did you know that over 60% of companies using New Relic, a powerful observability platform, fail to fully capitalize on its features due to common misconfigurations? This can lead to wasted resources and missed opportunities to improve application performance. Are you making these same mistakes?

Ignoring Deployment Tracking

A staggering 75% of organizations don’t consistently use New Relic’s deployment tracking features, according to a recent study by the DevOps Research and Assessment (DORA) group. DORA’s research shows that high-performing teams meticulously track deployments to correlate code changes with performance impacts. Without proper deployment tracking, it’s nearly impossible to pinpoint the root cause of performance regressions after a release. I had a client last year, a small e-commerce company based here in Atlanta, who struggled for weeks to diagnose a sudden spike in error rates after a website update. After integrating deployment markers, they immediately identified a problematic code push and rolled it back, saving them significant revenue and customer frustration.

This functionality is accessed via the New Relic deployment API. It’s not enough to simply deploy your code; you need to tell New Relic that you’ve deployed it. This creates a marker in your dashboards and allows you to directly compare performance before and after each release. Neglecting this step is like driving a car without a speedometer – you’re just guessing your speed.

Dashboard Overload and Alert Fatigue

Data indicates that 40% of IT professionals experience alert fatigue, as reported by a survey conducted by Ponemon Institute. The Ponemon Institute study highlighted that too many alerts, often from overly broad dashboards, lead to missed critical issues. This often happens when organizations create massive, all-encompassing dashboards in New Relic that display everything from CPU usage to database query times. The problem? No one knows what to focus on. We see this all the time. Instead, teams should create focused dashboards tailored to specific services or team responsibilities. For example, the database team should have dashboards that primarily focus on database performance metrics, while the front-end team focuses on browser-related metrics. I used to work at a fintech company where the infrastructure team created a single, massive dashboard for the entire platform. It was so overwhelming that nobody ever looked at it. After breaking it down into service-specific dashboards, the team was able to identify and resolve issues much faster. Think of it this way: would you rather receive 100 irrelevant alerts or 5 highly relevant ones?

Further, are you using the correct alert conditions? Are your thresholds appropriate? A common misstep is setting overly sensitive alert thresholds that trigger false positives, leading to even more alert fatigue. Fine-tune your alert conditions based on historical data and business requirements. Don’t just accept the default settings. If your tech stability is a moving target, you’ll want to get this right.

Ignoring NRQL’s Power

Only 25% of New Relic users actively leverage NRQL (New Relic Query Language) for custom queries and alerts, according to internal New Relic data. This means a huge portion of users are stuck with the default metrics and pre-built dashboards, missing out on valuable insights that are specific to their applications. NRQL allows you to create highly customized queries, alerts, and reports tailored to your specific needs. For example, you can use NRQL to track the performance of a specific microservice, identify slow database queries, or even monitor custom business metrics. The possibilities are endless. If you are not using NRQL, you are only scratching the surface of what New Relic can do. We ran into this exact issue at my previous firm. We were trying to track the performance of a newly developed API endpoint, but the default metrics didn’t provide the level of detail we needed. By using NRQL, we were able to create a custom query that tracked the endpoint’s response time, error rate, and throughput, allowing us to quickly identify and resolve performance bottlenecks.

Learning NRQL is an investment, yes, but it’s one that pays off handsomely in terms of improved observability and faster issue resolution. New Relic offers extensive documentation and tutorials to help you get started. Take the time to learn it; you won’t regret it.

Neglecting Tagging and Metadata

A recent industry survey indicates that 55% of organizations fail to properly tag their New Relic data with relevant metadata. This lack of tagging makes it difficult to filter, group, and analyze data effectively. Think of tags as labels that you can attach to your data to provide context. For example, you can tag your transactions with the customer ID, product ID, or region. This allows you to filter and group your data based on these tags, making it easier to identify trends and patterns. Without proper tagging, you’re essentially flying blind, unable to see the big picture or drill down into specific areas of interest. One thing that’s often overlooked is the ability to tag transactions with business-relevant data. For example, if you’re running an e-commerce site, you can tag transactions with the order ID, customer ID, and product ID. This allows you to track the performance of specific orders, customers, and products, providing valuable insights into your business. Here’s what nobody tells you: consistent tagging also dramatically improves the effectiveness of your anomaly detection and machine learning features.

Case Study: Optimizing a Fintech Application with New Relic

Let’s look at a concrete example. A fintech company, “Alpha Investments” (fictional, of course), was experiencing performance issues with their core trading platform. They were using New Relic, but weren’t getting the insights they needed. Here’s how they turned things around:

1. Problem: Slow transaction times during peak trading hours.
2. Initial State: Basic New Relic setup with default dashboards. No deployment tracking. Limited NRQL usage.
3. Actions Taken:
   • Implemented deployment tracking using the New Relic API.
   • Created service-specific dashboards for the trading engine, order management system, and risk assessment module.
   • Developed custom NRQL queries to track the performance of critical API endpoints.
   • Added tags to transactions to track the performance of different trading strategies.
4. Results:
   • Identified a problematic database query that was causing slow transaction times.
   • Optimized the query, resulting in a 40% reduction in transaction times.
   • Reduced alert fatigue by 60% by creating targeted dashboards and fine-tuning alert conditions.
   • Improved team collaboration by providing a shared view of performance data.
5. Timeline: The entire process took 3 months.
6. Tools Used: New Relic, NRQL, SQL Profiler.

Alpha Investments’ experience demonstrates the power of using New Relic effectively. By implementing deployment tracking, creating targeted dashboards, learning NRQL, and tagging their data, they were able to significantly improve the performance of their trading platform and reduce alert fatigue.

New Relic is a powerful tool, but it’s only as effective as the people using it. Avoid these common mistakes, and you’ll be well on your way to unlocking the full potential of this technology and achieving true observability. Prioritize deployment tracking — it’s the single most impactful change you can make.

To fix performance bottlenecks, you need the right tools and expertise. If you’re concerned about wasting cloud money on inefficient apps, New Relic can help.

Don’t let your New Relic investment go to waste. Start tracking your deployments today. This single action will give you immediate and measurable improvements in your ability to diagnose and resolve performance issues, leading to happier customers and a more stable application.