Sisense Monitor

Important!

Sisense Monitor is a part of the Central Monitoring Service that Sisense offers as an add-on to the Sisense for Product Teams and Sisense for Business Intelligence and Analytics Teams packages.


The following information describes the data that Sisense Monitor collects and describes how to troubleshoot common issues with the information contained in the Sisense Monitor dashboard. For example, you can identify if too many concurrent builds are affecting query performance and then take corrective action such as scheduling builds throughout the day.

Sisense also collects data when you or your users install or use Sisense products or services. Sisense collects the data for internal and support-related purposes to improve our products and services, increase customer engagement, conduct research, and solve technical issues.

Prerequisites

Your servers can send data collected by Sisense. For a list of the types of data Sisense collects, see Collected Product and Usage Data.

This service is a subscription feature and you should contact your CSM for more details.

Minimum Requirements

Sisense Monitor runs in the following HTML5 supported browsers:

  • Google Chrome
  • Firefox

Data Security and Privacy

Sisense Monitor requires that your Sisense server has access to the internet, and can send monitoring information to the service. All information is secured and transferred over HTTPS.

To ensure a high-level of security, Sisense collected product and usage data is stored by a third-party service on AWS data centers. The third-party service has the following certifications:

  1. SOC 2 Type 2 compliance
  2. ISO 27001 compliance
  3. HIPAA compliance

The system does not store personal identity information about your users. By default, Sisense usernames and email addresses are obfuscated before the data leaves your Sisense server.

All Sisense Monitor collected data is stored for 30 days and then deleted. A copy of the collected data is indefinitely stored on secure Sisense servers for internal research purposes.

Additional information collected by the monitoring system can be obfuscated by the system prior to it leaving your Sisense server.

If you have deployed Sisense on Linux, you can easily configure Sisense to send no information at all by setting the parameter external_monitoring to false in the configuration script. For more information about this parameter, see Installing Sisense on Linux.

Data Refresh Frequency

The data displayed in Sisense Monitor is refreshed as follows:

  • System Resources: Data regarding your system, such as CPU, Memory, available hard disk space, etc. is collected and sent to Sisense Monitor every minute.

  • Builds and Queries: Data regarding build attempts and queries is sent immediately after the action is complete.

Time Handling

All timestamps that appear in Sisense Monitor are displayed according to your browser's timezone.

Filtering Your Servers

When you log in to Sisense Monitor, the data displayed is the aggregated data for all of the servers together. You can filter the data to display only the data relevant for a specific server by hovering over the server in the Host List widget and clicking

You can select to exclude the data of a specific server from being displayed in Sisense Monitor.

Each time you filter a server, the data displayed in Sisense Monitor is refreshed.

Changing Your Password

If you need to change your Sisense Monitor password, from the Sisense Monitor homepage, click Forgot Password and enter account username or email.

Sisense will send an email with a URL to change your password. This URL is valid for 24 hours, afterwards, you must generate a new URL to change your password.

Open this URL and enter the new password. The password must be at least 8 characters.

Host List

This widget displays the list of your hosts together with the total number of log records sent by the host in the selected time period.

The amount of log files sent by a server depends on its usage. Log files about system resource utilization are sent every minute, regardless of the server usage. Logs about queries and builds are only sent when queries and builds occur. On a server that is not running builds, there will not be any build or query logs.

The amount of logs sent varies depending on how your server is used, however, the amount should be relatively consistent unless your server has recently changed.

Sisense Status at a Glance

This section provides a quick view of the status of queries and ElastiCube builds in your system.

Total Queries

This widget shows the total amount of queries executed in the system, during the selected time interval.

Queries by Status

This widget shows the total amount of successful and failed queries executed in the system, during the selected time interval.

Build Count

This widget shows the total amount of builds performed by the system, during the selected time interval.

Builds by Status

This widget shows the total amount of successful and failed builds performed by in the system, during the selected time interval.

Query Monitoring

This section provides information about your query performance such as their success and failure and the volume of queries being sent to your ElastiCube server.

Query Details Table

This widget provides information about the queries executed in the system during the selected time period.

Query Response Time (Sec.)

This widget provides information about the system query response time. It provides the maximum duration of a query and the average duration of queries in seconds over time.

The time interval between the data points depends on the selected time interval.

ElastiCube Builds Monitoring

This section provides information about your ElastiCube builds in your system.

Build Status Timeline

This widget provides information about the builds performed by the system. The information is provided for each ElastiCube in the system. Successful builds appear in green. Failed builds appear in red.

The time interval between the data points depends on the selected time interval.

Build Blocks Timeline

