WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Detecting ESXi Remote Syslog Connection Error Using a vCenter Alarm

07.27.2012 by William Lam // 6 Comments

I was just cleaning up one of my development labs and found that one of my VCSA (vCenter Server Appliance) which I had configured with vSphere Syslog Collector was no longer capturing logs for several of my ESXi hosts. After looking at some of the ESXi logs, I realized that I had rebooted the VCSA at one point and that caused an interruption in syslog forwarding and then knew immediately that I just needed to reload the syslog configuration via ESXCLI as noted in this VMware KB to restore log forwarding.

After restoring my syslog configurations, I had remembered a neat little trick I learned from one of the VMware TAMs about creating a vCenter Alarm to alert you when an ESXi host is no longer able to reach a remote syslog server. I thought this might be very handy alarm to have in your vCenter Server in case you hit a similar issue or having some connectivity issues with your syslog servers. By default, there is not an event on syslog connectivity but you can create a vCenter Alarm based on an eventId which shows up as "esx.problem.vmsyslogd.remote.failure" in both /var/log/hostd.log as well as /var/log/vobd.log.

Now that we know the eventId, we just need to create a vCenter Alarm which will notify us when it has a connectivity issue with it's configured syslog server.

Step 1 - Create a new alarm, in this example I am calling it "Syslog Connection Error" and you will need to specify the Alarm Type as "Host" and monitor for a specific event.

Step 2 - Next, click on Triggers and we will go ahead and paste in our eventId which is "esx.problem.vmsyslogd.remote.failure"

Step 3 - Lastly, you can configure an Action, if you wish to send an SNMP trap, run a command or send an email notification. In this example, we are just going to generate a regular vCenter Alarm event, so go ahead and just click OK to save the alarm.

To test the alarm, I just disabled the syslog-collector on the VCSA using "service syslog-collector stop" and you should see an alarm generate for any ESXi hosts forwarding it's logs to that particular syslog server.

So now when your ESXi hosts can not reach it's syslog server, you will automatically be notified and can look into the problem immediately. Now having an alarm is great ... but you might be wondering what about the need to reload the syslog configuration on all your ESXi hosts to restore syslog forwarding? This can definitely be a challenge/annoying, especially if the syslog server's connectivity is returned after some amount of time and you have hundreds of hosts.

Well luckily, you no longer have to worry about this, with the latest ESXi 5.0 patch03 that was just released, this problem has been addressed and ESXi syslog daemon will automatically start forwarding logs once connectivity has been restored to the syslog server. It is still definitely recommended that you have more than one syslog server in your environment and that they are properly being monitored. Also, do not forget with ESXi 5.0 you can now configure more than one remote syslog server, for more details take a look at this article here.

Note: After applying the patch, you will no longer be able to generate an alarm based on the eventId for syslog when using UDP. You will see something like "Hostd [290D5B90 verbose 'SoapAdapter'] Responded to service state request" in the hostd.log. The alarm will only be valid if you're using TCP or SSL protocol for syslog which have not been patched with latest p03.

If you are looking for a quick way to reload your syslog configurations, you can easily write a simple for loop to reload your ESXi hosts using the remote ESXCLI:

Here is another example using PowerCLI in-conjunction with ESXCLI:

Categories // ESXi, Uncategorized Tags // ESXi, syslog, vob

Free Linux & Windows Syslog Alternatives to depercated vi-logger in vMA 5

07.25.2011 by William Lam // 12 Comments

Those of you who currently use vi-logger in vMA 4.x as a free syslog server for your ESX(i) hosts may notice this functionality has been removed in the latest vMA 5 release. VMware decided to remove the syslog functionality in vMA in favor of combining it with the vCenter Server. If you decide to run vCenter 5 on Windows, you have the option of installing an additional syslog collector on the same or separate Windows system and registering it as a vCenter plugin. If you are using the new VCVA (vCenter Server Virtual Appliance), there is also a syslog collector that is installed by default.

Using vMA's vi-logger was an easy and free solution, but you still have some alternatives without having to use vCenter or install/build a new syslog server. The following will document a free syslog solution for both a Linux or Windows platform.

Linux Syslog server alternative using vMA 5.0
You can actually leverage the existing syslog server on the latest vMA 5 release and with a few customization, get it setup to start collecting logs from your ESX(i) hosts as before with vi-logger.

