Documentation

Ensuring and maintaining the availability of ServiceNav Boxes

On the page

Need some help?

Purpose of this document

While the central platform is the heart of ServiceNav, the monitoring boxes are the eyes of the application.
The ServiceNav Box (SNB or monitoring box) allows you to :

  • Collect monitoring information on the client LAN or from an external source.
  • Transmit the collected data to the central platform via the VPN tunnel.
  • Send email alerts (regardless of VPN tunnel access).
  • Execute instructions given by the user via the web interface (immediate check, acknowledgement, application configuration).

It is essential to ensure that the monitoring boxes are always available.

This documentation will explain how to avoid SNB downtime and how to resolve certain problems if they occur.

Monitoring your ServiceNav Boxes

The best way to prevent device failure is to monitor them.
That's what ServiceNav is for!

When setting up a ServiceNav Box, the first two steps must be :

  • Self-monitoring of the SNB via the host template ServiceNav Box - self-monitoring.
    In terms of resources, it is very important to monitor the use of the following:

    • CPU load: 1v CPU per 1000 control points (to be adjusted according to the number of checks undertaken). A lack of CPU will lead to instability of the box and delays in the execution of the checks.
    • RAM: A lack of RAM can prevent checks from being executed and can lead to crashing of or openvpn services resulting in a termination of monitoring.
    • Disk space: a lack of disk space will cause the file system to be read-only and the monitoring to become erratic or even stop.
  • Monitoring via another box via the host template ServiceNav Box - Monitoring by monitoring agent.
    The service Box-Live-Status allows you to ensure that the monitored box has sent monitoring data for the last X minutes.
    If this check becones Critical it is because the monitored SNB no longer sends data to the central platform and therefore the statuses present on the web interface are no longer current. It is imperative to take action to restore communication.

Important to note The monitoring and maintenance of the SNBs are the responsibility of the customer.

For more details, a webinar entirely dedicated to SNBs and their monitoring is available here : How to monitor your ServiceNav Box.
The monitoring of SNBs is described at the end of the following document: Installation of an SNB

Solving ServiceNav Box problems

Even though the risks are greatly reduced by monitoring, it is still possible that a ServiceNav Box may experience downtime.
The following section will present some common scenarios and how to solve the problem.

Scenarios

  • Connection to the VPN tunnel impossible, high latency of the box in the VPN tunnel, untimely connection losses.
    -> Follow the solution : Check network access.
  • All checks are in unknown status.
    -> Follow the solution : Check network access.
    -> If the problem is still not solved: follow Restart remoteOperationBox .
  • The checks carried out by a ServiceNav Box have a very old time stamp.
    -> Follow the solution : Restart remoteOperationBox .
  • Unable to reload configuration on a Servicenav Box.
    -> Follow the solution : Restart remoteOperationBox .
  • Acknowledgements are not processed.
    -> Follow the solution : Restart remoteOperationBox .
  • Immediate checks launched from the web interface are not processed.
    -> Follow the solution : Restart remoteOperationBox .

Solutions

Check network access

  1. Check SNB performance (CPU load, RAM, disk space) and add more if necessary.
  2. Check the time on the box using the command date.
  3. Make sure that no changes/deletions to firewall rules have been made recently.
  4. Verify that the box permits outbound access to the ServiceNav VPN port to the central platform.
    For the platform https://servicenav.io -> telnet vpn.servicenav.io $(awk -F '[ ]' 'NR==42 {print int($3)}' /etc/openvpn/client.conf)
    For the platform https://azure.servicenav.io -> telnet vpn-azure.servicenav.io $(awk -F '[ ]' 'NR==42 {print int($3)}' /etc/openvpn/client.conf)
    For an OnPremise platform -> telnet
    Functional access :

    If the connection fails, take the necessary steps on the firewall.
  5. Make sure that the box's LAN IP address is not duplicated with another machine on the same network.

Restart remoteOperationBox

The Process remoteOperationBox  is responsible for the sending and receiving of messages between the box and the central platform.
If it doesn't work anymore:

  • Monitoring data collected by the box will no longer be sent to the central platform.
  • All actions performed on the web interface towards the box will no longer be acted upon by it.

The Process  is responsible for the scheduling of checks. It communicates with remoteOperationBox to process immediate check executions or acknowledgements made through the web interface.

Carry out the following operations:

  • Connect to the ServiceNav Box with an SSH client.
  • Stop the process remoteOperationBox :
    • Execute: service remoteOperationBox stop
    • Check that no more processes are running : ps aux | grep remoteOperationBox
    • If some remain, manually kill the process instances: Kill. or kill - 9
  • Stop the process :
    • Execute: nagios stop service
    • Check that no more processes are running : ps aux | grep (the stopping of may take a little time, redo the command several times if required ).
    • If there are any processes left kill them manually: Kill. or kill - 9 .
  • At this point, remoteOperationBox must no longer be running and no processes must be present at the output on the command line. .
  • Restart the service : nagios start service
  • Restart the service remoteOperationBox : service remoteOperationBox start and check for the presence of 6 instances of the service.
  • Check on the web interface that the application is working again.

If the problems persist after the restart of the 2 services, please contact ServiceNav support.

Recovering a ServiceNav Box

3 Use cases:

  • The ServiceNav Box is completely unusable despite a reboot. Cannot connect to it via SSH or a local console.
    -> Follow this document : Preparing for ServiceNav Box DRSee the section "Complete replacement of a ServiceNav Box".
  • Migrate a defective but still accessible ServiceNav Box to a new one.
    -> Follow this document : Migration ServiceNav Box
  • Perform a restore of the ServiceNav Box using a backup.
    -> Follow this document : Preparing for ServiceNav Box DRSee the section "Rollback from a backup of the ServiceNav Box".

This may also be of interest to you

install script

Preparing for ServiceNav Box DR

Configurer une ServiceNav Box pour utiliser un serveur de mail avec authentification

Replacing an Ubuntu12.04 with a ServiceNav 4.0 Ubuntu16.04 Box

en_US
fr_FR en_US

Welcome to ServiceNav!

Need help? More information about our products? Write to us!
You have taken note of our privacy policy.

[COVID - 19 ] - TELEWORKING, TARGET AVAILABILITY 100% !

While the epidemic lasts, ensure the availability and performance of your IT services for teleworking, with ServiceNav!

Following the government's call to mobilize to help businesses overcome the current health and economic context, we help you, free of charge, to ensure the complete monitoring of your teleworking environments: VPN, VDI, Teams, Skype Enterprise, Citrix... Objectives: collection, availability and usage indicators, dashboards to support your communication.
We use cookies to ensure that you have the best possible experience on our site, and if you continue to use this site, we will assume that you are satisfied with it.

Reserve your place

You have taken note of our privacy policy.