Private Node Server Control Panel (Web Interface)

The first thing you need to do is to register your Private Node Server in AlertSite. This adds the private node as a new location to your global locations list, so you can use it in your monitors. For step-by-step instructions, see Registering Private Node Server as Location in AlertSite.

Once your Private Node Server is registered, you can change the admin password for logging into the Private Node Server Control Panel. Enter the current password and the new password and click Apply Changes.

The password must be 6-20 characters long. The password cannot contain the following characters:

In certain cases, if you request technical support for your Private Node Server, our engineers may need remote access to it. Remote access is done via Secure Shell (ssh) with authentication.

You can enable or disable remote access on this page. Access remains open for 12 hours, or until you manually disable it.

On this page you can see your Private Node Server software version and check for updates.

If an update is available, select it and click Upgrade. If multiple updates are available (for example, 1.7.1, 1.7.2 and 1.8.0), install the next major revision (1.8.0).

To reboot the private node, open this page and click Reboot. Monitoring will not occur while the node is rebooting.

To check when the node is back up, you can:

• Ping the IP address of the private node.

• Open http(s)://<IP address> in a browser, where <IP address> is that of your private node. Use https for Private Node Server 2.0 and later, and http for earlier versions.

By default, Private Node Server obtains its IP address through Dynamic Host Configuration Protocol (DHCP). If you need to use a static IP address, you can configure it on this page:

• Set Use DHCP to No.

• Enter the IP address, subnet mask, DNS server, and gateway host.

• (Optional) To add additional DNS servers, click Advanced DNS Configuration and enter their addresses.

  To remove an added name server, clear its entry.

• Click Apply Changes to reboot the Private Node Server with the new settings.

If you connect to Internet via proxy, specify the proxy settings on this page. To test connection via proxy, use the Connection Tests or Diagnostic Tests page.

• No proxy – Select this option if you connect to the Internet directly.

• Manual proxy configuration – Select this option to use a proxy server.

  • HTTP Proxy, SSL Proxy, Port – The proxy servers and ports for HTTP and SSL (HTTPS) traffic. Both are required.

    • In Private Node Server 2.1 and later, a proxy can be specified by a host name or IP address. Earlier versions require IP addresses for the proxy.

    • Some proxy servers use the same port for both HTTP and SSL, and some use different ports. Contact your network administrator for the correct settings for your network.

  • SOCKS Host and Port – Specify a SOCKS proxy if needed.

  • SOCKS v4 and SOCKS v5 – Select the type of your SOCKS proxy.

  • No proxy for – Optional. A comma-separated list of domains or IPv4 addresses to connect to directly, bypassing the proxy.

  • Userid and Password – If your proxy requires authentication, specify the username and password. If the username includes a domain name, such as DOMAIN\user, you need to use a double backslash: DOMAIN\\user.

    Note for DéjàClick users: DéjàClick does not support automatic proxy authentication. Authentication needs to be handled in the DéjàClick script using dialog prompts.

What traffic goes through proxy

Private Node Server sends email alerts on port 25. If your local network does not allow outgoing connections through the firewall on port 25, you need to specify a mail relay host on your local network to send alerts through.

On this page you can configure the mail relay:

• Relay Host – The name or IP address of the host to pass all outbound email to.

• Relay Port – The port to connect to the mail relay host (specify only if different from the default 25).

• Masquerading host – Not used. Reserved for future use.

Private Node Server does not retry alerts if it cannot reach the mail relay host.

Network Time Protocol (NTP) is a common method to synchronize computer time with public time servers on the Internet. To learn more about NTP, visit http://www.ntp.org.

Private Node Server uses NTP to maintain the system time. It can synchronize with one or two NTP servers. The default servers are:

• For Private Node Server 2.x:

  0.ubuntu.pool.ntp.org

  1.ubuntu.pool.ntp.org

• For Private Node Server 1.9 and earlier:

  0.debian.pool.ntp.org

  1.debian.pool.ntp.org

If you have an NTP server in your private network or at your ISP, you can use those for greater accuracy. Or you may want to use the NTP servers local to your continent or country. For local NTP servers, use:

where XX is your continent name or two letter country code. For a list of public NTP servers, see http://www.pool.ntp.org/zone/@.

Examples

ExamplesExamples

NTP servers for Europe:

0.europe.pool.ntp.org

1.europe.pool.ntp.org

For Germany:

0.de.pool.ntp.org

1.de.pool.ntp.org

Notes:

• Disable time synchronization with the host so it does not conflict with NTP.

• After changing the NTP servers, reboot the Private Node Server to apply the changes.

• Time synchronization works only if the system time is not too far from the NTP server time. Otherwise, set the system time manually, and the time will start syncing.

Starting from v. 2.1, Private Node Server includes two versions of the SoapUI test runner, which is used to run API monitors. Select the version you want to use:

