New App Dev Models Require New Monitoring Tools

Modern app dev models have forced a change in the way we monitor and manage our code. Instead of building one monolithic application, we’re now developing applications as distributed systems, using microservices to handle application functions. In many cases we’re also reusing those services across more than one application.

The result is a complex mix of services that is hard to track and analyze. Orchestration tooling such as Kubernetes adds complexity with code that will automatically scale and can be distributed across multiple cloud service regions. It’s a model that’s not readily supported by traditional application monitoring tools. Designed to support monoliths, these traditional tools fail to track application flows across multiple services and struggle to identify the application ownership of API calls into shared code.

Application monitoring specialists New Relic recently added support for distributed tracing. As Victor Soares, senior product manager, notes, “We’ve been around for 10 years now, and the way people write code has changed.”

Building on New Relic’s existing cross-application tracing tools and available as part of its existing APM Pro product, the new distributed application tools can be added to your applications simply by updating your existing monitoring agents and deploying them across your application. Most common application platforms and languages are supported, including Java, .NET, Node.js and Go.

Once you’ve updated your agents, you can track service performance across all your monitored code in the New Relic Dashboard, using scatter charts and waterfalls to display performance. As the dashboard is handled by New Relic’s SaaS platform, you don’t need to make any configuration changes, and any service instances deployed by automated scaling will be traced as soon as they are deployed.

It’s a model that should fit in with current ways of working and help with a move to DevOps.

“Companies are on a spectrum of DevOps. … The ideal state of DevOps [is] where individual engineering teams are setting up their own alerts, they're creating their dashboards to monitor their systems, with a true sense of ownership--if it breaks you fix it,” said Soares.

Modern application monitoring takes an end-to-end, user experience-focused approach to tracing application performance. Adding distributed tracing helps DevOps teams understand how applications are working. With support for common languages and development platforms, companies can use New Relic’s tooling to understand the bottlenecks in their applications. Data from distributed traces can be used alongside more traditional traces, allowing users to link back-end microservices to front-end applications, tracing asynchronous calls to APIs.

Each traced service is visualized as a “span," and bar charts give an at-a-glance view of performance. This makes it easier to spot issues, and to then drill down into the specific service to understand how it’s been called and what data has been sent as part of the call. Key service traces can be visualized separately and added to DevOps dashboards for quick monitoring of important services. There are also filtering tools to help companies focus on specific traces, making it easier to pinpoint issues. Soares notes that it allows teams to “Set up alert conditions that are more informative, that don’t wake us up at night.”

Once code is monitored and bottlenecks spotted, developers will be able to optimize their applications. If you’ve designed a service to handle a relatively small number of queries, knowing that one of the applications using the service is seeing a slow-down in useful information. However, knowing that the slow-down is due to an excessively large query from one specific application can help DevOps teams quickly rectify performance issues by restructuring the calling code to make multiple, faster queries.

It’s best to take care when rolling out distributed tracing, as turning it on for an entire fleet of services can be overwhelming. New Relic recommends starting with a set of business-critical calls and services so you can get a feel for how you want to use these new tools while at the same time getting any quick wins. Once you have your first traces in place, you can start to add calls as needed. Soares suggests a simple approach to implementation: focus on end users. “There are two layers of monitoring--monitoring the customer experience, start there and then work your way backward. Set up alerts around throughput and response time so there are signals when we go to troubleshoot individual services.”

Modern application monitoring takes an end-to-end, user experience-focused approach to tracing application performance; adding distributed tracing helps DevOps teams understand how applications are working. With support for common languages and development platforms, organizations can use New Relic’s tooling to understand the bottlenecks in their applications. Data from distributed traces can be used alongside more traditional traces, allowing you to link back-end microservices to front-end applications, tracing asynchronous calls to APIs.

Each traced service is visualized as a “span”, and bar charts give an at-a-glance view of performance. This makes it easier to spot issues and to then drill down into the specific service and understand how it’s been called and what data has been sent as part of the call. Key service traces can be visualized separately and added to DevOps dashboards for quick monitoring of important services. There are also filtering tools to help focus on specific traces, making it easier to pinpoint issues. 

DevOps and modern application development go hand in hand, so it’s good to see one of the pioneers of application performance monitoring adding distributed application tracing to its platform. Debugging distributed applications can be hard, so giving DevOps teams as much information as possible is essential. New Relic’s new tooling should help deliver that information, and make it easy to act on data from your running code.