Browse
 
Tools
Rss Categories

System Service Monitoring

Reference Number: AA-02099 Views: 1379 0 Rating/ Voters

Following several request from users asking if we provide any interface allowing LumenVox services to be monitored by existing data-center monitoring systems (such as SNMP, Nagios and many others), we have introduced a new mechanism that enable this.

Introduced in LumenVox version 14.1, we added a new WebAPI interface, hosted by the LumenVox manager service (the same one that hosts the LumenVox Dashboard). This interface provides a simply URL that can be automatically read by these network/process monitoring services, allowing the LumenVox services' status to be checked.


Service Status URLs

These URLs are listed below, one for each of the LumenVox services that may be monitored by the manager service.

  

Service

  
  

Status   URL

  
  

Manager

  
  

https://localhost:8080/api/status/manager

  
  

License Server

  
  

https://localhost:8080/api/status/license

  
  

Media Server

  
  

https://localhost:8080/api/status/mediaserver

  
  

ASR Server

  
  

https://localhost:8080/api/status/asr

  
  

TTS Server

  
  

https://localhost:8080/api/status/tts

  
  

Call Indexer

  
  

https://localhost:8080/api/status/callindexer

  

Table 1 : Service status URLs

Note that the URLs shown above assume the default manager settings, on the default port (8080), using the default protocol (https), on the local machine (localhost). If you are connecting remotely to the server in order to obtain this service information, you will need to format your query accordingly as described here:

[protocol]//[IP Address]:[Port Number]/api/status/[Service Identifier]

So, if you were trying to request the status of the LumenVox TTS Server service running on machine whose IP address is 192.168.55.55, and whose Manager ADMIN_PORT was set to 8888 and the manager was configured to use http protocol, the request would look like this:

http://192.168.55.55:8888/api/status/tts


Status Responses

This WebAPI can be called synchronously or asynchronously, as needed and should return one of a predefined set of results, depending on the current status of the specified Service, as shown below:

                       
  

Status

  
  

Description

  
  

Online

  
  

Service is online and communicating with the LumenVox   Manager

  
  

Offline

  
  

Service is offline or not communicating with the LumenVox Manager

  
  

Unmonitored

  
  

Service is not being monitored by the LumenVox   Manager

  

Table 2 : Status Response Descriptions


Detailed Response Description

The responses from these API calls are purposefully simply and unambiguous as shown in the above table. For example if the status request was returning a response from the ASR whose service was Online, the response sent would be a simple one word page containing "Online". Since this is a WebAPI, the response will have a status code associated with it (typically 200 to indicate success), and the response packet will be marked as Content-Type: application/json (although no json markup is used for this specific API).

You can simply test this interface yourself using your favorite browser, and typing in one of the above URLs. For example, here is the result of viewing the status of the ASR service on machine IP address 192.168.55.55



Example using wget

you can also use simple command line tools to access this API if you have them installed, for example on Linux, you could use wget - shown here from a Linux console:

[root@EL6-VBOX ~]# wget --no-check-certificate https://192.168.55.55:8080/api/status/asr
--2015-12-14 17:53:28--  https://192.168.55.55:8080/api/status/asr
Connecting to 192.168.55.55:8080... connected.
WARNING: cannot verify 192.168.55.55"s certificate, issued by "/C=US/ST=CA/L=San Diego/O=LumenVox/OU=LumenVox/CN=LumenVox/emailAddress=support@lumenvox.com"
  Self-signed certificate encountered.
    WARNING: certificate common name "LumenVox"doesn't match requested host name "192.168.55.55"
HTTP request sent, awaiting response... 200 OK
Length: 6 [application/json]
Saving to: "asr"

100%[==========================================================================================>] 6           --.-K/s   in 0s      

2015-12-14 17:53:28 (222 KB/s) - "asr"saved [6/6]

Here we are using the --no-check-certificate option to ignore the self-signed certificate used by default when LumenVox is installed (see our Resolving Dashboard Certificate Issues article to see how to install and use your own valid signed certificate).

The result of this example is written to disk in a file named asr. Opening this file reveals that it contains the single word Online, as expected, indicating that the ASR service is online on the specified server.


Example using curl

An alternative example using curl is shown here from a Linux console:

[root@EL6-VBOX ~]# curl -v -k https://172.16.0.157:8080/api/status/asr
* About to connect() to 192.168.55.55 port 8080 (#0)
* Trying 192.168.55.55... connected
* Connected to 192.168.55.55 (172.168.55.55) port 8080 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb* warning: ignoring value of ssl.verifyhost
* skipping SSL peer certificate verification
* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA* Server certificate:
*       subject: E=support@lumenvox.com,CN=LumenVox,OU=LumenVox,O=LumenVox,L=San Diego,ST=CA,C=US
*       start date: Dec 07 18:35:52 2015 GMT
*       expire date: Dec 06 18:35:52 2016 GMT
*       common name: LumenVox
*       issuer: E=support@lumenvox.com,CN=LumenVox,OU=LumenVox,O=LumenVox,L=San Diego,ST=CA,C=US
> GET /api/status/asr HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: 192.168.55.55:8080
> Accept: */*

< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 6
< * Connection #0 to host 192.168.55.55 left intact
* Closing connection #0
Online

Here, for example, you can see we're using the -v (verbose) and -k (ignore SSL certificate mismatch) options.

The verbose option allows us to see the response ("Online" shown at the bottom of the response) and ignore the invalid self-signed certificate that is used by default when LumenVox is installed (see our Resolving Dashboard Certificate Issues article to see how to install and use your own valid signed certificate).


Example using Windows Powershell

There are a number of other ways to call a WebAPI function. Here we are using the Windows Powershell :

PS C:\Users\YourName> Invoke-RestMethod https://192.168.55.55:8080/api/status/asr
Online

This is not a very simple example, since we needed to disable certificate checking within the powershell due to the fact there is no simple flag that can be used to ignore SSL mismatches as there is with wget or curl. For this reason, we encourage users to avoid using this example wherever possible, but we wanted to include a Windows-based example.

Please also note that the Invoke-RestMethod option is only available if your powershell version is configured to use one of the later versions of .NET. We will leave this configuration, and the disabling of SSL checking to you, since it is well beyond the scope of this article. Searching the Internet should provide you the solution to this if you need it, along with the various warnings associated with it.

Other (and arguably better) examples on Windows might include installing Linux tools, allowing the use of wget, or installing curl command line tools for Windows, among other choices. By far the simplest option on both Windows and Linux would be to use the web browser approach described above.


Interfacing with Management Systems

We have provided this interface and the above simple examples to show how remote monitoring of LumenVox services can be achieved using version 14.1 and later of LumenVox. 

You should note, however, that we are not SNMP experts, or experts in other system monitoring tools available to network administrators. Therefore describing how to interface with individual monitoring systems is beyond the scope of our core competence, so we leave this task up to others. We hope that by demonstrating how to easily access this WebAPI, you are able to utilize this knowledge to easily integrate these service checks within your own systems.