This widget provides information about the builds performed by the system. The information is provided for each ElastiCube in the system. The build process for each ElastiCube is comprised of multiple blocks, including the following stages:

  1. Initialization (appears as empty space)
  2. Data Import
  3. Custom Column handling
  4. Custom Table handling
  5. Finalizing

The display only includes data regarding successfully built tables. If the build of a table fails, it will not appear in the widget. The last table that is displayed is the last successful table.

This widget is limited to 10K records. If the selected time period includes more records than can be displayed, empty space will be shown on the chart. You can drill down to specific time interval to display information about builds that happened during that period.

The time interval between the data points depends on the selected time interval.

Build Details Table

This widget provides information about the builds performed by the system during the selected time period.

System Resources

This section provides information about your system resource usage, such as software versions, CPU, memory, network and disk utilization.

System Information

This widget provides information about your system, including the Sisense version, hard disk (model, total size, space in use and available size), RAM capacity, number of cores, OS version, and more.

Server Information

This widget provides information about your server configuration and status, including the location of the data folder where ElastiCubes are stored, the server's size and available free space on the server, port configuration, and others.

Total CPU Utilization

This widget provides information about the CPU utilization over time.

All information is provided as a percentage of the total CPU available on your server.

The time interval between the data points depends on the selected time interval.

Memory Utilization

This widget provides information about the memory usage in terms of working set. It provides the maximum memory utilization and average memory usage over time.

All information is provided as a percentage of the total working set available on your server.

The time interval between the data points depends on the selected time interval.

Sisense Components CPU Utilization (%)

This widget provides information about the CPU utilization for Sisense's components. The total CPU usage on the server is also displayed. The total CPU usage includes the CPU usage by Sisense components and non-Sisense components.

All information is provided as percentage of the processor time available on your server.

The time interval between the data points depends on the selected time interval.

Sisense Components Memory Utilization (GB)

This widget provides information about the memory utilization for Sisense components. The total memory usage of the server is also displayed. The total includes the memory usage by Sisense components and non-Sisense components.

All information is provided as amount of working set in GB.

The time interval between the data points depends on the selected time interval.

C Drive Disk Utilization

This widget provides information about the C drive disk utilization. It includes the total C disk space, and the utilized disk space, over time.

Note that the C drive is used for storing Sisense system configuration, dashboard definitions, user profiles, and more. ElastiCubes are stored in the data folder, which may not be located on C drive. Information regarding the data location, available and in-use disk space is available in the widget .

The time interval between the data points depends on the selected time interval.

I/O Utilization (%)

This widget provides information about the I/O utilization. All information is provided as percentage of the available disk time.

The time interval between the data points depends on the selected time interval.

Network Utilization

This widget provides information about the network utilization. All information is provided in bytes.

The time interval between the data points depends on the selected time interval.

Cube Virtual Bytes Allocation (GB)

This widget provides information about the virtual memory allocation of Sisense ElastiCubes defined on the server.
All information is provided in gigabytes.

The time interval between the data points depends on the selected time interval.

Cube CPU Utilization

This widget provides information about the CPU utilization of Sisense ElastiCubes defined on the server.

All information is provided in percentage of processor time units.

The time interval between the data points depends on the selected time interval.

Cube Memory Utilization (GB)

This widget provides information about the memory utilization of Sisense ElastiCubes defined on the server.

All information is provided in working set units (GB).

The time interval between the data points depends on the selected time interval.

Log Monitoring

This section shows the amount of log files sent to the monitoring system. Use this to verify that your system is sending monitoring data.

Log Count

This widget provides information about the number of logs sent by the server to the monitoring system. This can be used to make sure your system is sending data to the Sisense Monitor system. In case your system has not sent monitoring data for a given period of time, data may not be available in the Sisense Monitor dashboard for that time period.

Troubleshooting with Sisense Monitor

Sisense Monitor enables you to monitor and troubleshoot issues on your Sisense system.

This section describes how to use the Sisense Monitor to troubleshoot potential issues with your ElastiCube server and dashboards.

Debugging ElastiCube Issues

Sisense Monitor can help you troubleshoot errors such as build failures, frozen builds, and server crashes.

This section describes examples of these errors and how you can troubleshoot them with Sisense Monitor.

Build Failures

There are several reasons your builds can fail ranging from ElastiCube designs to disk space capacity.

