Monitoring Reporting Usage by User / App / Date / Space etc.

[110]

While there's a lot of detail available in the back end and in monitoring apps to see entitlement / capacity usage across apps/spaces and users, there's not much by way of tracking usage of reporting.

Is it possible to extract this data from logs / api  in order to understand the  'Reports generated (monthly)' number? 

We've had a higher than usual number of Reports run this month, which has then hit the hard limit and halted all reporting. 

Ideally it'd be great to be able to pin down what was different this month vs last - as upon review, there's nothing out of the ordinary running beyond what we had running last month.

[Andrew_Kruger · Accepted solution]

Hey @110 , you might reference this post https://community.qlik.com/t5/Support-Updates/Reporting-Service-Packaging-Changes/ba-p/2436638 on the evolution of the Qlik Reporting Service.  The feature level help documentation is here.  More recently the limits in place are being enforced. You will see the aggregate count of report usage on the landing page of the Management Console / Administration. 

There is activity to surface better visibility of report execution history as you are looking for.  Stay tuned.  

In the mean time Report (file) production events are found by filtering within the Management Console > Events on the Event Type = com.qlik.v1.reporting-service.audit. 

Within those events you will be looking for TemplateType = Composition-1.0 or sense-excel-template-1.0.  Depending on what reporting use cases are in use:

• Composition-1.0 events will have a Tag = automation.execution or public.api - you can ignore that subscription.execution events 
• The Sense-excel-template-1.0 events could have a few Tags including reporttask.execution, excel-addin.download, Public.api, sense-ondemand.download

Hope that helps.

[JonnyPoole]

I am working on a app prototype for this. Feel free to message me directly in community and if you are willing to provide feedback, I can send you a copy to test out. 

[110]

Thanks @Andrew_Kruger   -  the first we knew about the reporting limit enforcement was when the service just stopped, which caused a fair bit of confusion and frustration.  I think with sufficient lead time we could have turned off some reporting sooner rather than run out the allocation.

I'll have a read through the documentation - we had intended to do more with Tabular reporting but will have to be more selective in what we run.  

One suggestion would be to perhaps have capacity be time based, so running extracts/reports out of hours ( i,e, running after 10am )  consumes less capacity than running at peak times.

@JonnyPoole  -  this sounds fantastic, please do count me in for any Beta testing .  The open source monitoring apps have been very useful to gain some insight without having to delve too much into the logs / apis.

Visualization wise  -  it'd be useful to see breakdowns by what/who/when similar to below  ( a sheet I added to the Reload Analyzer )  - we've been able to see issues with concurrency , long running loads etc., peak times etc.