Monitoring Sisense with APIs and CLI
  • 14 Jun 2022
  • 4 Minutes to read
  • Dark

Monitoring Sisense with APIs and CLI

  • Dark

The monitoring service in Sisense enables you to run system monitoring tests via the REST API or a Command Line Interface (CLI). The test results can be retrieved in the response or via an API. All tests are executed using the System token, unless you provide other credentials.

Note :

For information about the Sisense Application Health check API, see Monitoring Sisense on Linux.

In this document:

Built-in Tests

The following table lists all of the built-in tests and a description of each:

LoginTests successful user authentication
  • Checks that the specified ElastiCube with cubeTitle on localhost is returned
  • Checks that the specified ElastiCube is in Running state
  • If the specified ElastiCube isn't in Running state:
    • Runs the ElastiCube
    • Waits for the ElastiCube to start running
    • Executes a simple query on the ElastiCube
    • Stops the ElastiCube
LiveChecks that Live data models are present in the system
  • Checks the number of unacknowledged messages on all channels isn't bigger than 500
  • Checks that ElastiCubes with no consumers aren't present in the system
  • Returns the failure statistics in the following format:
 "no_consumers_queues": [
 total_unack_messages" : 550
GraphQLChecks that the GraphQL restListElasticubes endpoint returns a list of ElastiCubes

Checks that JAQL can be executed on a specified cube with cubeTitle. JAQL is build dynamically, based on specified optional dimensionId, or on a random ElastiCube field:

 "datasource": "Sample ECommerce",
 "metadata": [
 "dim": "[Brand.Brand]"
 "count": 1,
 "offset": 0
  • Checks that a specific dashboard with dashboardOid can be exported to PDF and downloaded
  • Checks that the downloaded file isn't empty
  • Checks if there are pods in FAILED or UNKNOWN states
  • Checks if there are pod containers in TERMINATED, NOT READY, or FAILED state or that the condition status isn't True
  • Returns failure statistics in the following format:
{'query-7d9798787b-xhsqw': {
    failedContainers: [
        name: 'query',
        state: {
          waiting: {
            reason: 'CrashLoopBackOff',
            message: 'back-off 5m0s restarting failed container=query pod=query-7d9798787b-xhsqw_sisense(23e6d6d0-fb4c-47b2-86c9-923dcc66bd88)'
           lastState: {
             terminated: {
               exitCode: 0,
               reason: 'Completed',
               startedAt: '2020-10-08T08:12:43Z',
               finishedAt: '2020-10-08T08:14:43Z',
               containerID: 'docker://96490307b12b8e9fc5c09c3a4df130fe73508fda9e63c12082ea458a968da217'
              ready: false,
              restartCount: 206,
              image: '',
              imageID: 'docker-pullable://                                               c92dd022ee0f53b10d70de770a9c02f9f5e1083cd9aafa42c1b0798',
              containerID: 'docker://96490307b12b8e9fc5c09c3a4df130fe73508fda9e63c12082ea458a968da217',
              started: false
            failedConditions: [
             type: 'Ready',
             status: 'False',
             lastProbeTime: null,
             lastTransitionTime: '2020-10-07T17:04:33Z',
             reason: 'ContainersNotReady',
             message: 'containers with unready status: [query]'
             type: 'ContainersReady',
             status: 'False',
             lastProbeTime: null,
             lastTransitionTime: '2020-10-07T17:04:33Z',
             reason: 'ContainersNotReady',
             message: 'containers with unready status: [query]'
  • Checks that a connection can be made with the MongoDB instance
  • Checks that the connection is made with the PrismWeb MongoDB instance

Built-in Test Configurations

Internal Test Configurations are additional parameters to set for some of the tests to work. When configuring the Monitoring service initialization, test configurations are loaded into the Monitoring Database under the testConfigs collection and can be further retrieved and modified via the API.

Each test should have a .config file that specifies basic tests configurations.

The following table describes the structure of the test configuration.

testNameThe name of the test 
testEntryFileThe test entry file name, including the extension 

The type of test. Supported test types are:

  • js
  • bash
  • batch
  • python
argumentsConfigurable arguments to run the tests (see Configurable Arguments, below)Empty array
versionThe version of the test1.0.0
enabledIndicates if the test is enabled (boolean). Disabled tests aren’t included to run all test flows, but still will be available for running by nametrue
executionTimeoutTest execution timeout (ms)5000
retryNumber of allowed retries1

Example of a Test Configuration

"testName": "exampleNodeJSTest",
"testEntryFile": "index.js",
"type": "js"


You can also specify the inline test configurations instead of using the global preset tests. This enables you to configure health monitoring tests for ad-hoc use. For technical API information about Application Health Check, see

Configurable Arguments

Some of the tests need to be configured for them to run. This applies to tests that check dashboards, widgets, and ElastiCube functionality. The following table describes these configurations.

Test NameConfigurationDescription

"arguments": [

{"cubeTitle": "Simple ECommerce"





"arguments": [


"cubeTitle": "Simple ECommerce",

"dimensionId": "Brand.Brand"



cubeTitleCube title for running JAQL (case sensitive)
dimensionIddimensionId for JAQL (optional)


"arguments": [


"dashboardOid": 12345



dashboardOidSpecifies the dashboard to test

Running Tests with the REST API

The REST API is included in version 2 of Sisense’s API and is available in /api/v2/tests.

With the REST API, you can:

  • Get the list of current tests
  • Run tests asynchronously
  • Return the latest test results
  • Return the current tests by test configuration ID or name
  • Update a specific test by ID or name

For more information about working with the REST API, see

Running Tests with the CLI

You can use the CLI to monitor your Sisense deployment. To do so, you'll first need to run docker/kubectl exec to the container. CLI commands can be executed as:

node ./src/cli/index.js <operation> <options>.

The following table lists supported Operations:

helphDisplays Help
getTestListlistDisplays the list of available tests
executeTestsexecExecute tests. Tests can be specified by the --names option (test names to be executed) or by the --all option (executes all tests)

The following table lists supported Options:

--table-tDisplays the results in a table
--names-aExecutes all tests that are present in the /tests folder (relevant for the executeTests command)
--isAsync-isAsyncExecutes tests in an asynchronous way, and saves the results to a dedicated MongoDB database called MonitoringDB, in the testResults collection
--token-tokenExecutes tests with a specified token for test operations with the Sisense API
--credentials-credsExecutes tests with specified credentials (username, password) for test operations with the Sisense API

CLI Examples

  • Run help for a specific command:

    node ./src/cli/index.js help <command>

  • Run specific tests and display results as a table:

    node ./src/cli/index.js executeTests -n galaxy --table

  • Run all tests:

    node ./src/cli/index.js executeTests --all

  • Run tests with a specific token:

    node ./src/cli/index.js executeTests --all --token 123456

  • Run tests with specific credentials:

    node ./src/cli/index.js executeTests --all --credentials mypassword

  • Run all tests asynchronously:

    node ./src/cli/index.js executeTests --all --isAsync

Was this article helpful?