Working with alarms

Content Gateway signals an alarm when it detects a problem, for example if the space allocated to event logs is full, or if it cannot write to a configuration file. A general alarm message is displayed at the top of the content pane in the Content Gateway manager.

Not all alarms are critical. Some alarms report transient conditions. For example, a "Content Gateway subscription download failed: error connecting" alarm can be generated by a temporary disruption in Internet connectivity.

Content Gateway alarm messages provides a description of some of the alarm messages that Content Gateway generates.

Use the Monitor > My Proxy > Alarms page to see a listing of current alarms, as shown below.


	Note Content Gateway also sends select alarms to the Web module of the Forcepoint Security Manager, where they are referred to as alerts. Summary alert messages are displayed on the System tab of the Web > Status > Dashboard page. Security Manager administrators can also configure SNMP and email alert notifications for Content Gateway alarms on the Settings > Alerts pages.

Clearing alarms

After you have addressed an alarm issue, click Clear in the alarm message window to dismiss the alarm.


	Important Clicking Clear only dismisses alarm messages; it does not resolve the cause of the alarms.

If the same alarm condition occurs a second time, it will not be logged if the first alarm has not been cleared.

Configuring Content Gateway to email alarm messages

In the Content Gateway manager, navigate to the Configure > My Proxy > Basic > General tab.

In the Alarm Email field, enter the email address to which you want to send alarms. Be sure to use the full mail address including @ notation, for example:

receivername@example.com

Click Apply.

Using a script file for alarms

Alarm messages are built into Content Gateway; you cannot change them. However, you can write a script file to execute certain actions when an alarm is signaled.

A sample script file named example_alarm_bin.sh is provided in /opt/WCG/bin. You can modify this file.

Configuring SNMP alerting on Content Gateway (software)

Before configuring SNMP to monitor and report on Content Gateway processes, make sure you have installed Net-SNMP and performed a basic SNMP configuration.

Add the process names and MAX/MIN process values to the "Process checks" section of snmpd.conf. You also need to add the v2 trap specification.

Edit /etc/snmp/snmpd.conf and add the following lines in the "Process checks" area:

proc content_cop 1 1
proc content_gateway 1 1
proc content_manager 1 1
proc DownloadService 1 1
proc microdasys 2 1
proc microdasysws 1 1
# send v2 traps
trap2sink IP_address_of_SNMP_Manager:162
informsink IP_address_of_SNMP_Manager: 162
rwuser all
agentSecName all
defaultMonitors yes

If Filtering Service is also running on the Content Gateway machine and you want to monitor it, add:

proc EIMServer 1 1

To verify that SNMP Agent is sending trap messages:

On the SNMP Agent/Content Gateway machine, start a network packet analyzer and terminate the DownloadService process.

In the packet capture data, look for an SNMPv2-Trap message for DownloadService going to the SNMP Manager. The trap message might be similar to:

Value: STRING: Too few DownloadService running (# = 0)

To verify that SNMP Manager is receiving trap messages:

On the SNMP Agent/Content Gateway machine, terminate the DownloadService process. Note that it may take several minutes from the time the trap occurs until the trap is sent to the SNMP Manager.

On the SNMP Manager machine, check the SNMP trap log for an entry for DownloadService. The name and location of the log file is specified in the snmptrapd startup command (example provided above). Here is one way to find the message if it is being logged in /var/log/messages:

cat /var/log/messages | grep DownloadService

An entry might look like:

Nov 25 15:09:42 localhost snmptrapd[11980]: 10.10.10.10]: Trap,
DISPAN-EV = STRING , DISMAN-EVENT-MIB::mteHotOID = OID ,
DISMAN-EVENT-IB::prErrMessage.4 = STRING: Too few DownloadService
running (# = 0)

Grep for "snmptrapd" to see all log entries related to snmptrapd.

Use nc (netcat) to test basic UDP connectivity between the Agent and the Manager. For example, this command could be run on either side of the connection to test the designated UDP ports.

[root]# nc -u -v -z -w2 10.228.85.10 161-162

Here, "-u" indicates UPD, "-v" indicates verbose output, "-z" means to scan for listening daemons, and "-w2" indicates to wait 2 seconds before timing out.

Sample results:

10.228.85.10: inverse host lookup failed: Unknown host
(UNKNOWN) [10.228.85.10] 161 (snmp) open