Step 1 - It is recommend that you configure an additional disk on vMA for your syslogs as the size of vMA is quite tiny for additional use. I will assume that you know how to add and configure an additional disk, if not you can do a simple search on Google. In this example, I have a second disk that is 10GB and it is mounted up under /var/log/remote which is where the ESX(i) logs will be stored in.

Step 2 - You will need to edit the syslog configuration under /etc/syslog-ng/syslog-ng.conf and you will need to add three entries. The first addition is to configure the source for log messages from the network and enabling both udp/tcp on port 514, you may add the following under the default "src" entry.

source network {
udp6( port(514) );
tcp6( port(514) );
};

The next two entries will define the destination and how it'll log. You will add the following at the end of the syslog-ng.conf configuration file.

destination log_remote {
file("/var/log/remote/$HOST_FROM/$YEAR-$MONTH/messages-$YEAR-$MONTH-$DAY"
create_dirs(yes) frac-digits(3)
template("$ISODATE $PROGRAM $MSGONLY\n")
template_escape(no)
);
};
log {
source(network);
destination(log_remote);
};

The "log_remote" destination will send all logs from your ESX(i) hosts into /var/log/remote and will have the following format: $HOST_FROM/$YEAR-$MONTH/messages-$YEAR-$MONTH-$DAY

Step 3 -  Now you will need to restart the syslog server for the changes to take effect. You will need to run the following command: sudo /etc/init.d/syslog restart

If everything went successful, you should now be able to configure your ESX(i) hosts to point to your vMA 5 system and you should see logs appearing under /var/log/remote

Note: You will need to use sudo to view the directory under /var/log/remote and to view the logs

Windows Syslog server alternative using vCenter Syslog Collector
The vCenter Syslog Collector can be installed and used without the use of vCenter, you can easily turn any existing or new Windows system into a syslog server for your ESX(i) hosts for free.

Step 1 -  It is recommend that you configure a seperate disk on the Windows system that you are going to be using for your syslog server. I will assume that you know how to add and configure an additional disk, if not you can do a simple search on Google. In this example, I have a second disk that is 10GB and listed as Syslog (E: drive)

Step 2 - You will need access to the vCenter Server 5.0 installation ISO or executable to install the Syslog Collector utility. Start the installer and select and install VMware Syslog Collector

Step 3 - You have the option of using the local C:\ drive, but I would recommend setting up a separate drive if you can. If you decide to change the default log location, you need to ensure that you specify the following directory structure VMware\VMware Syslog Collector\Data else you will run into issues with the installation. In this example, I have moved my logs into E:\ drive and the path looks like the following: E:\VMware\VMware Syslog Collector\Data. You also have the ability to change the size of the log files before rotation and the number of logs before rotating.

Step 4 - If you are installing the Syslog Collector on the same host as vCenter Server, you should select the integrated installation else you should select a standalone installation.

Step 5 - The next screen will be the default ports to enable for both TCP/UDP and SSL which can be configured or left as the default as recommend.

Step 6 - The screen is how the Syslog Collector will be identified on the network and it should just be the IP Address of the host.

If everything went successful, you should now be able to configure your ESX(i) hosts to point to your Windows Syslog Collector system and you should see logs appearing under E:\VMware\VMware Syslog Collector\Data

As you can see even with vi-logger being removed in the latest version of vMA 5, you can easily still configure a free syslog server with your ESX(i) hosts on either a Linux or Windows platform.

Categories // Uncategorized Tags // ESXi 5.0, syslog, vilogger, vma, vMA5, vSphere 5.0

ESXi syslog caveat

06.24.2010 by William Lam // 5 Comments

There are two easy methods of capturing logs for both an ESX or ESXi server:

  1. Use VMware vMA and vilogger to setup a syslog server. Simon Long wrote a very detailed article on how to configured and set it all up, check it out here.
  2. Configure ESX or ESXi server to remotely log to an existing syslog server.

In ESXi, there are potentially three sets of logs to be captured: messages, hostd, and vpxa (if your host is being managed by vCenter). If you are using option #1 and you have enabled logging using vilogger, you will see the following:

[Read more...]

Categories // Uncategorized Tags // syslog, vpxa

  • « Previous Page
  • 1
  • …
  • 5
  • 6
  • 7
  • 8
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025