• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Best Practice for ESXi Syslog

K

KapsZ28

2[H]4U
Joined
May 29, 2009
Messages
2,114
I don't want to use syslog built into vCenter anymore. I would rather just have the logs reside on one of the datastores. I also want to use a kickstart script for setting up the syslog location during the install. One of the examples I was looking at I believe modified the Syslog.global.logDir field in Advanced Settings during the install. I have done this manually before too, but I am wondering about the folder within the datastore that syslog points to. Does each server have to point to its own specific directory so that the log files are not overwritten by another host? When I set it up manually, I created folders such as ESXi01, ESXi02, and pointed each host to a separate folder. If I am using a kickstart script, I am guessing that each server would point to the exact same directory? Is that an issue, or will it create a subdirectory for each server automatically?

I noticed another method where you leave syslog pointing to "[] /scratch/log" but then you update the ScratchConfig to point to a different datastore rather than the local one. Is there a preferred method? Either updating syslog verse the scratch directory?

Keep in mind I would really like to be able to add this to a kickstart script so everything is done during the install.
 
you can trigger a uniqueDir option to have each host create a folder (named for the host) in the directory, eg:

[Datastore]/LOG FOLDER/HOSTNAME

You're doing it right with the first option, just set the second flag too in order to keep it sane.
 
Cool, thanks. The first option was really the one that I had known. Just so happen to be looking at someone else's work today and saw they did it the other way and was curious. Although I should have known better as most of the other configurations I saw this person do were definitely not what I would have done including the VMs.

He has two Exchange 2013 servers setup in DAG. They both run on a separate HP blade. Each blade has 2x 8 core CPUs with hyperthreading and each Exchange server has 24 vCPU assigned to it. I only briefly looked, but CPU usage wasn't high, but either way, 24 cores... Plus 64 GB of memory allocated to each VM. Seems a bit excessive for 1,800 mailboxes. Plus I would have at least separated the CAS and Mailbox roles on to separate VMs.
 
lopoetve said:
you can trigger a uniqueDir option to have each host create a folder (named for the host) in the directory, eg:

[Datastore]/LOG FOLDER/HOSTNAME

You're doing it right with the first option, just set the second flag too in order to keep it sane.
Click to expand...

This.

But the biggest question is how will you review historic logs if you are troubleshooting a SAN issue and all of your logs are stored on that shared (SAN/NFS) storage?

I've been debating the pro's and con's of local vs. shared for awhile. Best option may be using a SysLog server in conjunction with one of the others.
 
KapsZ28 said:
Cool, thanks. The first option was really the one that I had known. Just so happen to be looking at someone else's work today and saw they did it the other way and was curious. Although I should have known better as most of the other configurations I saw this person do were definitely not what I would have done including the VMs.

He has two Exchange 2013 servers setup in DAG. They both run on a separate HP blade. Each blade has 2x 8 core CPUs with hyperthreading and each Exchange server has 24 vCPU assigned to it. I only briefly looked, but CPU usage wasn't high, but either way, 24 cores... Plus 64 GB of memory allocated to each VM. Seems a bit excessive for 1,800 mailboxes. Plus I would have at least separated the CAS and Mailbox roles on to separate VMs.
Click to expand...

That's insane.
REDYOUCH said:
This.

But the biggest question is how will you review historic logs if you are troubleshooting a SAN issue and all of your logs are stored on that shared (SAN/NFS) storage?

I've been debating the pro's and con's of local vs. shared for awhile. Best option may be using a SysLog server in conjunction with one of the others.
Click to expand...
A VERY valid point. Syslog ftw.
 
lopoetve said:
That's insane.
A VERY valid point. Syslog ftw.
Click to expand...

Yeah, if you dont have syslog server already just setup a quick ELK stack and send em there. Definitely the recommended path.
 
4saken said:
Yeah, if you dont have syslog server already just setup a quick ELK stack and send em there. Definitely the recommended path.
Click to expand...

any good links or articles to read on how to use these to deal with the logs? searching etc


thanks

Alex
 
The issue I had with syslog happened twice to me. I was syslogging to the vCenter server running on Windows. One of the ESXi hosts stopped communicating via syslog, and was logging thousands of events per day that it could not communicate with syslog. My fault for not noticing, but it didn't trigger any real alerts until the vCenter database was out of space. This happened or two locations but both were sysloging to be same vCenter server.

Is it better to setup a Linux syslog server? Has anyone else had this issue before?
 
kalex1114 said:
any good links or articles to read on how to use these to deal with the logs? searching etc


thanks

Alex
Click to expand...

I dont, but if you are familiar with json format you can do some really awesome dashboards and queries. It's worth spending the time to learn it. Very powerful tool.
 
You must log in or register to reply here.
Back
Top