Architecting, installing and maintaining your SAS environment

Check the Health of SAS Web report studio application

Reply
Contributor
Posts: 33

Check the Health of SAS Web report studio application

Hello,

 

We manage SAS 9.3 on a Grid environment. We have SAS Web Report Studio running Weblogic server.

At times, we have the WRS application going down due to:

1)hanged weblogic services

2)hanged SAS services on any of the grid nodes

 

Is there any way to check the health of WRS and get an alert

1) if WRS is accessible

2) run a report in it and to ascertain its succesfully rendered output.

 

Kindly help.

 

Cheers

Mark.

Trusted Advisor
Posts: 1,756

Re: Check the Health of SAS Web report studio application

[ Edited ]
Posted in reply to MarkNicholas

Hello @MarkNicholas,

 

very good question.

 

While I normally would monitor the services and logs, I also understand you would like to monitor the user experience.

 

For that, your best choice would be to set a monitor on a specific URL and create alerts on return codes.

Your company probably has got already a good monitoring tool. Once you create your report, you will need to provide that team with the URL to monitor. They will name it as web page monitoring or URL monitoring.

 

The web monitoring can be a bit tricky, sometimes, since you will need to log on to the application, or either allow guest/anonymous access to the web applications and release that report for anonymous/guest. And, if you have Single Sign On, you will need to log on with a fallback URL to be able to log on, which can be really tricky sometimes and you might need to monitor different return codes (i.e, when code 200 is normally success, for SSO the "success" might well be a 304).

 

If you have a web development department, they will be a really great help for your objective, since you will have the perfect support in-house.

 

General enterprise-level tools:

https://webapplicationmonitoring.net/

https://www.nagios.com/solutions/web-application-monitoring/

https://stackify.com/web-performance-monitoring-guide-developers/

https://www.dynatrace.com/topics/application-monitoring/web-application-monitoring-tools/ (dynatrace, expensive but absolutetly 4x4 for monitoring things)

 

Linux command-line options:

https://www.ostechnix.com/easy-way-monitor-website-command-line-linux/

 

Microsoft tool:

https://docs.microsoft.com/en-us/azure/application-insights/app-insights-web-monitor-performance

https://technet.microsoft.com/en-us/library/dn465157(v=sc.12).aspx

 

Windows command-line:

https://www.coretechnologies.com/products/http-ping/

 

Also, if there is any doubt, perhaps you can give a look to cURL, available on Windows and Linux. Simple and flexible.

 

Finally, if you upgrade SAS to 9.4, it already brings a monitoring tool, SAS Environment Manager, an adaptation of Hyperic, a VMWare product to monitor resources and services. And it has capabilities to monitor web/URL as well.

 

 

Contributor
Posts: 33

Re: Check the Health of SAS Web report studio application

Posted in reply to JuanS_OCS

Thank you @JuanS_OCS for your quick response. I will initially work with our monitoring team to develop this idea further.

 

-Mark

Frequent Contributor
Posts: 133

Re: Check the Health of SAS Web report studio application

Posted in reply to MarkNicholas

Hi Mark,

 

To add to Juan's excellent response, here's something that may also interest you. If nothing else, the Python code in our project might help your engineers build a WRS ping routine into whatever monitoring application you use at the moment.

 

A while ago we built a Python app that uses the Python Requests library to traverse the SASLogon application and log on to WRS/STP/Portal/VA, effectively emulating the behaviour of an end user as if they had just attempted to log on to the application and view a report. You can find it on GitHub here.

 

The way it works is:
- a Python collector script logs on to SAS via HTTP (traversing the SASLogon redirect bits and collecting cookies), and then makes whatever subsequent HTTP requests it needs to and feeds a .csv file with the results and timings of those requests (with the .csv being symlinked to from your webroot, see below)
- a D3 based static webapp is served from in your htdocs folder for users to view system availability metrics (the static html app perioducally pulls the .csv data in via ajax. It's static so that it operates independently of your JVM)
- a Python 'aggregator' script periodically summarises that data for the historical overviews and produces 3 more csvs that are loaded in in a similar fashion.

While the web application itself might not be of particular use to you, you could use the python components to pull availability data in periodically. You'd have a config of something like this:

 

 

{
"hostUrl": "https://apps.boemskats.com/",      
  "loginPath": "/SASLogon/login",
  "loginParams": {
    "username": "sasdemo",
    "password": "Orion123"
  },
  "applications": [{
    "name": "SAS Web Report Studio",
    "tests": [{
      "id": "id1",
      "type": "stored_process",
      "execPath": "/SASWebReportStudio/do",
      "execParams": {
        "something": "something"
      },
      "validations": {"mustContain": ["abitofyourreport"], "cantContain": ["ERROR:"]}
    }]
  }]
}

 

(It's been a while since I used WRS, but the idea would be to identify a HTTP call that the app makes to the server JVM, and decide what regexes it must match to be a 'successful' call, and what it can't contain)

 

It's worth noting that when we started building ESM for SAS, identifying the root causes of Web Report Studio instability was pretty high on our agenda. This is why we still monitor both the pooled workspace sessions and the JVMs very closely (in real time), so that we can spot the moment where it all start to overload and reconcile it with a particular user/report/infomap. There are always a couple of reports that cause instability with WRS, and identifying these means you can take preventative measures. If you're interested feel free to drop me a line.

 

Lastly lastly, (and @JuanS_OCS this will interest you), just this week we started rolling with a custom module architecture for ESM that lets us use python modules such as the collector script above to collect real-time application availability event data straight into ESM. This will feed directly into our alerting architecture, so it is huge for us. I can't help but share Smiley Happy 

 

 

Nik

Ask a Question
Discussion stats
  • 3 replies
  • 242 views
  • 5 likes
  • 3 in conversation