Getting a Handle on Node.js Deployments with Dynatrace – InApps Technology 2022

Hypothetical scenario: The marketing department for your company has just prototyped a sharp new website. They built it with the JavaScript Angular framework, so comes with mad personalization logic that draws data from various data sources. The company’s executives are pleased with the site, so now it is up to the system administrators to get it working quickly and to make sure it hums along with minimal latency.

This can be a challenge.

Some relief may come by using the open source Node.js, a server-side JavaScript runtime built on Google’s V8 JavaScript engine. Using Node could reduce the labor it would take to connect the framework to the backend databases. It’s less work than standing up a traditional Java EE stack for the task.

The danger with JavaScript is that if one part of the code breaks — and you can bet that it will — it can easily cascade into an entire page going blank. And then the phone calls start. When the page does break, or even if it just gets really sluggish, how can the administrator tell where — in this towering stack of web technologies — the root problem hides?

Next week, at the Dynatrace’s Perform user conference, held in Orlando, Dynatrace technology strategist Daniel Khan, will talk about how to use the company’s application monitoring tool to instrument Node.js deployments so that when things go wrong, administrators will know exactly where to look.

The goal with the Dynatrace software is to give administrators and developers an end-to-end view of how multiple tier applications are performing. This information is particularly useful in microservice-type architectures, which have many moving parts. If a web application is slow, the Dynatrace software can help pinpoint where the bottleneck might be.

“We’re able to monitor the whole stack, from the browser to Node.js through to the backend,” Khan said. The company has offered Node.js support since the release of Dynatrace 6.2, released earlier this year.

Why Node

Ryan Dahl created Node.js, written in C, to solve the issue of I/O blocking in web applications, releasing the software in 2009. I/O blocking happens when a web page requests something from a database or disk, causing all subsequent operations to halt, at least momentarily, until a response arrives. This can be particularly aggravating in web frameworks’ such as Ruby on Rails.

Methods for routing around blocking I/O were already available when Dahl first released Node. But building concurrency into web applications tended to require context switching between multiple threads (which chew up time), and necessitated each thread to get its own patch of memory (which gobbles up memory). Other approaches involved program-specific libraries, which are arcane and difficult to learn.

Node.js uses a single event-loop thread to handle multiple chores. Instead of waiting for a response, Node can assign a callback to each function, so the event loop can continue on to the next task and loop back around to the function response when it does arrive.

Using event loops was smart, as was Dahl’s choice of JavaScript as the interface for developers. Being a language for a browser, JavaScript was well-equipped for building event loops.

More importantly, JavaScript was known by a lot of programmers by 2009. By building Node to run as a server-side technology, it instantly gave JavaScript application developers a language they were familiar with.

Walmart’s Jason Pincin, celebrating 500 million page views, served up by Node.js, on Black Friday 2014.

Node.js gained popularity quickly, and not just with start-ups. The technology found a home in many enterprise shops and web-scale companies. Behind the firewalls of companies such as PayPal, Walmart, The New York Times, Groupon and Netflix, you’ll find Node running.

“Node provides a very simple API for pulling data from different data sources in an asynchronous way,” Khan said.

As a result, the developer doesn’t have to worry about the implementation details for a lot of specific backend technologies, speeding dev time and reducing errors. Nor is there a lot of framework overhead to contend with, as there would be in Java EE.

Measure Twice, Cut Once

All good things. But how to work with Node, and the technologies that Node touches, when things go awry?

This is where Dynatrace comes in. An organization runs Dynatrace software on a server, which collects metrics from various agents installed alongside or within the components being instrumented.

Instrumenting Node requires installing only a couple of modules on the Node deployment itself, as well as an agent on the server running Node. The agent captures all the calls made to Node, as well as all the calls Node makes, and the time Node itself takes to process these calls.

Combining this data with similar information from other agents watching over browsers, databases, application servers and other components in a workflow give the administrator a full glimpse of the transaction flow.

A Node.js-based transaction flow

The software provides a topological view of how all the components are connected in a single transaction flow. This chart also details how long, on average, it takes two components to complete a transaction, as well how many transactions each component is handling every minute. The number of failed transactions is recorded, as well as the percentage of the time each component takes to complete its part of the entire process.

All this information is also rolled up to offer a set of metrics on how well the application is performing overall.

Feature image: “Sheep Vortex” by Scott Draves and the Electric Sheep with 3D Design by Somatika. Licensed under CC BY-SA 2.0.