Qlik Data Gateway Direct Access: Basic Health Check

[NadiaB]

When Qlik Data Gateway Direct Access is implemented, sometimes, as the workload increases post-implementation, customers may experience general stability issues. We suggest a basic health check to address the more well-known problems and stabilize your gateway implementation. 

This article outlines the following five:

• Verify the number of disconnects
• Verify the number of ODBC connector crashes
• Verify long-running metadata requests
• Verify that new features intended for stability and performance are enabled
• Excessive logging level

Verify the number of disconnects

A high number of disconnects can cause reload disruptions. Some important disconnects will be recorded in the DirectAccessAgent logs. While a low volume of disconnects is expected and will typically recover within a few seconds, a high number of entries in the logs are indicative of a problem.

We suggest initiating an internal investigation if more than ten disconnects are found per day. 

Search for “[ERROR] Connection to”, sample:

[Service ] [ERROR] Connection to <mytenant>.us.qlikcloud.com:443 failed

If the number of disconnections is high, we suggest referring to: 

• Qlik Data Gateway - Direct Access. Reloads failing intermittently
• Data Gateway Direct Access disconnections (0x80004005): The remote party closed the WebSocket connec...

Verify the number of ODBC connector crashes

ODBC connector crashes can impact concurrent reloads if Process Isolation is not enabled. We suggest customers who experience crashes in their logs enable Process Isolation and configure Dump file creation. 

Process isolation for ODBC connector can be confirmed in the C:\ProgramData\Qlik\Gateway\configuration.properties. ODBC_PROCESS_ISOLATION_MODE, will be set to None if disabled, and set to Load if enabled.

It can also be verified using the logs. The ODBC logs named odbc-connector_logs.txt, odbc-connector_logs.txt.1 from 1 to n. If isolation is enabled, the files includes a port number, for example odbc-connector_logs_49156.txt where 49156 would represent a port number.

To identify whether there are crashes or not in your DAG (Direct Access Gateway) and proceed to enable Process Isolation we suggest reviewing Qlik Data Gateway - Direct Access - ODBC Crashes.

1.7.9 introduced Process Isolation for metadata requests. It is suggested to configure it to ALL 

Verify long-running metadata requests 

Other causes of issues would be due to misconfiguration of third-party drivers, the details are outlined in Qlik Data Gateway Direct Access Data Preview long metadata requests.

Keep in mind that these recommendations are additional validations to the Best Practices and System Prerequisites documented in our Help Site:

• Best practices when using Qlik Data Gateway - Direct Access
• System prerequisites

1.7.9 introduced Process Isolation for metadata requests. It is suggested to configure it to ALL 

Verify that new features intended for stability and performance are enabled

• Enable Process Isolation 
• Enable Load Data requests asynchronously
• Enable Requesting load slots asynchronously

Excessive logging level

In the past enabling Agent log to Debug was an usual suggestion for troubleshooting, since the introduction of chunk recovery setting AGENT_LOG_LEVEL will incur in excessive logging, files size exceeding 1GB size, this logging level should only be enabled when suggested by Support and should include parameters for AGENT_LOG_OPTIONS that will significantly reduce the logged information when AGENT_LOG_LEVEL  is set to DEBUG. If you currently have AGENT_LOG_LEVEL  is set to DEBUG without parameters set for AGENT_LOG_OPTIONS it is suggested to set it back to INFO.

Environment

• Qlik Data Gateway Direct Access

[AlexOmetis]

Worth noting that the logs for process isolation will only appear when some data is loaded (not connection test / data preview) using that connection - so you can't just restart the service and see the logs to confirm, you need to do at least one data load.