I’m a big fan of log files. When it comes to resolving an issue for a single end user to correcting a system-wide problem with an application, the first thing I like to do is take a quick peek at the log files. However, I do run into a fair amount of situations where I’ve been called in to troubleshoot a system that I’m not a user or custodian for, and the log file locations have not been documented. In these situations a quick root cause analysis can pose a little challenge.On Linux systems, a quick check at /var/log is usually a good start, if that fails then grep of the /etc/<appname>/<configuration-file> for “log*” works very reliably. On windows systems, it’s a totally different story. There might be a standard location for logfiles on Windows in APPDATA, ProgramData, the event viewer, or the registry…but I’m not aware of any, The quickest thing that I’ve discovered for network logs is using “Wireshark”. When troubleshooting standard network application protocols like SMTP, SMB/CIFS, SFTP, HTTP(S), or TCP/IP… Wireshark or TCPDump can quickly reveal the root cause of a problem with a test transaction. If the application fails to complete the transaction (whether the application tells you explicitly or not), Wireshark will give you a detailed breakdown of what happened on the wire and the protocol “logs” often report failures in a more detailed manner, allowing you to quickly trace the problem and implement the appropriate remediation. For instance, recently I was brought in to assist with what turned out to be an SMTP issue. I setup a Wireshark sniffer and within 15 minutes of testing we were able to determine to root cause of the issue and put a fix in place to allow the business to continue operations affected by this issue. For other, non-standard applications that do not leave logs in the event viewer or obvious locations in Windows, I’ve found that the “resource monitor” offers great value in tracking down relevant log file locations for analysis. The resource monitor can be activated with the following keyboard combination:
Win+R “resmon” <enter>
Once the resource monitor is open, click on the the “Disk” tab and you can see the Windows processes that are “touching” the disk, and if a log file is being written to the disk, you can filter the process that would be writing the log file by selecting the checkbox and determine the location on the “Disk Activity” section of the “Disk” tab.
In my experience…on a Linux machine you can usually determine the log file location from the configuration file or by checking /var/log, and in a Windows environment you can use “Wireshark” to quickly get to the bottom of network application issues (it’s usually the firewall), and Resource Monitor to find the application log file (if a logfile is being updated) and then trace the issue using the application’s proprietary log file.
Hope this helps..