Notifications

NetEye can be set up to send SMS notification to allow DevOps and Network Managers to be informed immediately about problems in the monitored infrastructure and promptly take adequate actions.

It is not always possible to connect an SMS Gateway between NetEye and a physical NetEye appliance like an SMS modem. For instance, you may be in a situation where:

• NetEye is operated on virtual infrastructure (e.g., the Cloud or with VMware)

• The mobile network signal is weak, forcing the SMS Gateway to be located at a distance that exceeds the maximum length for a serial cable

A dedicated SMS LAN Gateway (i.e., a serial-to-ethernet adaptor) that can solve these problems is available for use with NetEye. These devices are sourced from Moxa and are tested for compatibility with the notification strategy of NetEye.

If you are interested in the SMS LAN Gateway, please contact the NetEye support.

How It Works

With the Moxa device in TCP Server Mode, the host computer (NetEye) initiates contact with the NPort 6150, establishes the connection, and receives data from the serial device. This operational mode also supports up to 8 simultaneous bidirectional TCP/IP connections, enabling multiple hosts to collect data from the same serial device at the same time.

The Moxa NPort 6150 supports SSL and SSH, encrypting data before sending it over the network. It has port buffers for storing serial data when the Ethernet connection is down, and the serial connection supports RS-232, RS-422 and RS-485.

NPort 6150 Hardware Setup

We recommend that you assign a static IP for the Moxa NPort device before connecting it.

You should first set up both hardware devices before proceeding to configure the software. The basic steps are:

1. Set up the Moxa NPort device and power it on

2. Check that the Ready and Link LEDs are green

3. Connect the modem to the Moxa NPort device with an RS-232 serial cable, attach an antenna, insert the SIM, and power it on

4. Check that the modem’s LED changes from red to green

5. Connect the Moxa NPort device to the network with an Ethernet cable

Moxa Device Configuration

The Moxa NPort series has both a built-in telnet server and a built-in web server for configuration. You can use either method as they have the same functionality. You should change the IP address, netmask and gateway according to your needs. Other changes are not necessary as we connect our Wavecom GSM Gateway to the Serial interface on the adaptor and the default settings work without problems.

The device is configured at the factory with the following default profile:

IP address: 192.168.127.254 Username: admin Password: <blank or “moxa”>

Once connected, you will be asked to change your password (press ESC to skip this). To change the default IP address, go to the Network tab and then the Basic tab. Change the field for the second line marked “IPv4 address”, and change the netmask and gateway if necessary. To change the serial interface type from the default RS-232, go to Port > Line > Interface.

Configuration for NetEye

You will need to install the modules without updating the kernel itself.

# yum install moxa-npreal2 kmod-npreal2

If you connect the Moxa NPort device to a remote switch on the network, you should skip this next step. However, if you connect your Moxa device directly to a physical NetEye server on a dedicated ethernet port, you must configure the dedicated network interface on NetEye with the desired network configuration, for instance:

# cat /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=none
IPADDR=192.168.127.1
NETMASK=255.255.255.0
IPV6INIT=no
USERCTL=no

Next, configure the IP address of the NPort 6150 for the Linux driver (this step is necessary since the Moxa NPort device is connected to NetEye via Ethernet). After configuring npreals, you will need to return here to insert the number appended to the end of the IP address (see below for which value to use):

# cat /etc/sysconfig/npreals

# Configure devices in this mode:
# DEVICES="IP:PORT(s) {IP:PORT(s)}"
#
DEVICES="192.168.127.254:1"

Start and Test the Driver Daemon

Set up the npreals system service.

# systemctl enable npreals.service
# systemctl start npreals

Next, you will need to manually install the UUCP package, which is used to communicate with the modem.

# yum install http://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/u/uucp-1.07-41.el7.x86_64.rpm

Now get the device’s tty name from the npreals configuration, which in this example, it is ttyr00,

# cat /usr/lib/npreal2/driver/npreal2d.cf

#=========================================================#
#   This configuration file is created by Moxa NPort      #
#   Administrator Program automatically, please do not    #
#   modify this file by yourself.                         #
#=========================================================#
ttymajor=3
3htmclalloutmajor=38
#[Minor] [ServerIP] [data]  [cmd]   [FIFO]  [SSL]   [ttyName] [coutName] [interface][mode][BackIP]
0   192.168.127.254 950 966 1   0   ttyr00  cur00   0   0   (null)

You MUST use this tty name in the modem’s smsd.conf file under the section [GSM1] > device (here ttyr00 instead of ttyS0 as described in the Modem Setup section). In addition, check that the number in the [FIFO] field is the number after the colon in the file /etc/sysconfig/npreals as shown further above.

Next, test your access to the Moxa NPort device with the device’s tty name from the prior step using the cu terminal program.

# ping 192.168.127.254

...

# cu -s 115200 -l /dev/ttyr00

Connected.
~.
Disconnected.

If the connection was successful (i.e., you see the “Connected.” response), you can now proceed to configure the GSM modem interface and test sending SMS messages as described in the setup. Note that to end a cu session you will need to enter the command ~. since the terminal program will block all control characters that typically end a session.

If instead you see a message such as:

cu: /dev/ttyr00: Line in use

then double check your configuration in smsd.conf (especially the tty device) and the permissions as described below.

Final Notes

If you want to use smssend, remember that that script uses a different embedded default path which you will need to change:

# /usr/bin/smssend

SMS Modem Setup

NetEye uses SMS Server Tools 3 (smstools) for handling the GSM modem interface. More detailed configuration documentation can be found in the smstools official documentation).

The configuration file is located at /neteye/local/smsd/conf/smsd.conf.

Here is a sample smsd.conf file:

# Example smsd.conf.

