Monitoring Sisense with APIs and CLI

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.

Built-in Tests

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

Title	Description
Login	Tests successful user authentication
Query	Checks that the specified ElastiCube with cubeTitle on localhost is returned Checks that the specified ElastiCube is in Running state If the specified ElastiCube is not in Running state: Runs the ElastiCube Waits for the ElastiCube to start running Executes a simple query on the ElastiCube Stops the ElastiCube
Live	Checks that Live data models are present in the system
RabbitMQ	Checks the number of unacknowledged messages on all channels is not 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": [ "build-cccd8483-09f7-40aa-b43a-e12339c93e28", "management-74fe3d97-64d7-4913-a77e-5792c84953c1", "query-47def361-1d6f-45ba-8eee-efabeb8c27e7", "query-d919d2ac-f3a5-48d3-9679-848d8e5dd7bf", "sisense.build.data.source.updated.cache.evict.queue-0cc53160-2211-409a-b413-d2be8fc7a28c", "sisense.elasticube.metadata.changes.query.queue-01e2c7c0-77d4-4e04-a1c2-a706cf1fa09a" ], total_unack_messages" : 550 }
GraphQL	Checks that the GraphQL restListElasticubes endpoint returns a list of ElastiCubes
JAQL	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 }
Galaxy	Checks that a specific dashboard with dashboardOid can be exported to PDF and downloaded Checks that the downloaded file is not empty
Pods	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 is not 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: 'docker.artifactory.sisense.com/query:L8.2.6-monitoring.14', imageID: 'docker-pullable://docker.artifactory.sisense.com/query@sha256:bab9bec32 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]' } ] }
Mongo	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.

Property	Description	Default
testName	The name of the test
testEntryFile	The test entry file name, including the extension
type	The type of test. Supported test types are: js bash batch python
arguments	Configurable arguments to run the tests (see Configurable Arguments below)	Empty array
version	The version of the test	1.0.0
enabled	Indicates if the test is enabled (Boolean). Disabled tests are not included to run all test flows, but still will be available for running by name	true
executionTimeout	Test execution timeout (ms)	5000
retry	Number of allowed retries	1

Example of a Test Configuration

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

Note:

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 sisense.dev.

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 Name Configuration Description

Query

{

"arguments": [

{"cubeTitle": "Simple ECommerce"

}]

}

JAQL

{

"arguments": [

{

"cubeTitle": "Simple ECommerce",

"dimensionId": "Brand.Brand"

}]

}

Config	Desc.
cubeTitle	Cube title for running JAQL (case sensitive)
dimensionId	dimensionId for JAQL (optional)

Galaxy

{

"arguments": [

{

"dashboardOid": 12345

}]

}

Config	Desc.
dashboardOid	Specifies 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 https://sisense.dev.

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:

Operation	Shorthand	Description
help	h	Displays Help
getTestList	list	Displays the list of available tests
executeTests	exec	Execute 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:

Operation	Shorthand	Description
--table	-t	Displays the results in a table
--names	-a	Executes all tests that are present in the `/tests` folder (relevant for the `executeTests` command)
--isAsync	-isAsync	Executes tests in an asynchronous way, and saves the results to a dedicated MongoDB database called MonitoringDB, in the `testResults` collection
--token	-token	Executes tests with a specified token for test operations with the Sisense API
--credentials	-creds	Executes 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 example@example.com mypassword
Run all tests asynchronously:

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