Node.js Uptime Test

In most production environments, it is essential to monitor the uptime of critical servers in the infrastructure. By tracking the uptime of each of the servers, administrators can determine what percentage of time a server has been up. Comparing this value with service level targets, administrators can determine the most trouble-prone areas of the infrastructure.

In some environments, administrators may schedule periodic reboots of their servers. By knowing that a specific server has been up for an unusually long time, an administrator may come to know that the scheduled reboot task is not working on a server.

Use this test to promptly detect unscheduled reboots and unexpected breaks in the availability of each instance of the target Node.js V8 Engine.

Target of the test : A Node.js V8 Engine

Agent deploying the test : An internal agent

Outputs of the test : One set of results for every instance of the target Node.js server being monitored

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed.

Host

The IP address of the host for which this test is to be configured.

Port

The port at which the target Host listens to. By default this is 3000.

DD Frequency

Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Has the node been restarted?

Indicates whether the instance has been rebooted during the last measurement period or not.

 

If this measure shows Yes, it means that the instance was rebooted during the last measurement period. By checking the time periods when this metric changes from No to Yes, an administrator can determine the times when this instance was rebooted.

The values reported by this measure and its numeric equivalents are mentioned in the table below:

Measure value Numeric Value
No 0
Yes 1

Note:

By default, this measure reports the Measure Values listed in the table above to indicate whether the instance has been rebooted during the last measurement period or not. The graph of this measure however is represented using the numeric equivalents only i.e., 0 or 1.

Total uptime of the node

Indicates the total time that the instance has been up since its last reboot.

Minutes

Administrators may wish to be alerted if an instance has been running without a reboot for a very long period. Setting a threshold for this metric allows administrators to determine such conditions.

Uptime during the last measure period

Indicates the time period that the instance has been up since the last time this test ran.

seconds

If the instance has not been rebooted during the last measurement period and the agent has been running continuously, this value will be equal to the measurement period. If the instance was rebooted during the last measurement period, this value will be less than the measurement period of the test. For example, if the measurement period is 300 secs, and if the instance was rebooted 120 secs back, this metric will report a value of 120 seconds. The accuracy of this metric is dependent on the measurement period - the smaller the measurement period, greater the accuracy.