Resizing System Volume Information (SVI) Windows only
Question: Sometimes your server might run out of space on because the SVI (System Volume Information) is eating up all memory. The system volume information is used in windows in order to save information related to system restore which is used when a restoration of the system is performed. The problem is that if there is no size limit to this feature, it might take a significant amount of the system memory, without ability to directly delete it. Answer: There are two ways to resize the SVI: Through the system properties - follow these instructions: http://www.pcadvisor.co.uk/how-to/windows/how-make-system-volume-information-folder-smaller-3613911/ Through the command line - if you don't see the system protection tab according to the above method, you can resize it through the command line: https://indrajitc.wordpress.com/2008/03/25/reclaiming-disk-space-from-system-volume-information/Pulse Troubleshooting (Windows)
Sisense Pulse allows you to stay on top of your most important KPIs across all your dashboards and your ElastiCube builds status. If you face any issues with Sisense Pulse, the first step is to identify if none of the alerts are working, or whether it's an issue for specific notifications such as email reports or push notifications created by the system. If no alerts are created (meaning you see no notifications in the notification icon), this could indicate that Pulse communication is either blocked or isn't running successfully. No Alerts are Created If you do not receive any alerts, verify that the following services are running: In Windows Services Manager for Sisense V7.2 and later, verify that Sisense.Broker is running: 2. In Task Manager, under Details, verify that Sisense.AlertingMQ.exe and erl.exe are running. 3. Verify that port 5672 is open on the Sisense server for the RabbitMQ system to have open communication. When Pulse is not running as expected, we strongly suggest trying and restarting the Sisense.Broker service and follow Steps 1 and 2 again to see if the issue is resolved. If after restarting the services Pulse is still not running as expected, the next step is to verify that the ElastiCube Manager is creating the proper notifications. You can verify this by navigating to %ProgramData%\Sisense\PrismServer\PrismServerLogs\ECS.log and search for ‘EventsPublishManager’ in the log. If there are no messages with ‘EventsPublishManager’, it means that Pulse was not triggered or some error message could be logged that describes the cause of the issue. In rare cases there might be an issue with RabbitMQ database. Make sure the following folder exists in your environment C:\Program Files\Sisense\Infra\Rabbitmq. Specific Notifications are not Received If the notifications are displayed in Sisense in your Notifications Feed, but you do not receive emails or push notifications in the mobile app, make sure you have checked these options under the Alert settings when you created the alert: Regarding push notifications in Sisense Mobile, make sure that all users that are supposed to get push notifications are logged in to the mobile application and have the proper application permission for popups. If some users do not receive email notifications, check if they can receive any system emails like ‘forgot password’ or when a dashboard is shared. In case no emails are sent from the system, review the email troubleshooting guide. Another useful test to conduct is to try running the Pulse on a different widget in order to make sure this is not a widget related issue. *Note* for Split Deployment Models Prior to Sisense 7.4 If you are not receiving pulse alerts and have a split deployment set up (High Availability, one cube server and one web server, etc) please follows the steps below to see if this resolves the issue you are facing. On the cube server, open "C:\ProgramData\Sisense\PrismServer\ElastiCubeConfiguration.xml" and edit the RabbitMQ IP address to be the IP (or name) of the app/web server Restart the Elasticube Management service (ElastiCubeManagementService -or- Sisense.ECMS and Sisense.ECMServer) On the app server, check to make sure ERL.exe and Sisense.Alerting.MQ.exe is running and 5672 is open from build to app server Restart Sisense.Pulse (or Sisense.Broker) Do a test build that you expect to receive pulse alerts for Still Not Receiving Pulse Alerts? If you are still not able to resolve the issue with the above information, please make sure to submit a ticket with screenshots and results of the above steps and we’ll happily assist!How to update style sheets in the branding folder for dashboards
In this article, we will address the issue of updates made to style sheets within a branding folder not reflecting on dashboards. Users often encounter this problem due to browser caching, which prevents the most updated CSS files from loading. This guide provides solutions to ensure your dashboard reflects the latest version of your style sheets.Overview to Interpreting Sisense 7.2+ Logs
In Sisense Version 7.2 and beyond, we replaced many components of the IIS web hosting with a NodeJS framework, as well as making many new structural changes to the software. This allowed us to categorize the key components of the application to categories of microservices. Each microservice performs some essential functionality in the software, and each one also has it's own logging file path associated with it. While this certainly isn't an all inclusive guide, this article is intended to shed light on the logging processes of the software. In order to interpret the logs for a particular issue, a user will need to first narrow down exactly which service is being affected. This can best be done by understanding the services list at the following article: Identifying Sisense Services Once we identify where exactly the issue is, we can find most logs for each individual service at the corresponding file path in: C:\ProgramData\Sisense\application-logs The main exception of logs that would not be found in the individual service logs, are the following: Build Logs (which detail each individual build error and successes, and often times contains better error reporting than the GUI in the elasticube managers): C:\ProgramData\SiSense\PrismServer\ElastiCubeProcessLogs<YourElastCubeName> Prism Server logs: C:\ProgramData\SiSense\PrismServer\PrismServerLogs Sisense Web log: C:\ProgramData\Sisense\PrismWeb\Logs ElastCube build logs: C:\ProgramData\SiSense\PrismServer\ElastiCubeProcessLogs<YourElastCubeName> MongoDB: C:\ProgramData\Sisense\PrismWeb\Repository\DB iisnode (web server) logs: C:\Program Files\Sisense\PrismWeb\vnext\iisnode Many log paths include an "error" log and then a general log name that does not include "errors" or "stderr". This is done as a way to simplify the troubleshooting process by filtering out all of the errors into their own log file, this is not always the case for each log, though, and sometimes it can be beneficial to look at the log file that doesn't include errors to see the process flow of the application leading up to, during, and after an issue has been noticed. All of the logs contain single instruction level data, meaning that, while they can be rather large, each instruction is associated with a particular timestamp, so it is important to know the date and time that the error occurred beforehand. Once you are able to narrow down the individual service and time stamp that the error occurred with, you can go to that section of logs and begin your digging. As multiple processes can occur in a very small window of time, most users find it beneficial to search for the term "fail", "failure", or "error" to narrow down exactly which line might be relevant to their search. Once a user has found the particular error that they feel could be responsible for the particular issue they are having, there are a few key elements to look for. While some errors are simple to understand, such as a build failing from needing more space on the hard drive, others could be more challenging since they are often written at the software developer level, and may even include a stack trace of where exactly in the program code the issue occurred. For errors of this later type, it is best to document the error, and open a service ticket with the support team for further analysis. Users should also note that these microservices often call API endpoints and other pieces from other microservices, which may require them to do some further troubleshooting in those particular set of logs. For example, a user may notice that an API call in the API-Gateway logs is calling an API that has the term "Galaxy" in it, and this call is returning a 500 code (an internal service error code which could have many different causes, and is considered to be a very generic error), the user should be able to go into the galaxy logs for that particular time stamp, and see the call being made, and find out more specifically what caused it to fail. All of the logs contain single instruction level data, meaning that, while they can be rather large, each instruction is associated with a particular timestamp, so it is important to know the date and time that the error occurred beforehand. Once you are able to narrow down the individual service and time stamp that the error occurred with, you can go to that section of logs and begin your digging. As multiple processes can occur in a very small window of time, most users find it beneficial to search for the term "fail", "failure", or "error" to narrow down exactly which line might be relevant to their search. Once a user has found the particular error that they feel could be responsible for the particular issue they are having, there are a few key elements to look for. While some errors are simple to understand, such as a build failing from needing more space on the hard drive, others could be more challenging since they are often written at the software developer level, and may even include a stack trace of where exactly in the program code the issue occurred. For errors of this later type, it is best to document the error, and open a service ticket with the support team for further analysis. Users should also note that these microservices often call API endpoints and other pieces from other microservices, which may require them to do some further troubleshooting in those particular set of logs. For example, a user may notice that an API call in the API-Gateway logs is calling an API that has the term "Galaxy" in it, and this call is returning a 500 code (an internal service error code which could have many different causes, and is considered to be a very generic error), the user should be able to go into the galaxy logs for that particular time stamp, and see the call being made, and find out more specifically what caused it to fail.Resolving "Internal Server Error" When Importing Model with Generic JDBC Connector [LINUX]
Resolving "Internal Server Error" When Importing Model with Generic JDBC Connector This article addresses the issue of encountering an "Internal Server Error" when importing a model from a local desktop to a production environment using the Generic JDBC connector in Sisense. This error often arises due to compatibility issues with older JDBC frameworks. Here, we provide a solution to resolve this error by updating the JDBC connector and connections. Step-by-Step Guide: Identify the Error: a. When importing the model, if you receive an error message resembling: Unexpected error value: { timestamp: {}, status: 500, error: "Internal Server Error", path: "/api/v1/internal/live_connectors/auth/GenericJDBC… } b. This error could indicate a problem with the outdated Generic JDBC connector. Understand the Cause: The error is due to the Generic JDBC connector using an older framework that is incompatible with the latest Sisense versions. Update the JDBC Connector: Deploy the JDBC connector using the new JDBC framework. Ensure all connections within the cube in the original environment where the model was exported are updated accordingly. Deploying the New Framework: Follow the step-by-step instructions detailed in the Sisense documentation for deploying a custom connector with the new JDBC framework. Access the documentation here: Deploying a Custom Connector - Sisense Documentation. Re-attempt the Model Import: Once the JDBC connector is updated, try importing the model again into the production environment. Conclusion: In conclusion, updating the Generic JDBC connector to align with the new JDBC framework and ensuring the connections are properly configured should resolve the "Internal Server Error" encountered during the import process. Following the above steps will help ensure a smooth and successful model import. References/Related Content: Deploying a Custom Connector - Sisense Documentation Sisense Community Support Forum Introduction to Data Sources Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this please let us know.Resolving "Internal Server Error" When Importing Model with Generic JDBC Connector
This article addresses the issue of encountering an "Internal Server Error" when importing a model from a local desktop to a production environment using the Generic JDBC connector in Sisense. This error often arises due to compatibility issues with older JDBC frameworks. Here, we provide a solution to resolve this error by updating the JDBC connector and connections.How to Troubleshoot UI Issues Using DevTools (HAR File & Console Logs)
If a webpage, dashboard, or widget isn't loading properly, encounters errors during exporting, importing, editing, or opening, or if buttons are unresponsive and error messages appear, you can use Developer Tools (DevTools) in your browser to diagnose the issue. This guide will show you how to: - Check the Network tab for failed requests. - Use the Preview and Response tabs to see details of errors. - Check the Console tab for other issues. - Save a HAR file to share with support.Troubleshooting "BBP Error 1551" in Sisense ElastiCube Builds
Troubleshooting "BBP Error 1551" in Sisense ElastiCube Builds Summary This article provides a comprehensive guide to troubleshooting the "BBP error 1551" that occurs during the build process of ElastiCubes in the Sisense Windows environment. The error typically indicates a discrepancy between the logical schema and the actual result of the ElastiCube, leading to build failures. Main Content Step-by-Step Instructions to Resolve the Issue Identify the Error: The BBP error '1551' indicates a mismatch between the logical schema and the actual data/indexes in the ElastiCube. This is done to prevent inconsistencies. Initial Troubleshooting Steps: Run Build Schema Changes: After creating a Custom Table, run Build Schema Changes. Add the Relationship and run Build Schema Changes again. Run Full Build: Perform a Full Build (Replace All) to ensure all data and indexes are correctly aligned. Check Logs for Detailed Error Information: Build Process Logs: %ProgramData%\SiSense\PrismServer\ElastiCubeProcessLogs\ ElastiCube Server Logs: %ProgramData%\Sisense\PrismServer\PrismServerLogs\ Review these logs to identify any specific issues or patterns that may be causing the build failure. Frequency and Environment Check: Determine how often the scheduled build runs and how frequently it fails with this error. If possible, duplicate the ElastiCube or create a new one for testing purposes and set its schedule to be more frequent. Observe if the issue's frequency increases. Accumulative Build Check: If the error occurs during an accumulative build, consider running a Full Build (Replace All) to reset the schema and data alignment. Troubleshooting Tips and Alternative Solutions No Recent Changes: If no changes have been made to the ElastiCube and the error persists, it may be necessary to investigate any underlying system or environmental changes that could affect the build process. Monitor and Report: Continuously monitor the build process after implementing the above steps. If the issue reoccurs, provide detailed logs and error messages to the support team for further analysis. Check out this related content: Academy Course Sisense DocumentationResolving Quest Service Fluctuations in Sisense on Windows
This article could help you fix the Quest service issue in Sisense fluctuating between active (green) and inactive (red) states under the https://yourhost/app/status page. The issue usually occurs because of the Sisense.Quest service malfunction.MongoDB logs take too much Drive space
Question: MongoDB logs keep growing and lead to no available space on Drive. Solution: Need to Enable Log Rotation In MongoDB. The following properties, located in "C:\Program Files\Sisense\Infra\MongoDB\mongodbconfig.conf", enable the log rotation and stop the continuous log growth: If that does not help you please create a support ticket and our support agents would be happy to help.
