We heard your feedback and took action on it by exposing an API that gives you access to data collected by the StrongLoop monitoring agent. So, what does this mean for you? You can now access performance metrics data without using our StrongOps console. Along with the API, we wrote strong-agent middleware for publishing metrics via the well-known StatsD protocol. As you know, the StatsD protocol is supported by a large ecosystem of servers and plugins, allowing publishing into custom infrastructure. Many metrics consumers, such as Datadog, have agents that support the StatsD protocol. This makes it trivial to create your own custom dashboard in DataDog powered by the StrongLoop monitoring agent.
Monitoring Node apps with StrongLoop
StrongLoop provides a comprehensive application performance management platform under the name StrongOps. The StrongOps solution provides key performance metrics for Node.js applications by helping you visualize and optimize Node application performance. It helps take your applications from development to production through configuration and deployment capabilities.
Follow the steps in Getting Started to create an application you can monitor with StrongOps. If you already have an application then read here to publish data via statsd. With a single StrongLoop command you can send metrics to a StatsD compatible server:
slc run --metrics=statsd:///my-app.my-host.%w
The rest is easy. Start your DataDog agent as you usually do, and then check the DataDog Integration dashboard for metrics from your Node app.
Some useful dashboards
Here are some useful dashboards that you can create with your DataDog Integrations. View CPU usage, the number of concurrent connections, memory usage, and event loop time using the StrongOps Agent API.
CPU usage for your Node app
Heap usage during GC
Metrics for node applications in your DataDog dashboard
Your StrongOps enabled agent sends you many real-time performance metrics for your Node.js product. Once you know what’s being sent and how you can best utilize each of the metrics, you can group them into as many Integration dashboards as you choose.
|cpu.system||System CPU time. CPU time spent inside the kernel on behalf of the process, expressed as a percentage of wall clock time. Can exceed 100% on multi-core systems. CPU time is the subset of wall clock time where the CPU is executing instructions on behalf of the process, i.e. where the process or its corresponding kernel thread is actually running.|
|cpu.total||Total CPU time. Sum of user and system time, expressed as a percentage of wall clock time. Can exceed 100% on multi-core systems. CPU time is the subset of wall clock time where the CPU is executing instructions on behalf of the process, i.e. where the process or its corresponding kernel thread is actually running.|
|cpu.user||User CPU time. CPU time directly attributable to execution of the userspace process, expressed as a percentage of wall clock time. Can exceed 100% on multi-core systems. CPU time is the subset of wall clock time where the CPU is executing instructions on behalf of the process, i.e. where the process or its corresponding kernel thread is actually running.|
|gc.heap.used||The part of the V8 heap that is still in use after a minor or major garbage collector cycle, expressed in bytes. The V8 heap is where JS objects and values are stored, excluding integers in the range -2,147,483,648 to 2,147,483,647. The exact range differs for ia32 and x64 systems.|
|heap.total||Total size of the V8 heap, expressed in bytes. The V8 heap is where JS objects and values are stored, excluding integers in the range -2,147,483,648 to 2,147,483,647. The exact range differs for ia32 and x64 systems.|
|heap.used||The part of the V8 heap that is currently in use. Expressed in bytes. The V8 heap is where JS objects and values are stored, excluding integers in the range -2,147,483,648 to 2,147,483,647.The exact range differs for ia32 and x64 systems.|
|http.connections||Number of incoming HTTP connections across all servers in this process.|
|loop.count||The number of event loop ticks in the last interval.|
|loop.minimum||The shortest (i.e. fastest) tick in milliseconds.|
|loop.maximum||The longest (slowest) tick in milliseconds.|
|loop.average||The mean average tick time in milliseconds.|
|messages.in.count||Number of received strong-mq or axon messages.|
|messages.out.count||Number of sent strong-mq or axon messages.|
A bit of history
In the past decade of web application development, major java web-application servers realised the need to provide some sort of visibility into connection pools, threads, application heaps, garbage collection et all. Initially every server platform offered their custom monitoring console graphic what seemed to be key performance metrics. All this changed with the advent of the JMX. Java Management Extensions (JMX) is a public specification for monitoring and managing Java applications.
Well known application/middleware servers like Tomcat, ActiveMQ, WebLogic and JBoss embraced JMX specs and published metrics via a common interface to be consumed by APM tools. They focussed on the core problem of generating useful metrics and left the graphing and cross-platform-corelation problem for monitoring solutions to solve.
Through JMX, APM solutions like AppDynamics, New Relic or CA Wily can access Java class properties that collect management data, such as the resources your application is consuming.
How is this relevant to Node.js?
In the node.js world, there wasn’t an equivalent of an application server or rather an API Server, yet the major use case of Node was around building APIs. In it’s platform journey, StrongLoop first launched StrongOps, which had a hosted graphical console to visualize generated metrics and datapoints.
Next we transformed the agent to be the central piece for cpu and memory profiling, transaction tracing and other devops functions. In a way, we created a JMX MBean type mechanism with the agent exposing APIs for external control. StrongLoop API server now comes packaged with the core agent and an API for controlling and accessing the metrics and data streams.
- In a following set of blogs, we will demonstrate additional techniques for integrating StrongOps with tools like Graphite, Zabbix, Splunk or independent scripting utilities.
- What’s in the upcoming Node v0.12 release? Big performance optimizations, read Ben Noordhuis’ blog to learn more.
- Ready to develop APIs in Node.js and get them connected to your data? Check out the Node.js LoopBack framework. We’ve made it easy to get started either locally or on your favorite cloud, with a simple npm install.
- Need training and certification for Node? Learn more about both the private and open options StrongLoop offers.