Support Updates Blog

[Jamie_Gregory]

Hello Qlik Users! 

“How can I monitor reloads across the tenant?” 

“How can I see what data connections and files are being used?” 

 “How can I view reload concurrency and peak reload RAM over time?” 

These are a few of the questions we frequently hear. To enable you to find better answers for those, we are happy to share with you the new Reload Analyzer for Qlik SaaS! 

The Reload Analyzer will help answer those questions and more! The app provides insights on: 

• Number of reloads by type (Scheduled, Hub, In App, API) and by user 
• Data connections and used files of each app’s most recent reload 

• Reload concurrency and peak reload RAM 
• Reload tasks and their respective statuses 
• And much more! 

(Available sheets) 

The Reload Analyzer uses Qlik’s RESTful APIs to fetch all the required data and stores the history in QVD files, allowing for efficient reloads and historical analysis. 

A few things to note: 

• This app is provided as-is and is not supported by Qlik Support. 

• This app leverages an undocumented API (reload-tasks) that is experimental, and relies on the users API, which is also experimental. 
• It is recommended to always use the latest app. 
• Information is not collected by Qlik when using this app. 

The app as well as the configuration guide can be found at the bottom of this post. This app was created internally and will be supported by the developers of the app. They will be following this thread so be sure to post any questions or issues here so they can be addressed. 

Be sure to subscribe to the Qlik Support Updates Blog by clicking the green Subscribe button to stay up-to-date with the latest Qlik Support announcements. Please give this post a like if you found it helpful! 

App Version Change log:

Version 1.2.1

1.2.1
    Added the additional optional variable vu_reloads_page_size for controlling the Reloads API page size. Previously hardcoded at 100. Useful for working around "Message too large" errors.
    Moved the system variables to the top of the "Main" load script tab so that they can be adjusted prior to any of the primary script executing.
1.2.0
    Fixed incremental load issue where the Reloads table had some duplicates post incremental load.
    Updated the "ReloadConcurrencyMinute" field to display all values.
    Updated the "Concurrent Reloads and Peak RAM by Concurrency Minute" chart on the "Dasbhoard" sheet to have a corrected Y axis range.
    Added the additional optional variable vu_audit_page_size for controlling the Audit API page size. Previously hardcoded at 100. This can help to relieve the weight on the audits API calls.
1.1.0
    Initial release

Kind regards, 

Qlik Digital Support Team 

Reload Analyzer v1.2.1.qvf

[Daniel_Pilla]

Hi @Kevin-M,

Qlik Sense Enterprise on Windows has a very comprehensive application specific to reloads that ships with the product called the Reloads Monitor. The Operations Monitor does in fact include reload data, however it is intended to give you an overall view of the entire site, so it doesn't dive in as deeply. The Reloads Monitor is one of a handful of additional applications that are purpose-built for a specific subject areas. You can find all of the supported monitoring apps for QSEoW here.

Cheers,

[AlexOmetis]

@Daniel_Pilla - it's actually the reloads endpoint (not audits) that I'm seeing giving us the message too big, so I've changed this line in sub get_reloads to make that page by the same number as the audits:

SET vParams = 'limit=$(vu_audit_page_size)';

I still hit both errors in different environments so am now trying with ErrorMode=0 to get round the problematic ones.

Update 1: I have managed to get it to run in one environment with ~1,000 reloads over 90 days using 10 per page so that's good. 

Update 2: I have found an issue where if you change the Timestamp format (as I want it to use 24-hours not AM/PM) then the load fails as there is some code run to determine the reload start before the variables are set which means it uses the previous format in one place and then attempts to use the new format to convert it back to a number and fails. The workaround is to add this (or whatever you want your format to be) to the start of the script once and then you can remove it:

SET TimestampFormat='DD/MM/YYYY hh:mm:ss[.fff]';

[Daniel_Pilla]

Hi @AlexOmetis,

I have addressed both issues above in 1.2.1, now posted on the page. I've created a new variable vu_reloads_page_size to address the message size issue (again unless a single reload is too large), and I've moved the system variables to the top of the "Main" tab to make sure that they are resolved first. Refer to the changelog on this post for details.

Cheers,

[jjdench]

Hi,

Are there any plans to include scheduled Automations details within the Reload Analyzer? Or is that information already available?

Thanks

Justin