SAS administrators are faced with multiple challenges in order to keep SAS environments running optimally. In an ideal world, an administrator would only need to focus on maintaining a healthy environment through standard best practices. Unfortunately, the reality is that things can and do go wrong.
At this point, everyone looks to the SAS admin and in turn, we look to our best friends, the multitude of logs that are created by the SAS platform. Once you open the log file, you can begin with the basics of searching for ‘ERRORS’ to get your troubleshooting going. While the default logging levels provide a substantial amount of information, we also have the ability to modify these levels to adjust the amount of information gathered in SAS logs.
When it comes to troubleshooting, the logs that you seek out will ultimately be the ones most relevant to your current issue. I can’t sit here and point you to a golden log that will solve all your problems, but what I did want to go over are a few important ones that can be critical to a properly running environment. Note that the log paths listed will be for Windows environments.
Metadata server log
The metadata server is where it all begins. It allows a centralized location for storing data used by the various SAS applications as well as users and groups and their access levels to the system. It is the most critical part of the SAS platform, so it is only natural that we want to start with the Metadata server and confirm it is up and running without errors. We can find the Metadata log in the following path:
- Configuration-directory\SASMeta\MetadataServer\Logs
Two examples when you would seek out these particular logs are if the Metadata server failed to start or when a user is continually being prompted for credentials, which leads to authentication errors. If the logs are not providing enough information, you can now adjust logging levels by following this SAS note: https://support.sas.com/kb/51/911.html
When it comes to logs, one aspect to be aware of when changing logging levels is that while you gain the benefit of additional information, it also comes at a cost. The cost, in this case, would be your disk space and some performance from the webapps themselves. Make sure to return your logs to their previous levels after resolving your issues.
Object Spawner
Next in line is the Object Spawner. When a user runs code, whether it be through Enterprise Guide or SASStudio, the Object Spawner is responsible for listening for the request and then launching a server; be it a workspace server, pooled workspace server or stored process. In order for the spawner to get the server definitions, it must first access the metadata config file which specifies the information needed to connect to the Metadata Server. The default location for the Object Spawner log in a Windows environment is as follows:
-
sas-configuration-directory\ObjectSpawner\logs
If you find yourself seeking out these logs for troubleshooting, be sure you are looking at the correct log file, depending on your current issue, as you have two types (initialization log and rolling log) that are easily identifiable if you know what to look for.
Looking at Figure 1, items 1 and 2 are considered the ‘Initialization’ log and contain relevant information or errors with regards to the launching of the Object Spawner. Item 3 is considered the ‘Rolling’ log, as they continue the log from the spawner, noted by the same process ID 14256 as the previous day. You may look in the rolling file log if a workspace server fails to validate.
SASLogon9.4
We now move onto logs produced by SAS’s Web Application logon manager. Any time you try to access a web application within SAS, you will be directed to a universal logon page that handles the authentication request for web applications. After successfully authenticating, a user can access all SAS web apps for which they have the permissions.
- sas-configuration-directory\Lev1\Web\Logs\SASServer1_1\SASLogon9.4.log
The errors that you see in the SASLogon9.4 file don’t have to do with failed log-in attempts when trying to get onto your web app with a wrong username or password. Rather it will address problems with sign-in mechanisms being used like Windows SSPI or third-party single sign-on products, such as PAM authentication in Linux. Also, be aware that the SAS Logon Manager only works for the services registered in Metadata Server.
Logs aren’t always about the errors
You can use the logs to gather general information such as, “which user signed into Enterprise Guide?”, by looking at the SAS Metadata Server log or “Is the Web Application Server instance up?” via the server.log in Web\WebAppServer\SASServer1_1\log directory, by looking for ‘Server startup in ….ms’. Linux makes it easier to keep an eye on this using the tail -f command to see real-time changes to the file.
Lastly, regular clean-up of log files is recommended in order to keep fresh, up-to-date logs. This means either deleting old logs or compressing and archiving for auditing purposes. When it comes to the cumulative logs, it will allow easier discovery of pertinent information without having a file with months of data. You can write your own scripts to automate the clean-up but be careful not to clean logs while SAS services are running and files are still in use by SAS. Linux environments allow you to use the logrotate utility to manage log rollover, compression and removal of older rotated files.
SAS logs can get overwhelming, but with time and experience, knowing which log to pursue based on the symptoms becomes easier and allows for a SAS admin to quickly diagnose and resolve issues that they may encounter.