NOTE
StrongLoop Arc and slc are no longer under active development, and will soon be deprecated. Arc's features are being included in the IBM API Connect Developer Toolkit: Please use it instead.
Skip to end of metadata
Go to start of metadata

Prerequisites

Icon

See Setting up monitoring for important prerequisites.

Get a demo application

If you don't have your own application, download the profiler-demo-app application.  It's designed to showcase StrongLoop metrics collection and CPU / heap profiling, and comes with a load generator script.  Clone it from GitHub as follows:

See Profiling for more information on the demo application.

View application metrics

By default, Arc starts a local instance of StrongLoop Process Manager, and displays "local application" in the Hostname field. It automatically displays the process IDs (PIDs) of the local application processes and select the first PID by default. Then, it displays metrics for that PID.

StrongLoop Arc Metrics provides live statistics on CPU use, event loop execution, and heap memory consumption for any Node application.

In the module picker, click Metrics to display the Metrics module:

To monitor an application running locally:

  1. Run it with the app controller.  
    Leave "local application" as the Hostname and Port value un-set.
  2. Click Load.
    Arc will show the application process ID in a blue box.
  3. Select a process ID (by default, the first one will be selected).
    Arc will start to display metrics graphs.

To monitor an application running remotely:

  1. Rung StrongLoop Process Manager on the remote host.  See Using Process Manager for more information.
  2. Build and deploy an app to the remote host.  See Building and deploying for more information.
  3. Enter: 
    • Host name: the name of the system where StrongLoop Process Manager is running the application; for example, myhost.foo.com.  
    • Port: Enter the port on which StrongLoop Process Manager is running, by default 8701.
  4. Click Load.
    Arc will show the application process IDs under the Processes heading.  
  5. Select a process ID (by default, the first one will be selected).
    Arc will start to display metrics graphs.

You can see a variety of metrics: CPU, Loop, HTTP Count, HTTP, Heap and Loop Count, as illustrated in the screenshots below.

See Available metrics below for a complete list.

Available metrics

Metric NameDescription
CPU metrics

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.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.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 elapsed wall clock time when the CPU is executing instructions on behalf of the process, that is, when the process or its corresponding kernel thread is actually running.

Event loop metrics
loop.countNumber of event loop ticks in the last interval.
loop.averageMean average tick time in milliseconds.
loop.minimumShortest (fastest) tick in milliseconds.
loop.maximumLongest (slowest) tick in milliseconds.
Heap metrics
heap.total

Total size of the V8 heap, expressed in bytes.

The V8 heap stores JavaScript objects and values, excluding integers in the range -2,147,483,648 to 2,147,483,647. Note: the exact range depends on the processor architecture.

heap.used

The part of the V8 heap that is currently in use. Expressed in bytes.

The V8 heap stores JavaScript objects and values, excluding integers in the range -2,147,483,648 to 2,147,483,647. Note: the exact range depends on the processor architecture.

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.

Strong agent reports this metric only when the garbage collector actually runs (periodically, as needed).

The V8 heap stores JavaScript objects and values, excluding integers in the range -2,147,483,648 to 2,147,483,647. Note: the exact range depends on the processor architecture.

Not available in StrongLoop Arc.

HTTP metrics
http.connections.count

Number of new HTTP connections in the last interval.

Not available in StrongLoop Arc.

Message queue metrics
messages.in.count

Number of received strong-mq or axon messages.

Not available in StrongLoop Arc.

messages.out.count

Number of sent strong-mq or axon messages.

Not available in StrongLoop Arc.

Third-party module metrics

StrongLoop Process Manager collects metrics for a number of third-party modules, reported as:

  • <module>.count

  • <module>.average

  • <module>.maximum

  • <module>.minimum

The following table lists supported modules and recorded metrics:

modulemetric
loopback-datasource-jugglerQuery time in ms (reported as dao.<metric>)
leveldownQuery time in ms
memcacheQuery time in ms (reported as memcached.<metric>)
memcachedQuery time in ms
mongodbQuery time in ms
mysqlQuery time in ms
postgresQuery time in ms
redisQuery time in ms
riak-jsQuery time in ms (reported as riak.<metric>)
oracleQuery time in ms (reported as oracle.<metric>)

Process Manager reports metrics once per time interval. For modules with more than one command or query method, PM reports the sum of query times for individual methods.

For example, the strong-oracle module has .execute().commit() and .rollback() methods. PM sums reponse times for those methods and reports them as one metric, where:

  • oracle.count is the number of calls in the last interval
  • oracle.average the mean average query response time
  • oracle.maximum the slowest query response time

  • oracle.minimum the fastest query response time

Examples:

 

 

 

  • No labels