devices = GSM1
#logfile = 1
logfile = /neteye/local/smsd/log/smstools.log
# loglevel [1-7]:
# A higher number indicates increased verbosity.
loglevel = 7

# PLEASE DO NOT EDIT THESE PATHS
failed = /neteye/local/smsd/data/spool/failed
incoming = /neteye/local/smsd/data/spool/incoming
checked = /neteye/local/smsd/data/spool/checked
outgoing = /neteye/local/smsd/data/spool/outgoing
executable_check = no


[GSM1]
# Use the modem's tty, or the tty of a bridging device if you are using one
device = /dev/ttyS0
# For older WaveCom modem devices, use this baudrate:
#baudrate = 9600
# For newer WaveCom and Sierra devices, use this instead:
baudrate = 115200
# For the new Sierra FX30(S) modem, uncomment this line:
#rtscts = no
mode = new
incoming = yes
cs_convert = yes
# Uncomment this line if your SIM has a pin (we recommend leaving the SIM PIN blank):
#pin = 1111
eventhandler = /usr/lib64/tornado/bin/tornado_sms_collector -c /neteye/shared/tornado_sms_collector/conf/

Note

For Sierra FX30 and FX30S models, remember to uncomment the parameter rtscts = no above. Also, if you are using the Moxa NPort 6150 to extend your modem’s range, be sure to insert the Moxa tty device in place of ttyS0.

After changing the configuration, you will need to restart the SMS daemon as follows:

[root@neteye ~]# systemctl restart smsd

Testing SMS Notifications

The phone number should include the country code and contain only numbers. So for instance a phone number in Italy might be 00391234567890.

There are two methods for testing that SMS messages are correctly sent:

1. Send an SMS message directly from the command line with the smssend script: # /usr/bin/smssend 00391234567890 "TEST FROM NETEYE"

2. Interact directly with the smsd daemon. To do this, create a file with content like the following in /neteye/local/smsd/data/spool/outgoing/ (the actual name of the file doesn’t matter). The smsd daemon will send the SMS without further intervention:

   To: 00391234567890
   
   TEST FROM NETEYE
   

To check the status, you can look directly in the directories under /neteye/local/smsd/data/spool/ or check the log file, for instance with:

# tail -f /neteye/local/smsd/log/smstools.log

SMS Notification Setup

After you have properly setup a SMS modem you should configure notification. To achieve this, you need to create suitable users and notifications. The whole process requires to create new data field and commands, then notification templates and user templates to define users, and finally to use them within a rule.

Note

In case of a cluster installation you need an SMS modem connected to each node. It is not possible to use a single Moxa configured on two different nodes.

Data Field Creation

Create a data field with following parameters:

• Field name = “user_sms”

• Caption = “User SMS”

It will be necessary when defining new user templates, to allow them to access the SMS functionality.

Commands Creation

Now you have to create two commands, one for the hosts and one for the services, necessary to activate SMS notification for hosts and services respectively.

The command for the hosts needs the following parameters:

• Command type = “Notification Plugin Command”

• Command name = “sms-host-notification”

• Command = “/usr/local/bin/sms-host-notification.sh”

• Timeout = 60

• Disabled = “no”

Arguments:

Argument	Value
-4	$address$
-6	$address6$
-b	$notification.author$
-c	$notification.comment$
-d	$icinga.long_date_time$
-f	$notification_from$
-i	$notification_icingaweb2url$
-l	$host.name$
-n	$host.display_name$
-o	$host.output$
-r	$user_sms$
-s	$host.state$
-t	$notification.type$
-v	$notification_logtosyslog$

Fields:

• Field = “user_sms”

• Mandatory = “Mandatory”

Create a command for the services with the following parameters:

• Command type = “Notification Plugin Command”

• Command name = “sms-service-notification”

• Command = “/usr/local/bin/sms-service-notification.sh”

• Timeout = 60

• Disabled = “no”

Arguments:

Argument	Value
-4	$address$
-6	$address6$
-b	$notification.author$
-c	$notification.comment$
-d	$icinga.long_date_time$
-e	$service.name$
-f	$notification_from$
-i	$notification_icingaweb2url$
-l	$host.name$
-n	$host.display_name$
-o	$service.output$
-r	$user_sms$
-s	$service.state$
-t	$notification.type$
-u	$service.display_name$
-v	$notification_logtosyslog$

Fields:

• Field = “user_sms”

• Mandatory = “Mandatory”

Notification Template Creation

Now, by using the commands defined in the previous section, set up two new notification templates as follows:

Host notification template:

• Notification Template = “sms_host_notification”

• Notification command = “sms-host-notification”

• States = Down, Up

• Transition types = Acknowledgement, Custom, DowntimeEnd, DowntimeRemoved, DowntimeStart, FlappingEnd, FlappingStart, Problem, Recovery

Service notification template:

• Notification Template = “sms_service_notification”

• Notification command = “sms-service-notification”

• States = Critical, OK, Unknown, Warning

• Transition types = Acknowledgement, Custom, DowntimeEnd, DowntimeRemoved, DowntimeStart, FlappingEnd, FlappingStart, Problem, Recovery

Notifications - Users - User Templates Creation

We can now create a user template with following parameters:

• User template name = “notify_allEvents”

• Send notifications = “yes”

• Custom properties = “User SMS”

Fields:

• Field = “user_sms”

• Mandatory = “Optional”

User configuration Creation

To create a user that is allowed to send SMS, import the template notify_allEvents and specify User SMS as Custom property.

Notification Apply Rule Creation

As last step, create an apply rule with following parameters:

• Imports = “sms_host_notification”

• Users = “your_user“, i.e., the user created in the previous section.

• Apply to = “Hosts”

• Assign where “host.name” = “*”