Platform FAQ
Last updated
Last updated
Please consult the in the Installation Guide for more details
To ensure seamless communication, follow these firewall configuration steps:
Agent Communication with Datasentinel Platform:
Enable bidirectional communication (push and pull) between the agents and the DataSentinel platform.
Specify the platform server address.
The default port for communication is 443
Platform to Agent Communication:
Configure the Datasentinel platform to communicate with the agents.
Establish one-way communication: Platform to agent.
The default agent port is 8282; feel free to modify it using the or .
To ensure seamless communication, follow these firewall configuration steps:
Agent Communication with DataSentinel Platform:
Allow bidirectional communication (push and pull) between the agents and our DataSentinel platform.
Specify the server as: <<server name provided by Datasentinel team>>
The port to be opened is: 443.
User PC to Agent Communication:
Configure the user PCs to communicate with the agents.
Ensure one-way communication: User PC to agent.
The default port for agent communication is: 8282. You have the flexibility to customize the agent port using either the or the
Datasentinel currently does not offer a native High Availability (HA) architecture within the platform.
Since all essential components are consolidated to run on the same server, we recommend leveraging the capabilities of virtual machines (VMs) to achieve High Availability.
Utilizing VMs enables you to create a highly available environment for Datasentinel effectively. This method maximizes the inherent features of VMs, such as snapshotting, replication, and quick recovery, ensuring that your monitoring system remains robust and resilient even in demanding conditions.
Similar to our approach for High Availability, we recommend utilizing the capabilities of virtual machines (VMs), such as snapshots, for backing up the Datasentinel environment. These VM snapshots can be an effective way to capture the entire state of the VM, including the Datasentinel application, its configurations, and data at specific points in time.
Additionally, Datasentinel provides a custom backup shell script designed to automate the backup process of critical metadata such as user accounts, roles, and configuration settings.
This script is configured to perform backups on a daily basis, automated using a crontab entry, by default.
Backups are stored in the /datasentinel/backup directory and are maintained with a retention period of 7 days.
// Bash script
/datasentinel/soft/datasentinel_backend/scripts/datasentinel_backup.shIf you wish to replace the default self-signed certificate with your own for the on-premises platform, adhere to the following steps:
Existing Self-Signed Certificate: Be aware that the on-premises platform utilizes a self-signed certificate configured through NGINX. This certificate is stored within the /etc/nginx/certs directory.
Generate Your Certificate: Generate a certificate suitable for your platform machine. It should adhere to security standards and compatibility prerequisites.
Certificate Replacement: Substitute the current cert_datasentinel.pem and key_datasentinel.pem files with your actual certificate and private key files.
Restart NGINX: After the certificate files have been updated, restart NGINX to ensure the seamless integration of your new certificate.
By following these instructions, you can enhance your on-premises platform's security by substituting the default self-signed certificate with a custom one of your choosing.
As a default, data is retained for a duration of 14 days. This retention period maintains consistent precision throughout the entire timeframe.
However, you possess the ability to adjust this retention period to align with your specific requirements. To effect this change:
Access the Global Settings submenu.
Input the desired retention period.
Please Note:
Each platform features its own distinct data retention policy.
Multiple platforms can maintain diverse retention periods. For instance, you might have one platform tailored for production clusters and another for non-production clusters.
To enable or disable access logs, utilize the following steps:
Access Configuration File:
Open the configuration file /etc/nginx/conf.d/datasentinel.conf.
Adjust the access_log Parameter:
For enabling access logs:
access_log /var/log/https_datasentinel.log combined if=$loggable;For disabling access logs:
access_log off;Reload Nginx: After making the changes, reload Nginx for the modifications to take effect. Use the command:
/usr/sbin/nginx -s reloadBy following these instructions, you can conveniently enable or disable Nginx access logs as needed to monitor or restrict the logging of incoming requests.
It's advisable to deactivate the generation of logs by the InfluxDB database.
To achieve this, make the following parameter adjustments within the configuration file located at
/datasentinel/soft/influxdb-1.7.6-1/etc/influxdb/influxdb.conf:
[data] Section:
Set query-log-enabled = false to prevent logging queries before execution.
[http] Section:
Set log-enabled = false to disable HTTP request logging.
Set suppress-write-log = true to suppress write request logs when the log is enabled.
[logging] Section:
Specify the desired log level (e.g., error, warn, info, debug) with level = "error".
After making these changes, you need to restart InfluxDB for them to take effect. Use the command:
sudo systemctl restart datasentinel_influxdbPlease be aware that restarting the InfluxDB database might take some time depending on its size.
Datasentinel generates logs, which are located in the /datasentinel/log directory, except for the NGINX log file.
The primary log file, datasentinel.log, serves as a valuable resource for debugging purposes.
For additional details, please refer to the dedicated within the platform installation guide.
Consult the of the platform documentation
For more detailed information, consult the