If you are running vRops and NSX, one of the mangement packs that is a must to install is the NSX management pack – On a side note remember to link Log Insight to vRops, that way when you install the NSX management pack in vRops, it will also install the NSX content pack in Log Insight and setup the alerts in the NSX content pack and forward them to vRops. The NSX management pack delivers both NSX network information as well as traditional network information from switches via SNMP and CDP/LLDP. It helps to provide better to understand of the NSX network, but more important it provides information across virtual and physical networks, this can be seen using OOTB dashboards which shows virtual and physical switches and connections between two points be it VM to VM or host to host (or others combinations). Lastly it also provides OOTB alerts that is really what this blog post is all about. A single vRops alert called “No Syslog Server is Configured”.

No Syslog Server is Configured

This is one of the OOTB alerts the NSX management pack comes with. As the text says “There is no syslog server configured on the NSX Controller”. So you might have setup syslog for the NSX manager and are wondering where is the GUI option for setting up syslog on the NSX Controllers. Its not there! Setting up a syslog server on the NSX Controller is done via API calls. VMware has a KB article on how that can be done “Configuring syslog server for VMware NSX for vSphere 6.x controllers“, this describes how this can be done manually, as I’m lazy and like the task to be done the same way every time, I created a script to fix the problem.

Set-NSXControllerSyslog

This is the script as is – There are others who have done this before, but either they have been too complicated or non functioning. This script only covers the NSX Controller(s), that is connected to a NSX manager, so if you have multiple NSX managers you need to run the script multiple times to configure each set of NSX controller(s).  As the script it self comes with all the comments one could wish for i’m not going to comment on it here. Just a note – The script only sets up unconfigured NSX Controller(s), if a configuration is already in place all the script will do is output the current configuration. If a configuration is to be updated, first the old configuration must be deleted, this can also be done via API call, but that is not part of this script – For more information on how to delete a NSX Controller(s) syslog configuration see this VMware KB – “Configuring syslog server for VMware NSX for vSphere 6.x controllers”

Syntax

The syntax is pretty straight forward there are six options which are all mandatory for the script to function correctly and a seventh variable which you will be prompted for during execution of the script – The password is what you will be prompted for after executing of the script. After the password, you will get an output like the one below – The first line starting with “syslog has” tell us that controller-1 wasn’t configured and have now been configured, the next three lines output the configuration of each NSX Controller. Note that controller-2 and controller-3 doesn’t have a line stating that it has been configured, just a line with its configuration, this is because these two were already configured.

.\Set-NSXControllerSyslog.ps1 admin nsxmgr.MichaelRyom.dk 192.168.1.2 514 UDP INFO
Password: ************
Syslog has been configured on controller-1
Syslog is set to 192.168.1.2 on port 514 using UDP and logging level set to INFO for controller-1
Syslog is set to 192.168.1.2 on port 514 using UDP and logging level set to INFO for controller-2
Syslog is set to 192.168.1.2 on port 514 using UDP and logging level set to INFO for controller-3

 

Wrap up

So I have shown one of vRops strong sides here, being able to detect misconfigurations as well as the performance data that we have grown so use to. In here also lays one of vRops not so strong sides. This is a pretty trivial alert, with a very trivial response – Setup syslog on the NSX Controller in question. This should be one of thoughts alerts which is a prime candidate for automation – unfortunately the current way of doing automation heavily relays on the management pack that has been installed. This is as such not a task that can be fixed easily it does require manual intervention. This is very much a petty, as being able to define ways to fix these kinds of issues in an automated fashion would really set vRops apart and help us deliver the software defined data center that every one is talking about. Until then I guess this script will have to do.

Thanks for reading, take care, and as always the comment section is open.