BookmarkSubscribeRSS Feed
Edmundov
Calcite | Level 5

Our department has created various dashboards.  We've been asked to see if there is a way to see how much usage the dashboards are getting.  Also, is there a way to tell what users are logging in to view the dashboards?

 

We know how many users have been granted access, but we want actual numbers on the usage.

 

I've looked at the knowledge base plus also at various log files, but so far no luck.

 

We are on SAS 9.2.

 

Thanks...Mundo

7 REPLIES 7
Quentin
Super User
How are the dashboards produced, i.e. BI Dashboard, BI stored process, WRS, VA, or ...?
BASUG is hosting free webinars Next up: Jane Eslinger presenting PROC REPORT and the ODS EXCEL destination on Mar 27 at noon ET. Register now at the Boston Area SAS Users Group event page: https://www.basug.org/events.
Edmundov
Calcite | Level 5

Directly from our developers:

 

"We use BI Dashboard 4.3.  For drilling down on indicators, we set up our links as stored processes that open in a new window."

 

Mundo

Quentin
Super User

I don't know BI Dashboard.  But would suggest this related thread which explains different approaches for processing logs, I would think Dashboard usage would show up in some of this logging data discussed:

https://communities.sas.com/t5/Administration-and-Deployment/RE-How-to-track-who-accessed-what-table...

Also references this nifty paper:

http://support.sas.com/resources/papers/proceedings14/1247-2014.pdf

 

Honestly I haven't explored this logging much (I'm not an admin).  As a developer, for some home-grown logging of the usage of stored processes I wrote, I soemtimes have the stored process write append a record to a permanent log dataset each time the stored process is called, storing the name of the user, parameters passed, and some other info.  It's a quick and dirty way for me to keep track of who is using them, how often, etc.

BASUG is hosting free webinars Next up: Jane Eslinger presenting PROC REPORT and the ODS EXCEL destination on Mar 27 at noon ET. Register now at the Boston Area SAS Users Group event page: https://www.basug.org/events.
MichelleHomes
Meteorite | Level 14

Thanks @Quentin for mentioning @TriciaAanderud and my "nifty" paper Smiley Happy

 

@Edmundov - here is a link to the Audit, Performance and Measurement package that collects the data that you are after from the ARM log files. The package is very useful as it has some predefined SAS code that you can further customise. https://support.sas.com/rnd/emi/APM94/index.html With the release of SAS 9.4 and Environment Manager, this is now not available as a download and I'd suggest you contact SAS Technical Support.

 

Kind Regards,

Michelle

//Contact me to learn how Metacoda software can help keep your SAS platform secure - https://www.metacoda.com
Edmundov
Calcite | Level 5

I want to thank everyone for your suggestions.  The current log files don't appear to gather the information we're looking for so we might wait until we upgrade to 9.4 to see what our options are.

 

Thanks again.

 

Mundo

ronan
Lapis Lazuli | Level 10

On 9.2, as mentioned by Quentin you can try to install the APM kit thus enabling audit reports. I am not sure this tool also covers Dashboard usage : let's hope it does ! If not, then I'll suggest three workarounds :

 

  1. locate the Dashboard log file(s) ( probably : <MidTier Server SASCFG>/Levn/Web/logs  with backslash on Windows)  and code or re-use some parsing SAS scripts that retrieves the relevant information - if this information is logged at all ! Then with a Stored Process or even Infomap/WRS you'll be able to create the reporting you need

2. As suggested below, try setting up a dedicated log file(s) using Log4SAS API in order to record the information (if 1. doestn't provide it already) and add a parsing script in the same manner as 1.

 

3. [more burdensome but effective if done properly] for each Dashboard  add a small invisible Stored Process  that records each access by creating an empty flag file named accordingly, like <MetataData Session or instance PID>_<account>_<Dashboard name>_<etc.>_<STP PID>_<TimeStamp>.log. Then with a small SAS script, you collect every now and then the flags and loads the information into some SAS tables etc. The STP code doesn't change, it is a small macro program that prints the macro parameters into a filename on a specific folder.

You'll have to set a systematic naming rule for each Dashboard if you try to set up this, it helps.

 

 

 

 

 

 

 

boemskats
Lapis Lazuli | Level 10

I was going to suggest something very similar to @ronan, but even simpler. You do not need to wait for 9.4 and you do not need to change any of your stored process code.

 

 

In your STP autoexec_usermods, issue a libname statement and define a dataset somewhere called auditlib.stp_&syshostname._&sysjobid., defining the variables you want to collect for each stored process execution. Something like this should work:

 

libname audits "/some/storage/somewhere";

data audits.stp_&syshostname._&sysjobid.; length a_username a_programname a_someparam $100; length a_timestamp 8; run;

 

Make sure that you use a hostname/pid reference in your table so that you avoid multiple processes trying to lock the same sas table. 

 

 

Then, in Management Console, within the metadata config for your stored process server context, you can define a SAS program that runs and appends the parameters you're after to your audit table that you just initialised in your stp autoexec_usermods, before each requestThis page also shows you how to alter this per-request metadata config:

 

initprogram.PNG

 

 Something like this will do for your initialisation program:

 


data appendme;
  length a_username a_programname a_someparam $100;
  length a_timestamp 8;
  a_username="&_METAUSER";
  a_programname="&_PROGRAM";
  a_someparam="any specific identifier that you pass to your stps";
  a_timestamp=datetime();
  output;
run;
  
proc append data=audits.stp_&syshostname._&sysjobid. base=appendme; 
run;

 

Whenever you want to run your audit reports, you can create a unifying view of all of your audit tables (one for each session). This will give you what you want, is much easier than installing APM, and with far less performance overhead. If you create an overarching view, you can even create a dashboard to report on this stuff in real time.

 

HTH

Nik

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 7 replies
  • 1413 views
  • 4 likes
  • 5 in conversation