Monitoring Yate
This article shows the modules you need configured and loaded in order to monitor what happens in the server, especially when you have limited access to Yate (e.g. when Yate runs as daemon).
Meaning:
- Eventlogs accessed from rmanager
- SNMP data from Monitoring through YATE SNMP Agent
Since you use or will use Yate, you'll need to check what happens inside the server at some point or another. The services Yate provides must be continuous, in order to avoid loss of calls or information (besides, who would want their lines to stop working right in the middle of a sales conference or a management meeting?).
Monitoring your system can be done in more ways than one, like many other things. This document reffers to the cases where your Yate runs as a daemon (for Linux users). This means that once it's started, you cannot communicate with it directly using a terminal.
The examples given in this document are from Mandriva 2010 spring OS, and Yate/YateClient 4.1.
Contents |
What is monitoring
In this document, monitoring refers to using the two ways presented below in order to obtain running or debugging information as the system continues to run.
Of course, monitoring your software is quite a generic concept. Each Yate user has his/her own idea of what it means, depending on the existing configuration and the tools they prefer.
However, the basic notion of monitoring is that you follow what happens with your system in real time in order to debug or fix sometimes critical issues impending your activity.
Eventslog accessed from Rmanager
In order to monitor Yate through Eventslog, the following modules are needed:
- eventlogs - found in /modules/server. Its configuration file is the eventlogs.conf, in the conf.d directory
- rmanager - found in /modules. Its configuration file is rmanager.conf, also in conf.d.
Eventlogs is a module that allows you to keep multiple logs when your Yate is daemonified, separated by specific criteria.
In order to load it when Yate starts you need to configure the eventlogs.conf from /conf.d directory. In this file you set the path to the directory where you need the files to be created in, having log files depending on your specific configuration for creating them in the [mappings] section (e.g. linksets, trunks, links).
Now, in order to access the files while Yate is running, you need to use Rmanager, a module that makes possible the connection through Telnet to your Yate. The default configuration binds the localhost (127.0.0.1) and listens on port 5038 (you can change the configuration in rmanager.conf).
Type telnet 127.0.0.1 5038 in a terminal and this should follow:
[ana@localhost ~]$ telnet 127.0.0.1 5038 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. YATE 4.1.1-alpha1 (http://YATE.null.ro) ready on localhost.localdomain.
Let's say you want to check what modules are loaded. Type module list in terminal:
module list lateroute* ysnmpagent* mgcpgw monitoring* cache yradius users* pbxassist heartbeat analog presence* park callcounters sipfeatures accfile ysigchan dbpbx regfile register mrcpspeech queues* ccongestion queuesnotify* regexroute wavefile rmanager extmodule ysipchan ystunchan h323chan tonedetect moh callfork* pbx yjinglechan tonegen ilbccodec* yrtpchan enumroute analyzer yiaxchan cdrbuild callgen conference* isaccodec* msgsniff gvoice* dumbchan filetransfer* javascript* openssl cdrfile zlibcompress ysockschan* mux subscription cpuload sigtransport ciscosm* analogdetect dbwave mgcpca clustering* eventlogs jabberserver jbfeatures
This way you can check if a module you need is loaded or not, you can restart it or stop it (depending on your needs). See here more on commands.
You can find out and ultimately control what happenned since Yate started. With logview /events log command all the messages from the point where Yate has started to present (so you can find out the uptime, for example).
logview Events: 132 Yate (5138) is starting Fri May 18 21:01:59 2012 Loaded module File Transfer Loaded module DumbChannel Loaded module Gvoice …........
However, if you are trying to fix an issue that has come up more recently, this might not be so useful, as you are looking for a more recent event, and Yate may have been working for days.
You can also check what events are stored in the specific logfiles you set using the command: events _logfilename_.
SNMP data from Monitoring through YATE SNMP agent
Simple Network Management Protocol (SNMP) is a protocol that regulates information passed on in order to monitor and manage your network. Yate offers SNMP information gathered by the monitoring module (when it's loaded) through the SNMP Agent module.
A simplified and generic model of how SNMP works is that within nodes of a network, you can have managed devices (ranging from routers to printers) with SNMP agents (software) running on them, and the network management systems (NMSs) gathers the information (on request or following an automated script, they also follow traps and could trigger notifications).
The hierarchical structure of network information is expressed by OIDs (object identifiers), translated into readable labels in MIB (Management Information Base).
In order to monitor Yate through SNMP you need the following modules:
- ysnmpagent - found in modules/server. Its configuration file is the ysnmpagent.conf, in the conf.d directory.
- monitoring - also in modules/server. Its configuration file is monitoring.conf in the conf.d directory.
The minimal configuration in ysnmpagent.conf you need to set is:
- port in the [general] section (example: 16001).
- ro_community name in the [snmp_v2] section (example: testsnmp) for using SNMPv2.
Now, you can either interrogate Yate directly or by proxy. Go to the SNMP Agent to see how to configure Yate and SNMP. You will get SNMP information according to the NULL-TEAM-MIB and YATE-MIB definitions files found in the YATE source directory in the share/data folder.
Note: Obtaining certain types of information (like RTP monitoring, SIP monitoring, SS7 monitoring) through SNMP requires configuration of the monitoring module in monitor.conf.
To see an example, start Yate with the monitoring and ysnmpagent modules enabled (you can check if they are loaded by using rmanager as explained above). Now let's say that you ask Yate for the information listed in the NULL-TEAM subtree. It has the .1.3.6.1.4.1.34501 OID (check the information provided here about OIDs).
[ana@localhost local]$ snmpwalk -v 2c -c testsnmp 127.0.0.1:16001 .1.3.6.1.4.1.34501 YATE-MIB::yateMIBRevision.0 = STRING: 201204242240Z YATE-MIB::version.0 = STRING: 4.1.1 YATE-MIB::plugins.0 = Counter32: 66 YATE-MIB::handlers.0 = Counter32: 488 YATE-MIB::messages.0 = Counter32: 0 YATE-MIB::threads.0 = Counter32: 24 YATE-MIB::workers.0 = Counter32: 1 YATE-MIB::mutexes.0 = Counter32: 267 YATE-MIB::locks.0 = Counter32: 0 YATE-MIB::semaphores.0 = Counter32: 0 YATE-MIB::waitingSemaphores.0 = Counter32: 0 YATE-MIB::acceptStatus.0 = STRING: accept YATE-MIB::kernelLoad.0 = INTEGER: 1 YATE-MIB::userLoad.0 = INTEGER: 0
Furthermore, you can write your own script that, following certain traps, can trigger a notification of some kind (email to the administrator, SMS to key individuals) to alert of certain events.
Conclusions
While these two aren't the only tools you can use to keep things under control, they certainly come in handy when the debugging options of running Yate (yate -vvvvv) and using -l (log to file) option are not applicable.
Please share what other ways you use in order to monitor your own Yate-based systems. Also, if, while using Yate, you think you discovered a bug, or have a peculiar behaviour to report, see here useful tips on that.
See also
