Zenoss is an Infrastructure monitoring application that monitors network, server, storage, power devices etc. It is distributed software that monitors the IT environment and generates events based on data which has been exposed with rest APIs or from third parties. This document describes the configurations required to establish a connection between the Zenoss application and the Zenoss LAM.
- The LAM reads configuration from given zenoss_conf file.
- The LAM connects with the host and request for the event console data.
- The event data of all the devices in Zenoss is received by the LAM as a response. The format of received events is JSON.
- If uid_filter variable in monitor section is set, then the LAM filters the events based on the uid_filter value.
- The LAM parses the events and convert it into map messages and then publish it to MooMS bus.
- After parsing, the event data is filtered and the device data along with unmapped event data is sent to the overflow variable.
- The LAM creates events that are submitted to MooMS bus.
- The events are published to the subject “/Events”.
HTTP request with basic user authentication is used in the Zenoss LAM
Lam uses http://"IP name":8080/zport/dmd/evconsole_router” as end point for event request
A user can configure how the Zenoss LAM processes events received from a Zenoss server by accessing the zenoss_lam.conf file, at the following path /usr/share/moogsoft/config
The Zenoss server does not need any configuration to connect to the Zenoss LAM, only the following information is required which can be entered in the zenoss_lam.conf file.
- The URL of the Zenoss server along with the port
- Username and password of the Zenoss console
The Zenoss LAM works with the Zenoss server version 4.2.5
Zenoss LAM Configuration
The events received from the Zenoss server are processed according to the configurations in the zenoss_lam.conf file. The processed alarms are published to Moogsoft AIOps
The configuration file contains a JSON object. At the first layer of the object, LAM has a parameter called config, and the object that follows config has all the necessary information to control the LAM.
The following sections are available for configuration in the Zenoss LAM configuration file:
The details of the connection with the Zenoss server are defined in the monitor section of the configuration file. The user can configure the parameters here to establish the connection with Zenoss server.
The above example specifies:
- url: It is the IP address and the port of the Zenoss server
- user_name: It is the username of the Zenoss console login
- password: It is the password of the Zenoss console login
encrypted_password: If encrypted password is used then enter the encrypted password in this field and comment the password field
At a time either password or the encrypted_password field is used. If both the fields are not commented then the field encrypted_password will be used by the Zenoss LAM
uid_filter: If a user needs to filter events based on device UID, the user can provide the uid_filter parameter. Multiple UIDs can be provided by separating the UIDs with a comma ‘,’
If the uid_filter field is commented or left blank then the events received by the Zenoss LAM are not filtered. The Zenoss LAM receives all the events generated by all the devices monitored by Zenoss
events_date_format: The date/time format of the event received in response . The possible value would be like "yyyy-MM-dd HH:mm:ss", "yyyy-MM-dd'T'HH:mm:ss'Z'", etc. If this value is set to blank then event date/time will be epoch time.
polling_interval: The polling time interval between the requests after which the event data is fetched from Zenoss. The polling interval is entered in seconds
The default value is set to 10 seconds, if 0 is entered in this field then the time interval is by default set to 10 seconds
max_retries: The maximum number of retry attempts to reconnect with the Zenoss server in case of a connection failure
The default value is set to 10, if 0 is entered in this field then the LAM by default takes the value 10 and will try at least 10 times to reconnect
If all the number of retries are exhausted, then an alarm is sent to Moogsoft AIOps about the connection failure. For re-establishing the connection the LAM has to be restarted
retry_interval: The time interval between two successive retry attempts
The default value is set to 60 seconds, if 0 is entered in this field then the time interval is by default set to 60 seconds
timeout: If for any reason the response is not received from the Server against a request, then the LAM discards the request after waiting for some time. The time that the LAM waits before discarding is given here in the timeout field. For example, If the timeout field has 120 entered in it, then the LAM will wait for 120 seconds for a response from the server, against a request. If no response is received for 120 seconds, then the LAM discards the request and sends a new request
The entry in the fields polling_interval , max_retries, retry_interval and timeout should be an integer, therefore enter the values in these fields without quotation marks
event_severity: This field helps in filtering events based on severity, Zenoss sends events with severity codes, the event with a severity code matching with the severity code in this field are only processed by the LAM. The severity codes of Zenoss are as follows:
- 0 is Clear
- 1 is Debug
- 2 is Info
- 3 is Warning
- 4 is Error
- 5 is Critical
- use_ssl: Set it to true to enable SSL communication. If set to true then use https instead of http in the url field
disable_certificate_validation: If SSL certificate is not to be used and https communication is to be bypassed then set it to true
ssl_keystore_file_path: Enter the keystore certificate along with the fully qualified path. E.g. /usr/local/zenoss_ssl/keystore.jks
ssl_keystore_password: Enter the keystore password
Agent allows the user to define 2 parameters:
The above example specifies:
- name: This is the agent name, the events sent to MooMs by the Zenoss LAM are identified by the agent name in the log. In this example the agent name is Zenoss
- log: In this instance, the Zenoss LAM will write its ingress contents to zenoss_lam.log located at /var/log/moogsoft/
Refer the document HA Configuration of LAM
For the Zenoss LAM the JSON parsing is used, hence the variable section is not used. The variable section is only used for text message. For JSON parsing, the mapping section is used. In mapping there is a value called rules, which is a list of assignments.
In the example above, the signature field is used by the LAM to identify the correlated alarms, it is mapped to a combination of agent and eventClass.uid. However, user can change it as per the requirement.
User defines a number of these rules covering the base attributes of an event. For reference, the system expects a minimum set of attributes in an event that are shown in the above example.
To map the sub-field values of a field in the Zenoss alarm the “. “operator is used e.g. "$device.uid”. Here “uid” is the subfield of the field device. So to map the subfield the “.” operator is used
Example of Zenoss events:
Constants and conversions
There are rules in mapping section for which conversions are to be defined. The conversions convert the received input from one format to another. E.g. in the above example of mapping, for the mapped field agent_time, the time is converted by calling the conversion function timeConverter. The example of calling a conversion is as follows:
The example of constants and conversions sections is as follows:
The above example specifies:
- Severity and sevConverter: The severity field has a conversion defined as sevConverter in the Conversions section, this looks up the value of severity defined in the severity section of constants and returns back the mapped integer corresponding to the severity
- stringToInt: It is used in a conversion, which forces the system to turn a string token into an integer value
The alarms/events are displayed in the Moogsoft AIOps, the data in the fields of the alarm or event mapped in the mapping section are shown in the respective columns of Moogsoft AIOps columns. The fields of alarms and events which are not mapped in the mapping section are displayed in the Custom Info field of the alarm. An example of Custom Info:
The attribute that is never referenced in a rule is collected and placed as a JSON object in a variable called overflow defined here and passed as part of the event.
The Zenoss field “DeviceClass” is sent to the Zenoss LAM. Since it is not mapped to a field in the zenoss_lam.conf file, it is placed in the overflow JSON object. The fields that are placed in the overflow variable can be viewed in the Zenoss LAM log file.
Example of an overflow JSON object created in the Zenoss LAM log file
Starting the Zenoss LAM
To start the Zenoss LAM enter the following command:
To stop the Zenoss LAM enter the following command:
To view the status of the Zenoss LAM enter the following command:
In some instances, the attribute strings are quoted. Our JSON parser ignores it, but the standard requires quoting for all strings, so Moogsoft recommends that user quote all strings.
A user can comment out lines by appending them with a hash.
Command Line Attributes
The zenoss_lam is a command line executable that can be run as a service daemon, and takes 4 attributes, which can be viewed by typing:
Points to a pathname to find the configuration file for the LAM. This is where the entire configuration for the LAM is specified
Displays all the command line options
Displays the component’s version number
Specifies the level of debug. By default, you get everything. In common with all executables in MOOG, having it set at that level can result in a lot of output (many messages per event message processed). In all production implementations, it is recommended that log level be set to WARN, which only informs you of matters of importance
Expected to Work
This LAM was tested on a system with the following configurations:
|Operating System||CentOS Linux release 6.7|
The system must at least have the above mentioned system requirements to run the LAM.