In this blog post, we will walk through configuring the various components within a PKS deployment such as vSphere (vCenter Server & ESXi), NSX-T (Manager, Controllers & Edges), BOSH and PKS Control Plane to forward their logs to an external syslog system such as a VMware vRealize Log Insight (vRLI) which includes 25 free OSI licenses for any vSphere customer.

If you missed any of the previous articles, you can find the complete list here:

Step 1 - Download and deploy vRLI. In my setup, I am using the latest release which is 4.6.0 and if you would like a detailed step by step instructions, please take a look at the vRLI documentation here. For lab and proof of concept purposes, you can select the "Extra Small" size when deploying the vRLI appliance.

Step 2 - Once vRLI is up and running, you can start off by enabling the vSphere Integration which enables logging from both vCenter Server as well as the ESXi hosts that it manages. This can be useful for troubleshooting and/or for auditing purposes logging all requests made to the underlying vSphere platform. If you only want to forward vCenter Server Events (VM Create, Delete, Host Add, etc), which is only possible when using the VCSA, take a look at this blog post here to configure this using the VAMI UI interface (https://[VCSA]:5480)

Step 3 - Before we start forwarding logs to vRLI, lets go ahead and install the NSX-T Content Pack which provides us with several useful dashboards specific to an NSX-T deployment. You can access the content pack page by going to the upper right hand corner and click on logged on username and then clicking on the "3-dashes" icon or you can also navigate to the following URL: https://[VRLI/contentpack. Under the Marketplace, select the NSX-T plugin and click Install.

At this point, we are now ready to begin forwarding logs to our newly deployed vRLI instance.

Step 3 - To send NSX-T logs to vRLI, we will need to use the NSX CLI which is only available when you SSH to each of the NSX systems: Manager, Controllers and Edges and run the following command (replace with the IP of your vRLI instance):

set logging-server proto udp level info

You can verify the configuration by running get logging-server or to clear the configuration, you can run clear logging-server. A restart of services is not required for the changes to go into effect.

Step 4 - Lets now configure BOSH to forward its logs to vRLI. To do so, login to the Ops Manager UI and click on the BOSH Tile. Select the Syslog tab and specify the address of your vRLI instance along with the desired port/protocol. For testing purposes, I am using UDP but you may want to consider using TCP and/or TLS for more reliable or secured logging. Once you have saved your changes, proceed to Step 5 before you applying the changes within Ops Manager.

Step 5 - Next, we will configure PKS logging by selecting the PKS Tile and repeating the same step as above. Once you have saved your changes, navigate back to the Ops Manager home page and click on the Apply Changes button on the upper right hand side to deploy the updated configurations.

Step 7 - Once BOSH and PKS has completed their configuration, when deploying new PKS Clusters, lots from each of the respective areas will now be centrally available within vRLI for further processing. If you click on the Dashboard view, you can select the NSX-T Dashboards to see some of the default views that are available as part of that Content Pack. Other interesting Dashboards will be VSAN if you are using that that as your backend storage (there are other storage packs as well) and of course vSphere, which we had configured earlier. If you want to query and see individual log entries, simply click on the Interactive Analytics tab at the top.

Today, the integration between PKS and vRLI is what I would refer to as a "light" integration which requires some additional steps post-PKS deployment. In future, you can imagine we can provide a much tighter integration point in which you only need to specify an external syslog source such as vRLI and the rest will automatically be handled for you, not just within the PKS application but also the underlying infrastructure.

Thanks for the comment!