Using ALTLOG with SAS EG and Studio, in Grid

[brendanodwyer]

I have a requirement to set the alt log so that we retain a complete copy of anything running in and on the Grid. Including everything that EG or SAS Studio Executes.

I have tried setting it in a few places and every time I set it and try to launch a workspace server via grid, the whole infrastructure just dies. Have to reboot everything.

I do have a wrapper script that does set it when I use the SAS Grid Client Utility.

[Kurt_Bremser]

What exactly have you tried already that caused the freezes?

(which files were changed, what options were set etc)

[brendanodwyer]

We have tried to inject the parameter before the sas command that gets executed on SAS EG Launch. We also tried to put it in !SASROOT/sasv9.cfg and !SASROOT/sasv9_local.cfg. Both dont seem to work when we tried to have it launch EG and connect into the Grid, which as I understand it is when the Workspace Server is being launched by the GRID.

[SASKiwi]

I'm curious to know what the purpose is of trying to collect all SAS session logs? If it is for tracking what products and procedures are being run then this can be done more easily using SAS Environment Manager monitoring and the same tool is good for performance monitoring too.

[brendanodwyer]

We have an Audit, Compliance, and Regulatory requirement to begin tracking, quite literally, everything in our SAS Environment that is running. The Requirement is more granular than aggregates surrounding PROC's and SAS Products, that we do have and get from Environment Manager.

[anja]

Hi,

I am almost certain that the freeze is caused by the ALTLOG option that's being enabled for your environment.

Do you have the Workspace Server log enabled?

Especially the Workspace Server might cause problems as it writes a single log for each user. Given that, plus an option to "copy" a dup of logs somewhere, might be too much for the resources you have, the resources SAS uses.

Going in the opposite direction, if the ALTLOG is set up for the SAS Servers, yet the Workspace Server log is not enabled, it might run

indefinitely, trying to find the Workspace Server log. Other log files are enabled per default, which is why I am highlighting the WS log.

As mentioned in a post earlier, one way to go would be using the Environment Manager:

What is Environment Manager:

http://support.sas.com/documentation/cdl/en/evug/69029/HTML/default/viewer.htm#n1vpa7fca7lm6xn1193gv...

Using the Report Center:

http://support.sas.com/documentation/cdl/en/evug/69029/HTML/default/viewer.htm#n0icicjjqba5khn17he8i...

Take a look at the reporting, one of the features provided by Environment Manager, to see which objects, items and resources you can

report on, and monitor. It is a great tool!

There is an Ask the Expert recording and upcoming sessions for Environment Manager,

see http://support.sas.com/training/askexpert.html, under Administration.

Aside from Env Manager, here is a blog that talks about logging events

http://blogs.sas.com/content/sgf/2015/09/30/part-1-auditing-data-access-who-did-what-and-when/

Hope this helps.

Thanks

Anja

[brendanodwyer]

So our workspace servers are grid launched, and the logs are enabled, we havent turned on TRACE yet but that is my next step to see what TRACE will tell us, but in the standard logging configuration we havent been able to see that the workspace server was even launched. We get this error in EG

[Error] Failed to start the server.
[Error] The launch of server SASApp - Workspace Server for user <XXXXXX> failed.

[anja]

Do you get this error when logging on, or, when users submit jobs? Does that happen for every user?

Could you provide a screenshot of this error message? Also, did you check the Metadata Server log and Object Spawner

log? There is most likely more info that'll help to troubleshoot.

Did you run into these problems before using the ALTLOG option, meaning, did this ever work before?

Also, are you on 9.4, and, would Environment Manager be an option? It would nicely provide what you are looking for.

[brendanodwyer]

We found an alternate solution that allows us to collect the logs on a permanent basis. Thank you for the assistance.

[anja]

Hi,

would you mind sharing what you used to get the info you needed?

Thanks bunches!

Anja

[brendanodwyer]

We are using SASV9_OPTIONS to make sure that altlog is recorded across the Grid environment. Since this option is set in UNIX/LINUX we can make sure we have what we need to make the log collision proof accross the cluster.

Since some sessions are logged and others arent under Grid-Launched Workspace Servers using -ALTLOG we are using the Environment Manager Postgres instance to our advantage to record and reconcile instances of each type of session so that we can track what is being done in the environement at all times.

The default sas executable at !SASROOT/sas has been modified to accomodate these changes and log all uses of that executable.

[SASKiwi]

Good to see you found a solution.

Personally I think your audit requirement is way over the top. I can understand doing this for business-critical processes but for every SAS job?! I guess you are now going to have fun managing potentially hundreds of SAS log files being generated each day...I hope you don't have to analyse all these.

[brendanodwyer]

We have Python code that reassembles the SAS code and does analysis on what it is doing. We previoulsy used a similar situation to parse our RTrace logs in an old environment.

As far as management is concerned, the logs are centrally located and reconciled to our Hadoop environment so that we can catalog and parse them at will. The high compression ratio of the logs has made them extremely easy to store and rextract into files that the Python code can then mine.