• ReadyAPI 1.9
• ReadyAPI 1.1

You may want to use an earlier version if your API tests run successfully on it, but are not compatible with later versions of ReadyAPI.

The Private Node Server system time is GMT and is displayed in the top right corner of the control panel.

Maintaining the correct time is important so that your monitoring data has accurate timestamps. Private Node Server synchronizes system time with the public time servers using Network Time Protocol (see NTP Configuration).

If the time difference between the node and the NTP server is large (say, several hours), time will not sync. In this case you need to manually set the system time to the approximate correct time, so the time can start syncing.

You can adjust the system time on this page. Enter the time in GMT (not your local time) and click Apply Changes.

Use this page to select the TLS version that will be used for HTTPS connection to your Private Node Server and click Apply Changes. The default value is TLSv1.1 and TLSv1.2.

Use this page to import the /ets/hosts file and define custom mapping of IP addresses to host names to be used by your private location. Private Node Server will validate all IP addresses and host names and exclude:

• The 127.0.0.1 localhost or loopback.

• All uploaded host names or aliases for hosts with the alertsite.com suffix.

To import the hosts file:

1. Click Import in the top right corner.

2. Click Choose File and browse for the hosts file.

3. Click Upload.

   

   Click the image to enlarge it.

You can edit the imported hosts file:

1. Click Edit in the top right corner.

2. Make any changes in the hosts file.

3. Click Done.

   

   Click the image to enlarge it.

To apply the changes to the private location, click Deploy in the top right corner. You can then roll back to the last successfully deployed version of the hosts file by clicking Restore.

Use this page to check the connectivity to AlertSite hosts and ports required for proper functioning of Private Node Server (see Network Connectivity). Tests are performed using the network parameters configured for this private node, including the proxy server, DNS server, and so on.

The results are displayed after some time (about a minute). Please do not refresh the page during this time.

Click the image to enlarge it.

If there are problems when connecting to certain hosts, make sure your firewall allows traffic from the private node to these hosts. You can run a detailed traceroute to these hosts in Diagnostics > Diagnostic Tests to see if the problem lies within or outside of your network.

A failed registration check means your private node is not registered yet. If the error appears for a registered node, register it again using its 32-character registration ID (or location ID in AlertSite 1.0) you can find on the list of your private locations in AlertSite.

Here you can run various tests to check connectivity from the Private Node Server.

• Hostname Lookup – Gets an IP address for a domain name, and vice versa.

• Traceroute – Runs a traceroute to the specified IP address or domain. Traceroute shows the path that traffic takes to reach the target server, and the delays that occur at each stop.

• Ping – Checks if an IP address or domain is accessible.

  Note:

  For lookup, ping and traceroute, enter the domain name without http://.

• AlertSite Web Test – Checks if a web page is accessible and measures its response time.

  Note:

  Private Node Server must be registered to use this feature.

On this page, you can send your Private Node Server system logs to SmartBear support for troubleshooting. Select all or specific logs, the delivery method, and click Send Logs in the top right.

Private Node Server can send alerts via e-mail, SMS, VoIP, and SNMP traps. On this page you can send test alerts to verify alert delivery. The page lists all compatible recipients configured in your AlertSite account. Click the recipient in the list to send a test alert to it.

Use this page to view your private node system utilization: CPU, memory and disk usage, and the usage of Firefox, Chrome and Selenium browser profiles. If the resource utilization is constantly high, consider adding more hardware resources to your VM to avoid performance issues.

Click the image to enlarge it.

The report under the charts contains the following information:

• Uptime – The system clock, uptime, and the average system load indicator in 1, 5, and 15 minutes.

• CPU – The CPU utilization report similar to that produced by the Linux mpstat command. See mpstat(1) for a description of the included metrics (%urs, %nice and others).

• Mem (kB) – The total amount of free and used memory in the system, and the buffers and caches used by the kernel.

• proc idx (indexes) and proc str – The total number and statuses of browser profiles in the current system configuration. Each character in the square brackets [ ] corresponds to a single browser profile, and the proc idx line is the header for proc str data. The statuses in proc str are:

  • 0 – idle
  • 1 – busy
  • C – checking (this is a transition state between other states)
  • K – killed and under recovering
  • S – stopped or initializing

  Consider the following example:

  prod idx: firefox[0....5....]
  proc str: firefox[111SS00000]

  This means the private node has 10 Firefox profiles (as indicated by 10 characters in the brackets). In the top row, 0, 5 and . serve as indexes for numbering purposes. Out of 10 profiles, 3 are used (status 1 in the bottom row), 2 are initializing or stopping (status S), and 5 are idle (status 0).

• total firefox, total chrome, total selenium – The total number of used and available browser profiles, and their usage percentage. This is a text representation of proc str data.