To try to identify where the problem is occurring and take corrective action, when a build fails, check the following:

  1. Concurrent Builds: Use the Build Status Timeline widget to check if there were multiple builds running at the same time. Too many concurrent builds can lead to increase in memory usage and may crash the server.
  2. Memory and CPU:The CPU and Memory widgets provide information at the machine level, the Sisense component level, and the ElastiCube level. In case of high memory or high CPU utilization, the information displayed in these widgets allows you to determine what contributed to the high values.

    Note:

    Towards the end of a full build, the ElastiCube memory usage increases and may even double. This is normal memory consumption. Once the build process completes, the memory returns to normal levels. To allow querying during the build process, the process first builds a new ElastiCube from scratch while the existing one is used for queries. Once the build is complete, the old ElastiCube is deleted.


  3. C Drive Disk Utilization: The C Drive Disk Utilization widget monitors the C drive. This drive should not be more than 80% full. In cases of a full disk space, refer to this article .
  4. Stage of the build: In the widget named Build Details Table you can view the details of each build and its status. In addition, the Build Block Timelinewidget displays the stages of the build, the type of the build and detailed information about the number of records and data source.

    Every Entire and Cumulative build process has the following flow:

    Initializing > Import > Custom Fields > Custom Tables

    A schema changes build usually only builds the custom tables and fields, and any new table added since the last full build.

    Every build block represents a table, custom field or custom table. Every block sends a log when it starts and when it ends. In case of a failure the currently running build block will not send an end log, and the start log will not appear as well. In case of a failure, the last available block will be the last successful build block.

    Tip: During the processing of custom tables and fields the RAM utilization will start increasing. A failure at this stage may suggest a memory problem, or a syntax problem in the queries.

    Tip: In case of failure with high memory consumption, while processing custom objects you should check the ElastiCube's data modeling and make sure there are no many-to-many relationships.

  5. Network Utilization: Check the network usage and download speed in the Network Utilization widget. Verify there was no network connectivity issue. If the line is completely flat or constantly very high with no drops, this indicates a network issue. If the line is very low, the build may have a connectivity timeout on the data sources connections. During the import stage, the network utilization should not be lower than a few Mbps.
  6. IO utilization:If the line is constantly high, there may be a problem with the disk performance. During the import stage, low usage of RAM is expected as the server is only receiving data from an external source and is not performing any computations. During this time, high network and disk I\O usage are expected. A failure at this stage may suggest a connectivity configuration issue, or a configuration or data limitation issue (long-index, # of records, etc..).

    Tip: In case of failure during the import stage with extremely low or high network usage, check the connectivity with the data sources.

Frozen Build

When a build freezes entirely or takes longer than usual to complete, there are a few things you can check to improve performance:

  1. Data Source:The connection to the data source is busy. This usually occurs during the import stage along with very low or no network usage and no increase in ElastiCube size on the disk (ElastiCube Virtual Bytes widget). In this case, the data source is likely to close the connection at some point and the build will fail with a connectivity error.

    Tip: Check if the Sisense query was received by the data source, and whether it is in a queue, still being processed, or was it cancelled?

  2. Custom Table:Custom table or custom build hangs could be caused by a change in the custom tables/fields syntax. If the query is different from other builds that were faster, the new query might be too long or complicated. Sisense custom queries timeout in six hours. After six hours of processing the same table, the build will fail.

    Tip: If the build hangs while building custom objects, check the query.

Server Crash

A server crash may happen when the memory usage reaches 100%. This can happen due to a combination of concurrent builds or too many queries from the Sisense Web Application.

When the server crashes, memory utilization will reach a peak and then drop to zero.

In this case you should restart the ElastiCube management service and verify that the Server Console is able to find the ElastiCubes, and if so, that the ElastiCube are running and your dashboards are working.

Debugging Dashboard Issues

If you experience dashboard issues such as widgets or dashboards crashing or longer load times than expected, your web server may be receiving a high amount of concurrent queries.

When your server receives a high volume of queries, some of the queries are queued and then handled in the order that they were received leading to an increase in average response time.

If you are experiencing dashboard issues, check the Query Response Time widget. This widget shows the maximum and average response times over time. A query that timed out will have a response time of 300 seconds (5 minutes), which is the Sisense default timeout for web queries.

Once you have narrowed down the time frame to the relevant dashboards' slow response or failure time, look at the Query Finish Search widget, where you can view a record of every widget's execution. Check the status of the queries and look for a pattern in the widgets/dashboards that take longer to return or fail.

Tip: In some cases you'll be able to pinpoint a heavy widget by the response size, that is a field in the Query Details Table widget that specifies the response size in bytes. If it's over 10,000, it could be a reason for the performance degradation. Usually this is caused by large pivot tables or scatter charts.

Troubleshooting Sisense Monitor

If you have problems locating a host in Sisense Monitor, verify the following:

  1. Sisense Monitor is enabled on the host. By default, Sisense Monitor is enabled as part of every installation, but you may have manually disabled it.
  2. The host has internet access.
  3. A firewall is not blocking outgoing data from the host.
  4. The host was not installed with a different Owner ID.

Related Topics

Collected Product and Usage Data