Sweep up my SAS logs

[#1]

In doing research for the troubleshooting section of a new workshop I am working on, I ran into a very useful tool that I was not aware of. A quick poll of my GEL administration team colleagues revealed I was not alone. I am guessing there may be many of you have not heard of the "LogConfigSweeper tool for automated log and configuration data collection". The LogConfigSweeper tool is an automated Java based tool that enables you to collect SAS server log and configuration files to a central location.

When you run into problems in a SAS deployment the log and configuration files become very important. To diagnose and fix a problem you often need log files from multiple server types. In a typical SAS configuration the log files for a SAS server are stored within the configuration directory of the server. For example, on an application server tier, Object Spawner logs would be stored in a logs directory within the ObjectSpawnerDirectory (<config>\Lev1\ObjectSpawner\Logs). Similarly, Workspace Server logs would be stored in a separate directory, for example <config>\Lev1\SASpp\WorkspaceServer\Logs. The result is that log files are not in one central location but distributed in a number of directories throughout the configuration directory.

The LogConfigSweeper tool helps you centralize the logs(and configuration files) making them easier to find and read, and also zips them up so that you could easily send them to SAS Technical Support. The tool only works for SAS 9.4 deployments. The tools installation, configuration and usage is described in this SASNOTE. The tool runs on windows and Linux and is pretty simple to get working. Download the zip file and unzip the files it to the directory <SAS-configuration-directory>\Lev1\.  When you unzip it three files will be added to the directory logconfigsweeper.jar, LogConfigSweeper.bat and LogConfigSweeper.sh. In Windows you can now run the tool, in a Unix environment you will have to make the .sh script executable.

In a multiple machine environment you will have to install the tool on each machine, or in a location that is accessible to each machine. The tool will not gather server logs and configuration files from all machines, only for the servers defined in the configuration directory of the machine it is run on. To get all log files you have to run it on each machine in the deployment. You must pass the tool parameter(s) which tell the tool what log and configuration files to collect, and also the -output option which tells the tool where to store its output. Let's look at an example. The command below tells the tool to collect logs and configuration files for the ObjectSpawner and Workspace server and store them in the d:\Logtooloutput directory.

 

When the tool runs it will write out messages to the terminal window.

When the tools is done it will have created, within the output directory specified, a new directory named with date-time that the tool ran. Within that directory are zip files contain the logs and configuration files for, in this case, the workspace server and the object spawner.

This tool can really help with one of the manual tasks involved in trouble-shooting issues within a SAS Deployment. It could also potentially be used as part of a log archiving process. There are a wide variety of options you can pass, including on the middle-tier "all" which collects all SAS 9.4 middle-tier logs as well as configuration files, "evmanager" which collects SAS 9.4 Environment Manager Server and Agent logs as well as configuration files and on the Metadata Server "metadataserver" to collect Metadata Server logs as well as configuration files. Check out the SASNote "Using the LogConfigSweeper tool for automated log and configuration data collection for SAS® 9.4 Ser..." for more details.

[JuanS_OCS]

Hello @GerryNelson,

I consider this tool really useful. I would like to ask you a question:

By following your instructions, and dropping the files in Config/Lev1/Web/Utilities, the first problem is that the tool cannot find the level_env.bat/sh file. You can quickly workaround it by modifying the call to level_env file... but the second problem is that, even after that, the tool won;t know the locations for the log files. 

So far, the tool only works if you place it as the SAS Note 54813 http://support.sas.com/kb/54/813.html describes, directly under Config/Lev1

I would love to know more details about being able to put the files in different locations, as you describe. Could you please share?

Thank you in advance!

Kind regards,

Juan

[GerryNelson]

@JuanS_OCS it appears that the tool has changed since I posted this article. As you note, you have to follow the instructions in the SASNOTE to get the tool to work. The three files for the tool should now be installed directly in the Lev1 directory. I will update the article to match the SASNOTE. Sorry for the confusion.

[JuanS_OCS]

Hi @GerryNelson,

many thanks for coming back to it, appreciated. And no need to be sorry, this clarifies everything!

[JuanS_OCS]

Hello @GerryNelson ,

I would like to ask you a couple of questions, towards its usage in a more complex deployment, such a SAS Grid.

Has this tool got any option to configure non-default log folder locations, non standard names (such as "Object Spawner A" or "SASAppUTF8")?

I remember you mentioned to have requested these kind of features in other threads in the SAS Communities. Is there any update?

I can see still:

- empty zip files (although it says successful creation)

- files actually that occupy 1 MB but empty when I open them (although it says successful creation)

- ERROR! Collecting the log and config files: java.lang.NullPointerException - not very descriptive, perhaps an option to see the trace of the java error might help. When this happens, it is not checking for the next components listed.

- Besides archiving, can the tool clean as well unused (not open) log files? It would be great if there is a flag to activate such option.

Is there any update on progress or actions to be taken to optimize the tool?

I see a great advantage on continuing the development of this tool.