Running AudioCodes' Syslog Viewer As a Service

How To Have "AlwaysOn" logging from your SBC

Let's face it, in the world of complex, heterogeneous systems that we spend so much of  our time in, logging and tracing are an absolute necessity.  For example , the ability to  analyze  a SIP dialog, step by step, can sometimes be the only way to debug a particular problem. If you have followed the tracing evolution of the Microsoft UC stack from the "flat file"  logging in  LCS ( AKA The Stone age),  to the OCS logger days (AKA The Bronze age), now to the Modern era of  Centralized Logging Service (CLS logging) we currently enjoy  ( OK,  maybe "enjoy" is too strong a word!), it is obvious that there is a premium placed on collecting and analyzing logs these days. 

Session Border Controllers (SBC) are the "firewalls" of any modern VoIP implementation , providing a termination point for both the carrier and internal deployments, while serving to protect each from the other. This is also a place to match, modify, or otherwise manipulate signaling and/or media in nearly unlimited ways. 

I currently have the distinct pleasure of being one of those responsible for the "care and feeding" of a very busy S4B deployment that routes its traffic to the PSTN via AudioCodes Mediant Session Border Controllers. As with S4B, the concept of "always on"  logging at this crucial point in the network is practically a necessity.

As mentioned in the opening paragraph, in order to keep up with those evolving debugging requirements,   AudioCodes' troubleshooting tools have thankfully received their share of  attention with respect to features and ease of use.

While there are times when tools that can be spun up quickly like  Power Syslog Server are absolutely a requirement for some situations ( Thank You, James for another great tool!), my requirements currently are closer to the "AlwaysOn" methodology. I don't know when I may have to go back and look at a call flow, and I don't always have the ability to ask the end user to try and recreate a reported problem.

Enter the newly updated "Syslog Viewer" from AudioCodes R&D.

My initial attempts at  setting this tool to run as a windows service were not met with much success. However, thanks to some able assistance from @mikerps  and the AudioCodes R&D team, they were able to update the tool to add a command line argument ( more on that in a moment)  that allows you to specify a startup configuration. This way, I am able to run it as a service, collecting my logs in the background, allowing me to search them when needed.

Here are the components I used to accomplish this. 

1. AudioCodes' Syslog viewer,  version 1.17
2. NSSM ( The Non Sucking Service Manager) to create the windows service. I have used this tool for many years, but any helper application that will enable you to create a service from an exe should work fine. You may have used SC or the now deprecated srvany.exe, but I like NSSM's ease of use , plus it is public domain, and open source. ( Besides, how can you not love a product that boasts it's non-suckyness?) 

Setting things up

First, you need to grab a copy of the latest syslog viewer ( You'll have to login to AudioCodes' site) . Next we need to create the text file that we will use when launching as a service.  IMPORTANT!! , DO NOT launch the program from the start menu at this time. Instead, we will have the program create the file for us by specifying the filename and path from the command line, as shown below.

Launching syslogviewer from the command line

NOTE: the CLI argument is <dash><dash>config<space><filename>

Once Syslog Viewer launches, we need to setup our config the way we want it to load when the service starts. First set your options in the Tools -> Options Dialog

Tools -> Options Dialog

If you are are going to be using this as an "AlwayOn" logging tool ( which is WHY you are reading this , right ? ),  be sure to set your log file size and number of files before rotation occurs. If you are pointing more than one device to the logger, be sure to check "Create separate files for each device", as this will enhance your ability to locate logs in a busy environment.

Save your options by clicking OK , and then navigate to the "File -> Write Log As..." Option

File -> Write Log As..

and set your log path and file name. As mentioned above, if you have multiple devices, the IP address of the device will be appended to this name. For reference, you can confirm the target folder by looking at the title of the Syslog Viewer window. 

Log path in TitleBar

Now, close the viewer to write your config file.  Then navigate to the folder where you specified your config file  when you launched the viewer. If all went well , you will have an INI file with the settings you just specified.

Config File

When you view this INI file , notice you will see the "WriteLog = true" and "RecentWriteFile=" as the file and path where logs will be stored.

Create the Service

Now, download and extract NSSM. (You can also deploy it via chocolatey using "choco install NSSM")  There is no real install needed. Simply extract the file. NSSM can be configured via CLI or GUI.
Navigate to the proper .exe file and run "NSSM install". The configuration dialog GUI will popup. Note: Running NSSM without any arguments, will launch a help window.

NSSM Installer 

The NSSM install dialog exposes all the options you need to configure a service (ex. run as, startup mode, etc.)   but be sure to add the config file argument exactly as you did when you launched the program initially  (when we created the INI file). The "Service name" field will be the name you use to interact with this service ( ex. via Powershell), but the "Name" field on the Details tab will be the one that you will see in Services.msc. Be sure to set your "Startup type" to Automatic!

NSSM Service Details Tab

Once you install the service, you will see it in the services dialog and you can start it there.

Check your log path and you will see an initial log file created for each device as soon as syslog data starts coming in.

Now, you can open the log files in another instance of the viewer and not worry about closing your window, missing any data,  or forgetting to restart writing logs. (Who me?  No, I've never done that, EVER!)

Happy logging! May you "always" be "on"  the lookout for new syslog adventures. ( See what I did there?)

Till next time!