Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Great post, and a very well-structured question!
On question 1: Is /data/metadata the right endpoint?
Yes, /api/v1/apps/{appId}/data/metadata does return reload performance metrics including cpu_time_spent_ms, peak_memory_bytes, and fullReloadPeakMemoryBytes. However, it was not designed for bulk iteration. The endpoint opens the app engine session internally to collect the metadata, which is expensive server-side and explains why it is slow and prone to timeouts at scale.
On question 2: Is there a better endpoint?
For reload performance metrics specifically, consider using the reload tasks API combined with the audit/reload logs approach. A more efficient alternative for bulk retrieval is:
GET /api/v1/reloads?appId={appId}&limit=1This endpoint returns reload history including duration and status without opening an engine session. However, it does not expose peak_memory_bytes or fullReloadPeakMemoryBytes directly. Unfortunately, those specific memory metrics are only available via /data/metadata today, so there is no complete alternative for those fields.
On question 3: Best practices to avoid 504 errors
A few approaches that help significantly:
Add a SLEEP between iterations to reduce server pressure:
CALL app_metadata;
CALL Sleep(500);
Batch your app IDs into smaller groups and reload in multiple passes rather than all 600 in one run.
Implement retry logic: since you mentioned the script still retrieves data even after a 504, wrapping the call in an error handler with a retry attempt can make the loop more resilient:
FOR vRetry = 1 TO 3
// your SQL SELECT here
IF ScriptError = 0 THEN
EXIT FOR
END IF
CALL Sleep(2000)
NEXT vRetry
Also, reconnecting inside the loop (LIB CONNECT TO) on every iteration adds overhead. Move the connection outside the loop if the REST connector supports reuse in your environment.
On question 4: Has anyone faced this?
This is a known pain point when using /data/metadata at scale. The endpoint was primarily designed for single-app inspection, not bulk extraction. The 20-minute runtime for 600 apps (roughly 2 seconds per app) is actually close to the expected behavior given how the endpoint works internally.
Suggested architecture for your use case
Instead of calling the API live on every reload, consider building an incremental approach: store the metadata results in a QVD after each successful call, and on the next reload only fetch apps that have reloaded since the last extraction. This way you are never processing all 600 apps in a single run.
Hope this helps!
These are excellent questions, and they directly address how Qlik exposes performance data at scale.
Q1: Do Qlik logs expose reliable CPU or resource usage metrics per app or task?
A1: Yes, but through a specific logging mechanism that needs to be explicitly enabled. Since the February 2018 release of Qlik Sense, it is possible to capture granular usage metrics from the QIX in-memory engine based on configurable thresholds, including CPU and RAM utilization of individual chart objects and reload tasks.
This is done via QIX Performance Logging (also called Telemetry Logging). Telemetry data is logged to C:\ProgramData\Qlik\Sense\Log\Engine\Trace\<hostname>_QixPerformance_Engine.txt and includes fields such as DocId (the app ID), PeakRAM, NetRAM, and ProcessTime (the end-to-end clock time for a request).
The key fields for your use case are:
- ProcessTime - total execution time per engine operation
- PeakRAM - peak memory used by an operation
- DocId - identifies which app triggered the operation
- Method — the type of engine operation (reload, hypercube calculation, etc.)
One important caveat: having Warning level QIX Performance logging enabled produced a small increase in response times of around 1.4% over having logging disabled, while Info level produced a 7.0% increase. For production monitoring, the recommended setting is Warning or Error, not Info, to keep the overhead low.
Q2: What data sources do the Operations Monitor and Reload Monitor use?
A2: The Operations Monitor loads service logs to populate charts covering performance history of hardware utilization, active users, app sessions, results of reload tasks, and errors and warnings. Qlik-poc It reads directly from the log files on disk, not from the Engine API, which is precisely why it scales well and does not put pressure on the engine at all.
The App Metadata Analyzer provides a holistic view of all Qlik Sense apps, including granular detail of an app's data model and its resource utilization. Qlik Help This one does call the Engine, but it does so in a controlled, scheduled way rather than on demand for every app simultaneously.
The key architectural insight here is that the native monitoring apps are all log-based and batch-oriented, not live API calls. That is how they handle hundreds of apps without engine pressure.
Q3: Recommended approach for performance monitoring at scale
A3: Based on what the native monitoring stack does, the recommended pattern for your use case is:
Log-based collection over API polling. Enable QIX Performance Logging at Warning level in the QMC (Engines → [engine] → Logging → QIX Performance log level), then load those log files into your monitoring app via a scheduled reload. This gives you per-app, per-operation metrics without any Engine API calls at runtime.
Incremental QVD layer. Since you are already building a monitoring app with QVDs, structure it so each reload only picks up new log entries since the last run, not the full history. This keeps reload time short even as the log volume grows.
Avoid polling /data/metadata for monitoring. As we established earlier, that endpoint opens an engine session per app and does not scale. For the metrics you described, identifying resource-intensive apps and detecting spikes, the QIX Performance logs give you equivalent or better data without the engine overhead.
For a ready-made reference implementation, the Telemetry Dashboard (available at github.com/eapowertools/qs-telemetry-dashboard) follows exactly this pattern and can serve as a starting point or benchmark for your own monitoring app.
Hope this helps move the architecture forward!
Sources:
https://github.com/eapowertools-archive/qs-telemetry-dashboard/wiki/Logging-Performance
https://adminplaybook.qlik-poc.com/docs/tooling/operations_monitor.html
